What Does Museum Data Migration Entail?

Museum data migration can be an intensive but ultimately satisfying project component when moving to a new museum Collections Management System (CMS). 

There are typically four main activities for museum data migration; however, the data migration experience can vary. Both the data migration approach and results will depend on the current CMS in place, the newly selected CMS, the current quality of the data, and how much preparatory work can be completed before the migration begins. 

The Main Data Migration Activities

These are the four major data migration activities to plan for:

1. Ascertain how data can be extracted from the current CMS.
2. Asses quality of current data.
3. Learn how data can be ingested by the new CMS.
4. Evaluate migrated data in new CMS and refine migration process as needed.

Ascertain How Data can be Extracted from the Current CMS

For the purposes of this post, collection data in spreadsheets and FileMaker Pro (or similar) databases are included in our discussion of the current museum CMS. Essentially, we need to consider where our data is currently and review just how hard (or easy) it is to extract from the system. 

Proprietary: If the current system is proprietary then you can begin by reaching out to the current CMS vendor to receive information on the data extraction part of the migration process. 

Open-Source: If the current system is open-source, then there’s usually documentation available for how to extract or export the data. If the CMS open-source product is widely adopted and used, then there may also be a robust online community to tap into for resources and peer-to-peer troubleshooting.

Homegrown (Access or FileMaker): These are admittedly the trickiest as the database is part proprietary (but without vendor support) and part completely customized. This hybrid status requires the museum to have advanced technical and database experts on staff, or can afford to bring on a 3^rd party consultant. 

Assess the Quality of the Current Data

This aspect can be quite complex. For a refresher, please review our previous posts on this topic: 

• How to Prepare for a New Museum CMS
• Evaluating the Quality of Museum Data
• Evaluating the Format of Museum Data
• Evaluating the Location of Museum Data
• Evaluating the Location of Museum Digital Assets
• Common Museum Data Messes to Look For
• Strategies for Data Cleanup—Part 1
• Strategies for Data Cleanup—Part 2
• Create a Plan for Data Cleanup

Learn How Data Can Enter the New CMS

We need to understand how the museum collection data can migrate into the new CMS. Many CMS vendors (of proprietary products) offer migration support in the form of tools and personnel. This is usually included as part of the 1x setup costs. However, for CMS products that are not proprietary (e.g. open-source) or are home-built (e.g. FileMaker or Access databases) there is no built-in support. Depending on the museum budget for this activity you may have the option to work with a 3^rd party consulting firm. Otherwise, you’re on your own for figuring out how to migrate the museum data (and possible digital assets) by yourself. Whether you work with a vendor, a 3^rd party consultant, or you’re doing it yourself, most contemporary CMS platforms support importing collection data via a Comma Separated Value (.CSV) spreadsheet. The key is to understand the format the spreadsheet and data need to be in, and how to import the data into the CMS via spreadsheet.

Other ingest file formats can include: JavaScrpt Object Notation (.JSON) and Extensible Markup Language (XML). There may be an Application Programming Interface (API) option for extraction, though this requires the support of API functionality from both the current and the new systems.

Evaluate the Migrated Data and Refine

Finally, the last piece to this process is an evaluation and refinement of how data migrated into the new CMS. If your data set is fairly simple and straightforward—and the new CMS is intuitive and built for standardized museum data—then you may only need to execute one migration. However, if there are complexities present then there may be several rounds of migration in order to ensure the data is mapping correctly and everything is working as anticipated. Those complexities can include: 

• The current data is complicated
• The new CMS wasn’t specifically built for your type of data
• There were significant customizations made to the current or new system

If any of these items are present, I recommend creating and using a testing script in order to review the data and proactively flush out any potential data issues.

Conclusion

Understanding how the museum CMS data leaves the current CMS and enters the new CMS is critical for a successful (and efficient) data migration. Even if resources are available to you for data analysis, extraction, and ingest; it’s important to understand how the different migration activities impacts the next. Next week we will review how to prepare for museum data migration into a new CMS.