Why migrations stall at eighty percent

Somewhere in every large engineering organization there is a migration that is eighty percent done and has been eighty percent done for eighteen months. The dashboards are green, the new system carries most of the traffic, and the old system hums along underneath like a pilot light that costs four headcount. The stall is so common it deserves to be treated as a law with a mechanism, not as a series of local disappointments.

The mechanism is selection. Migrations move easy cases first, and rationally so: momentum, morale, early wins for the steering committee. But this sorts the backlog by difficulty, which means the remaining twenty percent is not a smaller version of the first eighty. It is the set of everything weird: the customer on a contractual integration, the batch job with no owner, the workflow that only exists in February, the dependency nobody ever finished deprecating. The first phase was a paving operation. The last phase is a series of bespoke negotiations, each with its own stakeholder, risk profile and definition of done.

The funding model rarely survives this phase change. Migrations get budgeted as one project with one curve, so when throughput drops tenfold at the tail, the org reads it as failure rather than as the expected second project beginning. Attention drifts, sponsors rotate, the tiger team returns to features. The migration enters its zombie state: too done to cancel, too undone to celebrate, paying double run costs indefinitely. The financial industry provides the cautionary extreme: TSB's 2018 attempt to finish a core banking migration in one heroic weekend ended in weeks of customer lockout and, eventually, a £48.65m fine from UK regulators, a reminder that the tail's risks do not shrink because the schedule does.

Organizations that finish migrations plan the tail as its own campaign from day one, and the practices are consistent. The long tail is enumerated early, by name, with an owner per item; "the rest" is not a line item. Decommission dates are external commitments (contracts renegotiated, hardware leases lapsing, support windows ending) rather than internal aspirations, because externally anchored dates survive reorgs. Progress is counted in things turned off, not things turned on; the second number flatters, the first one finishes. And somewhere, visibly, the double-run cost is printed monthly, because nothing refocuses a steering committee like the pilot light's utility bill.

There is also an unfashionable option that the completion-minded overlook: declaring the tail permanent on purpose. Sometimes the last three integrations genuinely cost more to move than to run forever behind an adapter. The failure is not the choice; it is making the choice by exhaustion instead of arithmetic, and calling it eighty percent done for five more years instead of ninety-seven percent done, closed, with three documented residents.

Migrations are promises about an ending. The eighty percent stall is what happens when an organization funds the beginning of the promise. The teams that keep it simply read the fine print at the start: the last mile is a different road, and it tolls.