Ask any engineering team how the big migration is going. You will hear the same number every time.
"About 80 percent."
Ask again in six months. Same number. Ask again next year. Still 80 percent, give or take.
I have sat in the leadership chair for a few of these. The new platform works. Most traffic runs on it. The old system still sits in the corner, humming, because three services, one nightly batch job, and a report the finance team loves all depend on it. Nobody wants to touch them. Everybody has moved on.
So you pay for both. Forever.
The Last 20 Percent Is Where the Work Lives
Engineers have joked about this for decades. Tom Cargill at Bell Labs put it best, and Jon Bentley made it famous in his "Programming Pearls" column in 1985. The first 90 percent of the code takes the first 90 percent of the time. The remaining 10 percent takes the other 90 percent.
Migrations follow the same rule, only worse. The easy services move first. They move fast, the dashboards turn green, and everyone feels great. What remains is the weird stuff. The undocumented integration. The service owned by a team which no longer exists. The job written by someone who left in 2019.
None of this work is glamorous. None of it ships a feature. And it lands right when the leaders who launched the migration have turned their attention to the next shiny thing.
Running Two Systems Isn't Free
Google's engineers wrote a whole chapter on this in Software Engineering at Google. The chapter is about deprecation, written by Hyrum Wright, and it is blunt.
"Having two systems to accomplish the same thing might not seem like a pressing problem..."
Over time, the chapter warns, "the costs of maintaining them both" grow substantially.
Think about what "both" means in practice. Two sets of on-call runbooks. Two sets of security patches. Two places a bug might hide. Every new hire learns the old system and the new one, plus the strange glue between them.
Stripe's Developer Coefficient report found the average developer spends more than 17 hours a week on maintenance issues such as debugging and refactoring. I'm not going to pretend half-finished migrations explain all of those hours. I'm not sure about this part: I found no study measuring how much of the maintenance load comes from running old and new systems side by side. From my own teams, I would bet the share is bigger than most leaders think.
A Warning Banner Won't Finish the Job
Here is the trap I fell into more than once. The new system launches. We send an email. We put a deprecation notice on the old docs. Then we wait for teams to migrate on their own.
They don't.
Google learned the same lesson. The book says a deprecation warning "rarely leads to teams actively migrating away" from the old system. It calls voluntary migration something which "should not be counted on to do the majority of migration work."
And when you force the move without help, it goes badly in a different way. Teams see the work, in Google's words, "as an unfunded mandate." They have to push their own priorities aside to keep the lights on.
So the warning banner does nothing, and the hard deadline breeds resentment. What works?
Google's answer is simple. They "strongly advocate" staffing a dedicated team "through completion." Not a side project. Not 10 percent of somebody's week. A team whose job ends when the old system is gone.
The Messy Middle Is a Leadership Problem
I talked with Ian Pettigrew on Corey-osity Unleashed about hope at work. He researches hope in leadership, and one phrase of his stuck with me. "Sometimes you go through the messy middle... of a change program," he said. His advice: look out for the glimmers.
I wrote about glimmers in Hard Times Don't Need Big Wins. They Need Glimmers. The idea fits migrations too well to ignore.
At the start of a migration, energy is high. There's a design doc, a kickoff, a big announcement. At the end, there's relief and a party. The middle has neither. The middle is where the progress bar stops moving and people quietly stop believing it will ever reach 100.
Rosabeth Moss Kanter at Harvard wrote about this pattern in a short 2009 HBR piece called Change Is Hardest in the Middle. The idea has since picked up the nickname "Kanter's Law": everything looks like a failure in the middle. I'm not sure about this part: the HBR article sits behind a paywall, so I haven't verified her exact wording.
Here is where I think leaders fail. We start migrations with fanfare. We staff them with our best people. Then the fun part ends, and we pull those people onto the next launch. The tail gets handed to whoever is left, with no deadline, no budget, and no recognition.
Then we wonder why it never finishes.
Give the Middle Its Own Milestones
Google's book makes a point I wish I had read years ago. When you build something new, you get wins along the way. Each feature ships and somebody notices.
Deprecation is different. The chapter admits the only milestone often feels like the final one: removing the obsolete system entirely. And when you finally do remove it, nobody outside the team notices, because by then nobody uses it.
Their fix: set "concrete incremental milestones" and "celebrate incremental achievements." Those are your glimmers.
Will Larson, who ran infrastructure migrations at Uber, laid out a playbook in his post Migrations: the sole scalable fix to tech debt. Three phases: derisk, enable, finish. Two of his points hit hardest for me.
First, stop the bleeding. Make sure all new code uses the new approach, with a linter ratchet or updated templates. In his words, this "turns time into your friend."
Second, save the big celebration for the end. He warns "starting but not finishing migrations often incurs significant technical debt," so your recognition should reward the finish, not the launch.
He also says something every leader should hear: if a team isn't working on a migration, "it's typically because their leadership has not prioritized it."
The fault sits with us. Not with the engineers.
What I Do Now
Here's my short list for any migration past the halfway mark.
Count what's left, out loud
Not a percentage. A list. Name every remaining service, job, and consumer. "80 percent" hides the problem. "Eleven things, here they are" exposes it.
Keep a team on it until the lights go out
If the people who started the migration have moved to the next project, the migration has no owner. Give it one, with a date and a budget.
Celebrate each removal
Every time a consumer moves off, say so in the team channel. Name the engineer. Say what got deleted. Deleting code deserves as much noise as shipping it.
Throw a party when the old system dies
Pull the plug in front of people. Put a hat on the server if you have to. Make finishing a thing your team wants to be part of.
Decide to stop, if stopping is right
Some migrations shouldn't finish. Perhaps the business changed. Fine. Then say so, write it down, and plan to keep both systems on purpose. Drifting at 80 percent is the worst of both options.
Your Move
Pick the oldest unfinished migration in your organization. Ask the team what's left. Get the list, not the percentage.
Then ask yourself the harder question. Who did you move off this work, and when?