Migration Debt: Why Unfinished Migrations Are Your Most Expensive Technical Debt

We’ve run cloud infrastructure and platform engineering for over 15 years. In that time, We’ve seen dozens of migrations get approved, funded, and started with confidence. We’ve seen very few get finished.

Nobody budgets for that. Every migration business case assumes a clean handoff: old system off, new system on, savings realized. That’s not what happens. What happens is the old system stays on. The new system goes live next to it, not instead of it. And you end up paying for both, indefinitely.

This isn’t a technology problem. It’s a management problem. It’s your budget that’s draining.

Why Migrations Stall at 70% Complete

Migrations don’t fail loudly. They stall quietly, usually right around the 70% mark. Here’s why:

• The visible work is done; the invisible work isn’t. The new system is live. Dashboards show green. But the last 30% is the hard part: edge cases, legacy integrations, and the handful of teams still pointing at the old system for reasons nobody documented.
• The team that ran the migration gets reassigned. Once the new system is “working,” leadership pulls the migration team onto the next priority. The remaining cleanup has no owner.
• Nobody wants to be the one who breaks something. The old system still has live traffic, even if it’s 5%. Shutting it down feels risky, so it just… stays on. Forever, if nobody forces the decision.
• The business case only measured the build, not the shutdown. Most migration proposals cost out “build new system.” Almost none cost out “decommission old system” as a separate, funded, tracked project.

If your team is afraid to turn off old systems, it is a strong indicator of broader operational gaps. Find out where you stand with our free Platform Engineering Maturity Assessment.

Here’s the number that should worry you: at 70% complete, you are paying 100% of the cost of two systems for maybe 30% of the value of one migration. That’s the worst point on the entire curve, and it’s exactly where most migrations sit for years.

The Dual-System Maintenance Trap, and How It Compounds

Once a migration stalls, the cost doesn’t stay flat. It compounds. Here’s what that actually looks like on your books:

• Two license bills, two vendor contracts, two support renewals, for systems doing overlapping work.
• Two sets of engineers who know how each system works, and neither group is fully staffed because headcount was planned for one final system, not two permanent ones.
• Every new feature has to be built twice, or built once and quietly skipped on the old system, which then falls further behind, making it harder to retire later, not easier.
• Security patching, compliance audits, and access reviews double up. Your CISO’s team is auditing two systems instead of one, every single cycle.
• New hires have to learn both systems because nobody can tell them which one is “real.” That slows onboarding and increases the chance of mistakes.
• The longer it runs, the more business logic quietly moves onto the old system, because it’s easier to bolt a fix onto something familiar than migrate it properly. This is the part that compounds: the debt doesn’t just sit there; it grows.

I’ve watched this trap add 20-40% to an org’s infrastructure and headcount cost, for two to five years straight, without anyone flagging it as a single line item, because it’s spread across a dozen different budgets. This invisible dual-running cost is exactly why most cloud cost reductions fail after 90 days.

Defining ‘Migration Done’ Why Decommission Is the Only Valid Endpoint

Here’s the mistake most leadership teams make: they define “done” as the new system is live.

That’s not done. That’s halfway.

• “Live” means the new system works. “Done” means the old system is gone, turned off, contracts cancelled, servers decommissioned, and nobody has access to it anymore.
• If you can’t answer “what date does the old system get shut off,” you don’t have a migration plan. You have a migration start.
• Decommission isn’t a formality at the end. It has to be a funded, staffed, deadline-driven project of its own, with the same rigor as the build phase.
• Set the decommission date before the build starts, not after. A date set in advance creates pressure to close gaps. A date set “once everything’s ready” never arrives, because everything is never ready.

See how we structured hard cutovers and achieved 70% faster provisioning in our Multi-Cloud Hosted Data Lake Platform case study.

If your engineering leadership presents a migration plan to you without a decommission date attached, send it back. That’s not a plan. That’s a cost center you haven’t discovered yet.

How to Structure a Migration Plan That Includes Transition Engineering

This is the part most plans skip entirely: the work of actually moving off the old system, not just building the new one. Call it transition engineering. It needs its own line items:

• A named owner for decommissioning, separate from the person who owns the build. Same person, two jobs, is how the cleanup gets deprioritized.
• A budget line for the shutdown phase, data migration for stragglers, contract cancellations, final security reviews, approved at the same time as the build budget, not requested later as a surprise.
• A cutover checklist with hard dependencies listed by name, which teams, which integrations, which reports still touch the old system, and what has to happen before each one can be cut over.
• A go-live date for the new system AND a shutoff date for the old one, both on the same calendar, both owned by someone with the authority to enforce them.
• A monthly cost report that shows both systems side by side, visible to you directly. If the report doesn’t exist, the cost is invisible, and invisible costs never get fixed.

Auditing Your Current Migration Debt and Prioritizing Completion

Before your next planning cycle, run this audit. It takes a week, not a quarter. If you don’t have the internal cycles to map this out, our Infrastructure and Architecture Review Service will identify and quantify your migration debt for you.

• List every migration started in the last three years. Not just the big ones; include the “small” internal tool switches too. They add up.
• For each one, ask one question: is the old system fully off? Yes or no. No half-credit for “mostly.”
• For every “no,” find out what percentage of traffic or usage is still on the old system. Anything under 10% is usually the cheapest debt to close and the highest-leverage place to start.
• Calculate the real dual-run cost, licenses, headcount, support contracts, security overhead, for each unfinished migration. Rank them by cost, not by how long they’ve been open.
• Pick the two cheapest-to-close migrations and fund their decommission this quarter. Momentum matters more than starting with the biggest one.
• Put migration debt on your quarterly business review, the same way you track revenue or churn. If it’s not on that agenda, it will never compete for budget against new initiatives, and it will keep losing.

Unfinished migrations aren’t a technical problem sitting in a backlog. They’re an operating cost you’re already paying every month, whether or not anyone’s tracking it. The fix isn’t more engineering effort. It’s a decision: set the shutdown date, fund the last mile, and hold someone accountable for hitting it. Contact us today to see how our platform engineering team can help you execute the last mile and finally turn off your legacy systems.