Seeking Comment on Migration Checklist

Seeking Comment on Migration Checklist. Abbey Potter. The Signal. Library of Congress. September 3, 2015.
     Here is a draft of a migration checklist from the NDSA Infrastructure Working Group. The group  would like to gather feedback to help make this a more useful tool. This is a checklist for things to be done before and after moving digital materials and metadata forward to new digital preservation system. Normalization of data or changing formats are out of scope for this document.

Before you Move:

1. Review the state of data in the current system, clean up any data inconsistencies or issues that are likely to create problems on migration and identify and document key information (database naming conventions, nuances and idiosyncrasies in system/data structures, use metrics, etc.).
2. Make sure you have fixity information for your objects and make sure you have a plan for how to bring that fixity information over into your new system. Note, that different systems may use different algorithms/instruments for documenting fixity information so check to make sure you are comparing the same kinds of outputs.
3. Make sure you know where all your metadata/records for your objects are stored and that if you are moving that information that you have plans to ensure it’s integrity in place.
4. Check/validate additional copies of your content stored in other systems, you may need to rely on some of those copies for repair if you run into migration issues.
5. Identify any dependent systems using API calls into your system or other interfaces which will need to be updated and make plans to update, retire, or otherwise notify users of changes.
6. Document feature parity and differences between the new and old system and make plans to change/revise and refine workflows and processes.
7. Develop new documentation and/or training for users to transition from the old to the new system.
8. Notify users of the date and time the system will be down and not accepting new records or objects. If the process will take some time, provide users with a plan for expectations on what level of service will be provided at what point and take the necessary steps to protect the data you are moving forward during that downtime.
9. Have a place/plan on where to put items that need ingestion while doing the migration.  You may not be able to tell people to just stop and wait.
10. Decide on what to do with your old storage media/systems. You might want to keep them for a period just in case, reuse them for some other purpose or destroy them. In any event it should be a deliberate, documented decision.
11. Create documentation recording what you did and how you approached the migration (any issues, failures, or issues that arose) to provide provenance information about the migration of the materials.
12. Test migration workflow to make sure it works – both single records and bulk batches of varying sizes to see if there are any issues.

After you Migrate

1. Check your fixity information to ensure that your new system has all your objects intact.
2. If any objects did not come across correctly, as identified by comparing fixity values, then repair or replace the objects via copies in other systems. Ideally, log this kind of information as events for your records.
3. Check to make sure all your metadata has come across, spot check to make sure it hasn’t been mangled.
4. Notify your users of the change and again provide them with new or revised user documentation.
5. Record what is done with the old storage media/systems after migration.
6. Assemble all documentation generated and keep with other system information for future migrations.
7. Establish timeline and process for reevaluating when future migrations should be planned for (if relevant).

Digital Preservation Matters.