CSStewardship
Preparing collection data for a system migration
A practical pre-migration audit for collection records: field mapping, vocabulary control, duplicate checks, and validation before data moves.
Entry checked on
What does a system migration actually involve?
A migration is not a copy and paste. It is a controlled mapping exercise in which every field in your current catalogue is assigned a destination in the new system, or consciously retired. Museums and archives that treat this as an IT task alone tend to discover problems after go-live, when object records no longer match their labels, loan paperwork, or published online entries.
The U.S. National Park Service manages museum and archival collections across more than 390 parks and centers, and its Museum Handbook gives guidance and standards on managing, preserving, protecting, documenting, and accessing museum collections (NPS Museum Program). That scope is a reminder that documentation standards exist to keep records usable across many years and many hands, not just within one database version.
Before any export, decide what the migration is for. Are you consolidating two catalogues, moving to a hosted system, or replacing software that is no longer supported? The answer shapes how strict your checks must be. If you are still separating stock lists from full descriptions, it helps to revisit the difference between inventory and catalogue records before the map is drawn.
Which record fields must survive the move?
Start with a field-by-field map. For each source field, record its destination, its data type, whether it is required, and whether values are free text or controlled.
A useful minimum set for object records includes: accession or registration number, object name, brief description, number of items, current location, condition summary, and rights or credit information. Your own documentation standard may require more, so review what minimum record fields your institution has agreed to support before committing to the map.
Treat the map as a working document, not a formality. Reviewers should include a curator, a registrar or collections manager, and whoever administers the database. Where a field carries condition information, make sure the language used in the new system matches the way your team writes condition reports, otherwise the same object may be described two different ways in the same week.
How should controlled vocabularies be handled?
During migration, free text fields rarely survive a change of system without cleanup. Terms that were entered casually over ten or twenty years will conflict with the stricter lists a new system usually expects, and staff will notice the inconsistency as soon as they start searching.
Questions to settle early:
- Which fields are currently free text but should become controlled?
- Is your new system able to hold a local term list, or must you adopt an external one?
- How will you record terms that have no acceptable equivalent?
Do not force every legacy term into a list that does not fit. Record unresolved terms in a holding list, migrate them as legacy values, and schedule review after launch. Silent deletion destroys institutional memory, and it is often the deleted term that a researcher later needed to match an older citation.
What checks should be run before export?
Run these checks systematically and log the results. Each one produces a worklist that someone can actually clear.
Uniqueness. Confirm that accession numbers are unique and correctly formatted. Duplicate identifiers are the single most common cause of records overwriting each other during import.
Completeness. Count records missing required fields. Report by field, not just by total, so the work can be assigned.
Orphan records. Look for component, media, or loan records that point to a parent object record that no longer exists.
Value ranges. Check dates, dimensions, and counts for values that fall outside plausible ranges. A height recorded as 4000 centimetres may be a unit error or a typo.
Character handling. Identify diacritics, non-Latin scripts, and special punctuation. Test these in a small sample import before the full run.
Attachment integrity. Confirm that every file path or media link resolves, and that no filename collisions will occur on import.
Spelling and consistency. Run a duplicate detection pass on object names and artist or maker names to catch variant spellings.
Each check should produce a countable list, not a general impression. A migration is auditable only if the before and after states can be described in numbers and examples.
How can you tell whether a field mapping decision is sound?
Use a short decision checklist before finalising each mapping. The table below sets out the questions worth asking.
| Decision point | Question to ask | If the answer is unclear |
|---|---|---|
| Field purpose | Is this field still used in reports, labels, or loans? | Keep as legacy field, migrate the values |
| Destination type | Does the new field accept the same kind of value? | Convert on export, keep the original in a notes field |
| Controlled list | Does an approved term exist for the values present? | Migrate as legacy term, flag for review |
| Required status | Is the field mandatory in the new system? | Prioritise filling gaps before import |
| Repeatability | Can the new field hold multiple values? | Split or concatenate deliberately, and document which |
| Public visibility | Will this field be published online? | Confirm rights and privacy status first |
If two people disagree about a mapping, the disagreement itself is useful. It usually reveals a documentation rule that was never written down.
What should be tested in a trial migration?
Never migrate the whole catalogue first. Export a sample that deliberately includes difficult cases: records with long text notes, multiple components, attached media, non-Latin scripts, and unusual accession formats.
A trial should confirm five things. Records arrive in the expected number. Identifiers remain unique. Required fields are populated. Media links open. Search and sort behave as expected on the migrated values.
After the trial, compare the new record against the old one field by field for at least a few dozen objects. A record can import successfully and still be wrong.
Document what changed during the test, including any fields you decided to merge. That documentation becomes your rollback reference if the full migration needs to be paused. If the collection also includes incoming loans, check how loan paperwork will reference the new identifiers before the import is locked.
When should you pause the migration?
Pause when the map is incomplete, when duplicate identifiers exceed a small number, or when a required field has no credible source of data. These are not technical failures. They are documentation gaps that will follow the collection into the new system.
If your institution operates under a national or funder documentation standard, check the current published guidance before deciding to drop a field. Standards are revised, and requirements for public reporting may differ from what is expected internally. Confirm which standard applies to your collection type and jurisdiction before the export is final.
What work continues after go-live?
Migration ends, but data work does not. Set a review period of three to six months in which staff log every record that behaves oddly in the new system. Track unresolved vocabulary terms to closure.
Then write down what you learned as a local procedure: how fields are mapped, how terms are approved, how new records are validated on entry. That document is what prevents the next migration from repeating the same audit.
A migration is a rare opportunity to see your catalogue as it actually is. Treat the cleanup not as overhead but as the substantive project.
