Library Data Migration Checklist

Treat migration as controlled transformation

Moving records is not the same as preserving meaning. Begin with a source inventory: systems, exports, formats, encodings, record counts, relationships, identifiers, attachments, local conventions, and known quality problems. Keep the untouched source export as evidence and as a recovery point.

Migration checklist

• Profile fields, value patterns, encodings, missing values, duplicates, invalid dates, identifiers, and orphaned relationships.
• Write an explicit source-to-target mapping with transformation rules, defaults, exclusions, and ownership decisions.
• Normalize only what is understood; preserve original identifiers or create a documented crosswalk.
• Run repeatable test migrations and retain logs, rejected rows, warnings, counts, and sample comparisons.
• Obtain functional validation from librarians, repository staff, or data owners before final cutover.

Validate more than totals

Counts can match while records are still wrong. Sample simple and complex examples across collections, dates, languages, item types, creators, access states, and edge cases. Confirm search, display, links, holdings, patron relationships, permissions, files, and reports in the target system.

Plan the final cutover

Define the last source update, freeze window, final export, transformation run, validation owner, launch decision, rollback condition, and communication plan. Keep the source system and migration artifacts available until the target has completed an agreed stabilization period.

Leave an evidence trail

Retain source checksums, mappings, scripts, versions, logs, reconciliation results, rejected-record decisions, acceptance notes, and the final imported files. This makes future correction, audit, upgrade, or migration far safer than relying on memory.