Data migrations are inevitable, but not often strategically planned for. Here are 3 ways to plan better based on client work. I’m a data consultant, freelance digital asset manager, & indie developer. I’ve led several multi-system data migrations for nonprofits, cultural heritage, film and media, and creatives.
(1) Get a developer on the project. Understanding of the data/collections and understanding of the system is often held by different departments and staff members. But data migrations need both. Moreover, a developer is often needed to get the actual data exported from a system because the system is designed by/for developers and uses their logics like the command line.
(2) Know that you won’t export the data how you’re envisioning. Your organization spent years entering data per technical standards like DACS, PBCore, and LC Authorities, but the data export doesn’t necessarily retain any of their formatting or nested hierarchies. Data exports are usually as CSV, XML, or JSON files. This limits how the data can be arranged and organized as you move it to new systems.
(3) Timelines are unpredictable. Plan for the monkey wrench. Plan for staff sabbaticals, time off, and maternity leave. Plan for the system’s limitations to push your expected timeline back. Data migrations are a marathon, not a sprint. Migrations are way more complex than preparing, downloading, and moving data. Typical complications include: system crashes, missing data upon export, & the need to create new metadata profiles/mappings.
My books are open! I’m looking for remote freelance and contract work doing database migrations, data assessments, digital projects, development/programming, digital asset management, analytics, or data storytelling.
Portfolio: https://www.decolfutures.com/
Email me: danareijerkerk@gmail.com