At the start of a legacy migration, the schedule always looks plausible. The old system is understood, at least by the people who built it. The new system is designed. The scope is defined. Six months is an optimistic estimate, but not an absurd one. Twelve months is conservative. Eighteen would be embarrassing to admit to leadership.
Three years later, the migration is either still running, has been quietly cancelled, or has finished in a shape that required so many compromises that some of the original problems were simply reproduced in the new codebase. This is not an unusual outcome. It is the modal one.
The explanation most teams reach for is technical: the old system was more complex than anticipated, the new platform had unexpected constraints, the data model did not map cleanly. These things are true, and they contribute to the timeline. But they are not the reason migrations take three years. The reasons are almost entirely organisational.
The system you are replacing is never fully understood
Legacy systems accumulate business logic the way old buildings accumulate load-bearing walls. Something was added to handle an edge case in 2009. Something else was patched to deal with a customer exception in 2013. A calculation was adjusted slightly in 2017 because someone noticed the numbers were wrong in a way that nobody could fully articulate. The person who made each change may no longer be at the company. The reason it works the way it does is often not written down anywhere.
The discovery phase of a migration — the part where you figure out what the old system actually does — is almost always underscoped. Teams spend two weeks on discovery before beginning design, find no obvious surprises, and conclude that the system is well understood. Then they spend the next eighteen months finding surprises.
A more honest approach is to assume that the legacy system contains roughly three times as much undocumented business logic as anyone currently believes, and to plan discovery accordingly. In practice this means running the old and new systems in parallel for longer than feels comfortable, accepting that some edge cases will only surface when real users encounter them in production, and treating the legacy system's behaviour as the specification rather than the requirements document.
The people who know the old system are never fully available
The subject matter experts for a legacy migration — the people who understand why the system behaves as it does — are almost always the same people who are responsible for running the business day-to-day. They cannot be fully seconded to a migration project without the operations that fund the project degrading.
What typically happens is a compromise: subject matter experts participate in workshops, answer questions on demand, review deliverables when they have time. This works well enough during the early stages, when the questions are strategic. It becomes a bottleneck during implementation, when the questions are specific: what should happen when this field is null? Is this behaviour intentional or a bug? What does this status code mean in the context of this particular workflow?
These questions are not difficult. Each one takes ten minutes to answer. But there are thousands of them, they arise unpredictably, and they can each block a sprint if the right person is not available. The migration accumulates wait time in increments that never show up as individual blockers on a status report, but which collectively account for months of elapsed calendar time.
Stakeholder alignment erodes
The executive who sponsored the migration had a clear rationale: reduce operational costs, eliminate technical debt, enable capabilities the old system could not support. That rationale was persuasive enough to secure a budget and a timeline. Eighteen months into the project, that executive has moved to a different role. Their successor inherited the project without inheriting the conviction that motivated it.
This is not a failure of individuals. It is a structural feature of how long migrations take relative to how frequently organisations change. A three-year project will, on average, outlast the tenure of the person who commissioned it. When that happens, the project loses its organisational patron at exactly the moment when it is most likely to need one — during the difficult middle phase when the old system is still running, the new system is not yet ready, and the team is asking for more time and money to bridge the gap.
The migrations that survive this transition are the ones that have distributed sponsorship — where enough people at enough levels understand why the project exists that it can survive the departure of any single champion. This is harder to create than a single executive sponsor and rarely emerges naturally. It has to be built deliberately, usually through regular communication to a wider audience than the core project team.
Eighty percent complete is a trap
The most dangerous milestone in a migration is eighty percent complete. At that point the new system handles all the common cases. The main workflows work. A reasonable demo can be given. The remaining twenty percent is a list of edge cases, exceptions, and unusual scenarios that have been deferred to keep the main path moving.
That twenty percent represents the accumulated complexity of years of production use. Each item on the list is there because a real user encountered a real situation that the standard workflow did not handle. Collectively, they encode most of the institutional knowledge about how the business actually operates as opposed to how it is supposed to operate.
Working through them is slow, because each item requires the same cycle: understand the original scenario, design the handling, implement it, validate it against the people who know the domain. There is no economies of scale. The hundredth edge case is not faster to handle than the first. And the list does not shrink steadily — it tends to grow as the new system is exercised more widely and surfaces scenarios that were not previously known to exist.
Teams that reach eighty percent on schedule frequently find that the remaining twenty percent takes as long as the first eighty. This is not a planning failure. It is a mathematical property of where the complexity in these systems lives.
What the migrations that finish have in common
The legacy migrations that actually complete share a few characteristics that are not obvious at the outset.
They treat the cutover as an event to be designed, not a threshold to be crossed. The moment when the old system is switched off and the new system becomes the system of record is the highest-risk point in the entire project. Organisations that plan for this event explicitly — who can roll back, under what conditions, who makes the call, what constitutes a successful first week — are more likely to navigate it without a crisis that resets the timeline by another six months.
They run the old and new systems in parallel for longer than they planned to. This is expensive and operationally uncomfortable. It also surfaces the edge cases that automated testing does not catch, before they become production incidents in a system that no longer has a fallback.
They scope the migration to deliver value incrementally rather than completing it in a single cutover. The worst migrations are the ones where nothing can be decommissioned until everything is finished. The best ones identify which parts of the old system can be retired independently and sequence the work to deliver visible wins before the project is three years old.
And they are honest, early, about what the timeline actually is. Not to sandbag, but because an organisation that knows a project will take three years can structure itself to sustain it. An organisation that believes a project will take six months, told repeatedly that it is nearly finished, loses patience at a pace the project cannot survive.