Most system migrations don’t fail because of the new software. They fail during the changeover, in the gap between switching the old system off and trusting the new one is actually ready.
On a recent digital asset management migration, one decision made that gap safe: running the old and new systems in parallel through the changeover, rather than cutting over in one move.
The decision nobody wants to pay for
Parallel running costs more up front. You’re maintaining two systems, two sets of access, two things that can go slightly out of sync, for however long the changeover takes. It’s tempting to skip it and just switch on the day, especially when a project is already tracking to budget.
That temptation is exactly the risk.
What a hard cutover actually risks
If you cut over in one move and something doesn’t behave as expected, there’s no fallback. Maybe a data field maps incorrectly. Maybe a metadata standard clashes with the new format. Maybe staff simply don’t trust the new interface yet. Whatever it is, the old system is already off, so whatever breaks, breaks live.
For a collection of any real size, that’s not a minor inconvenience. It’s staff unable to find assets they need for their work, external requests going unanswered, and a scramble to fix a live system rather than a controlled one.
How it actually played out
This particular migration moved over 100,000 digital assets from an on-premises system to a SaaS platform, including data cleansing and a new migration format for every asset. Configuration and testing ran alongside the parallel systems throughout the changeover.
The project finished in 19 weeks and within budget. Parallel running was part of how that stayed achievable: nothing had to be verified for the first time on the cutover date itself, because the cutover date wasn’t the first real test.
What this means if you’re planning your own
This isn’t specific to digital asset management systems. The same principle holds whether you’re migrating a DAMS, an ILS, a PIMS, or a CMS, or any system where the collection or dataset itself is the thing you genuinely cannot afford to lose access to.
A few things worth deciding before you start, not during:
– Set your cutover trigger in advance. Decide what “ready” actually means, in specific terms, before the project begins, not as a judgement call under deadline pressure.
– Budget the parallel-running period as its own line item. Not a buffer, not contingency, a planned and costed phase of the project.
– Test the data format change on a subset first. Migrating format alongside migrating platform doubles the things that can go wrong at once. Prove it works small before it needs to work at scale.
– Decide who has the authority to delay cutover. If the answer is “whoever’s under the most deadline pressure that week,” that’s not a real answer.
None of this makes a migration faster. It makes it survivable if something doesn’t go to plan, which is the more useful thing to optimise for.
The takeaway
The smoothest migrations aren’t the ones that move fastest. They’re the ones where somebody decided, before anything was at risk, exactly how they’d know it was safe to let go of the old system.
If you’re looking at a migration like this and want a second opinion on the changeover plan specifically, that’s a conversation worth having before the project starts, not during it.
Book an initial consultation: https://calendly.com/informedbyte/initial-consultation
*This article was drafted with the help of Maya, our AI marketing agent, to keep things timely. All AI content is reviewed by humans.*