Here is a typical scenario that plays out quietly across the software industry. A company decides to modernize its aging SaaS platform using $25 million in funding. The plan is to finish the project in 18-24 months. Dozens of engineers are assigned. Four years later, the world it was designed for no longer exists, and the “modernized” platform is not ready to go live.
The project simply drifts, quarter after quarter, consuming money and talent, while competitors who started later ship faster. Eventually the “modern” platform arrives already dated, if it arrives at all. I call this “modernizing to yesterday”.
Let’s talk about why, and about what accountable modernization actually looks like in an era when technology moves faster than any four-year plan can survive.
This Is a Pattern, Not Bad Luck
The first thing to understand is that these failures are predictable. They are not freak accidents that struck one unlucky team.
The data is unambiguous. According to research by McKinsey and the University of Oxford, large IT projects run 45% over budget and deliver 56% less value than predicted. The Standish Group’s long-running CHAOS research is even starker: large projects succeed less than 10% of the time, while small projects succeed around 90% of the time. And critically, McKinsey found that each additional year a project runs increases its cost overrun. Time itself is a compounding risk, not a neutral resource.
Sit with that last point. The longer a modernization runs, the worse its economics get, automatically. A schedule that slips from 18 months to 48 months is not merely late. It is mathematically more likely to fail with every quarter that passes.
The Accountability Vacuum
This is the heart of the problem, and it deserves more attention than it gets. Multi-year rewrites do not just fail often. They fail without consequence, and the reason is structural.
A big-bang rewrite delivers no value until the end, which means there is no forcing function for honesty along the way. When a project ships nothing for years, there is no moment that exposes reality. Every status update is a projection, a slide, a percentage-complete estimate that no working software has ever tested. As one industry analysis of big-bang programs put it, the organization typically sees no tangible benefit until cutover, meaning 18 months or more of investment with nothing to show for it in the interim. You cannot hold anyone accountable to a result that has been deliberately deferred past the horizon.
The people reporting on the project are usually the people who chose its approach. When the architects and executives who committed to the multi-year rewrite are also the ones grading its progress, honest bad news becomes structurally unlikely. Admitting the plan is failing means admitting the original decision was wrong. So scope gets quietly trimmed, timelines get “re-baselined,” and the story stays optimistic long past the point where anyone believes it. Dissent from inside the team gets reframed as negativity or interference, precisely because it threatens the official narrative. The engineer or analyst who says “this architecture is too complex” or “the data model is not defined well” becomes a problem to manage rather than a signal to heed.
Sunk cost becomes a management strategy rather than a fallacy to avoid. Every dollar and year already spent becomes an argument for spending more. “We are 70% done” (a number no working software supports) is used to justify the next tranche of budget. The more that has been invested, the harder it becomes to stop, which is exactly backwards from how a healthy organization should treat a struggling bet.
And by the time failure is undeniable, accountability has evaporated. Four years is long enough for sponsors to move roles, for leadership to turn over, for the market to shift so much that the failure can be blamed on “changing conditions” rather than the original plan. The person who championed the approach is often gone or promoted and the organization absorbs the loss as a cost of doing business, and the pattern is free to repeat.
Why This Is Now Worse Than It Used to Be
The multi-year rewrite has always been risky. What has changed is the speed of the world it competes against.
Technology is improving faster than at any point in my career. AI-assisted development, mature cloud primitives, and off-the-shelf model capabilities have collapsed the time it takes to build serious software. Small teams now ship in months what used to take large teams years. Entire products are being built AI-native from day one and reaching billion-dollar valuations before a legacy incumbent’s rewrite would even reach cutover.
This creates a brutal new failure mode I think of as modernizing to yesterday. When your rebuild takes four years, you are not building toward the present. You are building toward your understanding of the world as it existed when you started. The architecture you locked in ages. The assumptions you froze go stale. The competitive bar rises while you are heads-down. You risk the worst possible outcome: not that you fail to finish, but that you succeed and ship something already obsolete on the day it goes live.
In a slow-moving market, a long rewrite is a gamble. In today’s market, it is a gamble against an opponent who gets faster every month you are not looking.
The Simplicity You Skip Is the Debt You Inherit
One more technical point that feeds directly into accountability. A recurring driver of these failures is unnecessary architectural complexity: elaborate designs, duplicated data stores, and services multiplied beyond what the problem requires. Complexity feels like progress. It looks impressive in a design review. But every layer you add is a layer you must build, integrate, test, and maintain, and it is a layer where the schedule can slip.
The industry’s hard-won answer to legacy modernization is not the heroic full rewrite. It is incremental, façade-based replacement, often called the Strangler Fig pattern, where you rebuild functionality slice by slice while the existing system keeps running, retiring old components only as new ones prove themselves. The simplest architecture that solves the problem almost always beats the most sophisticated one, because simplicity ships and complexity stalls. Choosing complexity you do not need is not just a technical mistake. It is a decision that makes accountability harder, because it pushes the day of reckoning further away.
What Accountable Modernization Looks Like
None of this means modernization is hopeless. It means the way most large rewrites are structured actively prevents accountability, and that structure can be changed. Here is what I would insist on:
Ship value on a short clock. If a modernization program cannot put something real in front of users within a few months, the plan is wrong. Not the timeline. The plan. Continuous delivery of working slices is the single best defense against multi-year drift, because it forces the truth into the open early and often.
Define kill criteria before you start. Every major program should have explicit, pre-agreed conditions under which it gets stopped or restructured. Without them, sunk cost runs the show. With them, “we are past our checkpoint and the metrics are not there” becomes a decision the organization has already committed to honoring.
Separate the graders from the players. The people evaluating a program’s health should not be the same people whose reputations depend on its success. Independent technical review, done by someone with no stake in the original decision, surfaces bad news while it is still cheap to act on.
Treat internal dissent as free consulting. When someone on the team says the architecture is too complex or the data model is wrong, that is not interference. It is your earliest, cheapest warning signal, delivered by someone who knows the system intimately. Organizations that punish that voice are paying for information and then throwing it away.
Assume the target is moving. Build in the expectation that requirements and technology will shift underneath you. Shorter cycles are not just less risky. They let you incorporate what is new instead of committing years in advance to what was current at kickoff.
The Real Cost
The money lost in a failed four-year modernization is real, but it is not the biggest number on the page. The biggest number is the one nobody writes down: the opportunity cost. Four years of your best engineers. Four years of market position surrendered to faster competitors. Four years during which the technology you could have adopted got dramatically better while you were busy building toward a plan you made before it existed.
That cost never shows up as a line item, which is exactly why it never triggers accountability. It is invisible, diffuse, and easy to blame on the market. But it is the cost that actually determines whether a company thrives or slowly falls behind.
The uncomfortable truth is that in a world moving this fast, the multi-year rewrite is no longer just an engineering risk. It is a bet that the future will wait for you to catch up. It will not. And the organizations that keep making that bet, with no checkpoints, no kill criteria, and no one answerable for the outcome, should not be surprised when they finish the race only to find the finish line has moved.
Sources: McKinsey & University of Oxford, “Delivering large-scale IT projects on time, on budget, and on value”; Standish Group CHAOS Report; “Why Big Bang Modernization Fails And What to Do Instead”; “When Big-Bang Modernization Makes Sense, and Why It Usually Doesn’t”.
Originally published on my blog site.