In the world of digital transformation, few phrases are as misleading as 'the migration is 80% complete.' This statement, repeated in countless executive presentations, hides a much more complex reality: the true success of a migration process is not measured by how many new systems have been launched, but by how many old systems have been turned off definitively. Over two decades of experience working with companies of all sizes has taught us that the last 20% of any migration concentrates the greatest risks, hidden costs, and organizational decisions that determine whether the project will be a success or a long-term financial burden.
When an organization declares that 80% of its workloads have been migrated, what it usually means in practice is that 80% of applications already have a new home: containers running, pipelines green, dashboards impeccable. However, the legacy environment remains operational because a handful of critical processes—a nightly batch job nobody remembers who created, a reporting extract finance needs on the third of every month, two integrations with a partner whose contract renews next year—still depend on the old infrastructure. The result is that the company pays twice: for the new platform and for the old one. Not just in infrastructure, but in two on-call teams, two sets of security patches, two audit trails, and costly synchronization work between both worlds. This double-run layer, which rarely appears in the original business case, becomes the most fragile code in the entire program and one of the biggest generators of hidden technical debt.
This phenomenon, which we could call the 'double-run tax,' is especially dangerous because nobody budgets for it. The business case was built on the savings that would be achieved once the old system disappeared. If the old system never disappears, the business case was fiction. And yet, the program is quietly declared a success because 80% of something was moved. To avoid this, the correct metric is not 'percentage migrated,' but 'legacy systems shut down.' Every month both environments coexist, the company accumulates an operational cost that erodes the expected return on investment. That is why at Q2BSTUDIO we advocate that a migration is only complete when the last old server is disconnected, not when the new one starts working.
The real obstacle of the last 20% is not technical, but archaeological. The applications left behind share a common trait: nobody knows exactly what they do. Those who wrote them are no longer with the company; the documentation, if it exists, describes an intention from ten years ago that the code stopped honoring seven years ago. Business logic is hidden in stored procedures, in schedulers nobody logs into, in config files with comments like 'do not touch, ask Raj'... and Raj retired. You cannot rewrite what you cannot describe. The standard response—assign a senior engineer to do 'discovery'—usually becomes a six-week task per system, stretching the tail for years and eventually getting abandoned, keeping both platforms forever.
This is where generative artificial intelligence is demonstrating real value, but not where most people expect. It is not about using a model to rewrite a monolith into microservices—that is still a pipe dream—but about reading. A well-directed language model can process legacy code and deliver, in an afternoon instead of six weeks, an inventory of all external systems it communicates with, a list of all scheduled jobs, a plain-language description of what each stored procedure appears to do, and—most valuable—a list of every place where the actual behavior contradicts the documentation. That map, not the rewritten code, is the true asset. However, the model will also confidently describe behavior that does not exist, which in a migration is worse than no description at all, because someone will build against it. That is why in our projects we impose a rule: the model does not get to assert anything. It produces claims with citations: file, line, confidence level, and a pending verification status. Every claim that touches money, compliance, or customer state is verified against replayed production traffic before becoming a requirement. Thus, archaeology stops being the reason the program dies.
Once you know what the legacy system does, you still have to leave it. The classic approach—the 'big bang'—has a deservedly bad reputation: everyone knows it is a bad idea, but everyone does it because the alternative seems harder to plan. The alternative is to put a seam in. Have the legacy system emit an event for every relevant state change, and let the new service consume it. For a while, both systems are live: the legacy remains the source of truth for writes, and the new one builds its own state from the event stream, comparing the results silently, in production, on real traffic, until differences stop being found. Then you flip the write: the legacy becomes a consumer instead of a producer. Then you turn that off too. This strategy, slower on paper, is dramatically faster than the big bang once you count failed cutovers and rollbacks. It allows you to be wrong safely, discovering that the legacy rounds in a way nobody documented, or applies a discount rule that only fires for accounts created before a certain date. It is better to find that while the old system is still authoritative, not during a weekend cutover with the CFO on the bridge call.
The last step, and perhaps the most neglected, is decommissioning. It generates no demos, ships no features, has no visibility. When budgets get squeezed at month nine, the retirement workstream is always the first to slip, because slipping it has no visible cost this quarter. That is why in our methodology, decommissioning cannot be a phase at the end: it must be a funded workstream with a named owner from day one and a forcing function that lives outside the engineering org. A hardware lease that isn't renewed, a license that expires, a support contract with a hard end date. Something the program cannot quietly extend by three months in a steering committee.
At Q2BSTUDIO, specialists in custom software development and cloud services, we know that the metrics that really matter are: number of legacy systems completely retired, total double-run months accumulated (and whether that number is falling), percentage of production traffic still served by the legacy path, and the recurring cost of the old environment compared to the business case that funded the program. None of these metrics are flattering in year one. That is precisely why they are useful: the flattering metric is exactly the one that lets a program run for three years and end with two platforms instead of one.
After more than twenty years in the industry, we have reached a clear conclusion: the hard part of modernization is no longer architecture. The patterns are solved, the platforms are mature, and we can staff a team that will build a clean Kubernetes estate with proper pipelines and sane service boundaries. What has not gotten any easier is turning the old thing off. That is an organizational problem dressed as a technical one, and it does not yield to better architecture. It yields to somebody owning the kill date and being willing to be unpopular in month nine. The migration is not done when the new platform goes live. It is done when someone unracks the old system. And to achieve that, every company needs a technology partner who understands both the technical and human sides, who knows how to apply AI to unravel legacy systems, who integrates cloud services on AWS and Azure with cybersecurity and business intelligence, and who builds AI agents to automate event verification. Because in the end, technology is the means; the goal is to free the organization from the weight of the past.
