When a museum moves to a new Collections Management System (CMS) certain data requirements must be addressed prior to migration in order for it to complete successfully. 

This post will review the common data areas that need to be ready for migration and what the consequences are if they are not.

Please read my previous posts What Does Museum Data Migration Entail? and How to Prepare for Museum Data Migration for an overview and instructions leading up to this post.

Items Required for Successful Migration

These are the common data areas where cleanup is most often required in order to achieve a successful data migration:

• Required fields complete with data
• The mapped field is “like for like” in term of data format
• Unique record identification numbers
• Image file names in the corresponding data record
• Authority records are consistent

Required Fields are Complete with Data

If your new CMS record template has required fields for saving a record, that usually means any data migrated over must also have each of those required fields completed with appropriate data. Depending on the complexity of the new CMS it may allow the creation of a partial or stub record with empty required fields, but those records will require almost immediate attention in order for your new CMS to work effectively across your entire collection.

Mapped Fields Match

Moving collection data breaks down to a field-by-field move. For example, the Object Name field in the old CMS needs to map appropriately to the Object Name field in the new CMS. This can get tricky as each field type will have an expected input. For example: A date field may require 08/27/2010 (i.e. MM/DD/YYYY), but the data you have is August 27, 2010. If your data format is even slightly different from what the new CMS is expecting, then it may reject that data from coming over.

Unique Record Identification Numbers

Whether you realized it or not, all museum collections management systems generate and assign a unique identification number to each of your records. That means the records leaving your current CMS will have a record ID number which will help the new CMS know how to ingest that record and any related data components. If there are duplicates somehow the new system understandably doesn’t know what to do with those two identical-seeming records. The new CMS will either conflate the two records and all related data, or it will reject the migrating data.

Image File Names Are in the Record

While not strictly required for data migration success, including the image file name in the corresponding data records is required in order to successfully reattach the digital asset to its record. If the record doesn’t capture the digital file names, those digital files will be divorced from their intended records. Given that a majority of museum collections in a CMS contain at minimum one digital image file per record, including the file name in the record is a requirement born out of necessity. Otherwise the files will have to be re-uploaded to the appropriate records “by hand” and by record in the new CMS.

Authority Records are Consistent

In addition to collection records, there are also authority records migrate over. Authority records are usually informed by a controlled vocabulary (e.g Nomenclature). Many, but not all collections management systems include controlled vocabularies and can also support any locally created authority terms. Authority records can include creator/artist names, subjects, genres, materials, geographic locations, etc. If your current CMS contains a non-standard vocabulary, and/or if the vocabulary was used inconsistently, the ability for the new CMS to correctly interpret the authorities present and their relational links will be hindered. It may not break the migration, but it will create an even larger mess and impact search result efficacy.

Conclusion

On the surface, these five items may not seem very large. However, it’s important to review your situation (current CMS, current data quality, and new CMS) in order to adequately prepare for your data migration. If even one of these areas is compromised with bad data, it can create a huge (and urgent) data cleanup need during migration.