There are TONS of unspoken tasks for a data migration. Here are the top three based on recent 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) Network Admin. When you migrate data, your ecosystem typically looks like: a virtual server, the SQL database that lives there, a public and/or private facing database portal staff use, and network security measures like a firewall and VPN. This intel is often not written down or in other words: no one knows who “owns the server.” And there’s usually no IT person dedicated to your CMS/DAMS. So when you migrate a CMS/DAMS you have to find out what your ecosystem looks like, who has the IP address and password/usernames to root access, and more.
(2) System Architecture. Developers who make the CMS/DAMS write documentation about what the system looks like, how to export data, how to configure it, etc. These docs are notoriously ambiguous. They don’t tell you the developer codes for the archival DACS hierarchy field that staff see on the database portal for example. And staff working inside the CMS/DAMS often don’t have an IT background so dev docs are hard to read.
(3) Technical Writer. CMS/DAMS is not just the database, it’s the server stack, the network security, and the new needs of the next database you’re moving to. Staff who work inside a CMS/DAMS or even a dedicated IT person for that database won’t necessarily have full-stack developer knowledge. When you migrate data, you often need to sandbox (test and play what works), and scour the internet for leads on how to use your old system so you can move to a new one.
Check out my portfolio for more like this. I’m looking for remote freelance and contract work: https://www.decolfutures.com/