Migration plans are built from what the system is understood to do. Migration timelines are determined by what it actually does. The gap between those two is where the schedule goes.
This is not poor planning. It is a structural property of long-lived systems: they accumulate behaviour that was never written down, and much of that behaviour is load-bearing.
The undocumented dependencies
There is a report somebody runs monthly against the production database directly. There is a scheduled job whose author left in 2019. There is a partner pulling a CSV from a path nobody has thought about in years. None of these are in the architecture diagram, and every one of them breaks on cutover.
The cheapest way to find them is instrumentation, not archaeology. Log every connection, every query source, and every file access for a full business cycle before planning the move. A month of observation routinely surfaces things six weeks of interviews miss, because people genuinely do not remember.
A full business cycle, not a calendar month
Quarter-end behaves differently from mid-quarter. Annual renewals exercise code paths that lie dormant for eleven months. If observation covers only a quiet period, the migration will meet those paths for the first time in production.
Where waiting a full year is not viable, at least identify the periodic processes by reading the scheduler, and treat each one as an explicit risk rather than an assumption.
Data is slower than compute
Moving an application is usually a matter of weeks. Moving its data — reconciling it, validating it, and proving the new copy agrees with the old — is where the real duration sits. Historical data is worse still, because it was written under schema rules and validation logic that have changed several times.
Budget for reconciliation as a first-class activity with its own tooling, not as a verification step at the end.
Rehearse the cutover, including the rollback
A cutover plan that has never been executed is a document, not a plan. Rehearse it against production-scale data, time each step, and rehearse the rollback specifically. Rollbacks are the part everyone writes down and nobody practises, which is why they so often fail at the exact moment they are needed.
Migrations run long because discovery is the work and it is invisible in the estimate. Planning for that explicitly does not make it faster, but it does stop the overrun from being a surprise.