Moving a collection catalog to a new system: a checklist

Most catalogs have been through several hands. Records were typed into a database in one decade and a spreadsheet in the next. A migration is the moment all of that history has to agree. The checklist below follows what we do before a switch-over: map every field, reconcile record statuses, check the new system against the old one and keep a way back. Work through it in order.

1. Know what you are moving

• List every source. That includes the main catalog, side spreadsheets, accession registers and any files staff keep on their own computers.
• Decide which source wins when two disagree, and write the decision down.
• Agree on how changes to the old system will be handled while the migration runs. Either freeze it or log every edit.

2. Map every field

Build a mapping workbook with one row per source field. Each row names the target field, the rule for converting the value, and an example record. Fields with no home in the new system get a row too, with a decision. Keep open questions in a separate column from rules that have been agreed, so nobody mistakes a guess for a decision.

3. Clean before you load

• Dates in mixed formats, including "circa" and ranges.
• Names of people and places spelled several ways.
• Terms that should come from a controlled list but were typed free.
• Duplicate records, and records that are really two objects.

Keep the original value next to the cleaned one. You will want it when someone asks why a date changed.

4. Decide the fate of every custom field

Older systems collect user-defined fields and notes that only one person understood. For each one, choose a permanent field in the new data model, fold it into a note, or drop it. Set who may see it. A field that held donor contact details should not become public by accident.

5. Reconcile record status

Published, unpublished, draft, restricted. In an old system the status may sit in a checkbox for some records and a folder name for others. The two will not match. Produce one list of every record with its target status. The person responsible for the collection signs it.

6. Run a test migration

Load everything into a test copy of the new system, never into the live one. Count records by type and by status, and compare the counts with the source. Open a sample of records side by side with the old system. Ask staff to do their everyday tasks in the test copy and write down what they could not find.

7. Check the new system against the old

• Record counts match, by type and status.
• Searches that staff run every week return the same items.
• Images and files are attached to the right records.
• Links between records, such as a photograph and the person in it, survived the move.
• Nothing marked unpublished appears on the public site.

8. Keep a way back

Take a full backup of the old system before the switch-over and keep it readable. Give staff read-only access to the old catalog for an agreed period. Do not retire it until acceptance is signed.

9. Accept in writing

Agree on the acceptance checks before the migration starts, and name the person who signs. Keep a list of known issues with an owner for each. Acceptance means the list is empty or every item has an agreed date.

What to ask your digitization vendor

If scanning runs alongside the migration, the files need to import cleanly. We do not scan or digitize material, but we build the systems that receive the files, and these four requests make the import far simpler.

1. File names that carry your catalog identifier, in a pattern agreed before the first batch.
2. A manifest with every batch, listing each file, its identifier, its size and a checksum.
3. Metadata delivered alongside the images as a spreadsheet or CSV, using the field names from your mapping workbook.
4. A sample batch first, so the import can be tested before the bulk delivery arrives.

Read more about how we build collections management systems and digital archives, including how we move existing records.