Successful Software Rewrites: What They Actually Have in Common
Search for successful software rewrites and you will mostly find people defending one. Be precise about what "successful" means here, because the projects that worked share a trait: from the outside they did not look like rewrites at all.
Khan Academy moved off Python 2.7 without a cutover
Khan Academy is the cleanest public example. Their backend ran on Python 2.7 and Google App Engine support was approaching end-of-life, which is a forcing function rather than a preference. The system had to evolve while continuing to serve millions of users.
They did not rewrite it. They used the strangler-fig pattern with an unusually cautious cutover. When the team believed a field was ready to migrate, the strangler made two calls: first to the original Python system, second to the new Go system. It returned the Python value immediately, then asynchronously compared the two responses and logged every disagreement. That let them verify 100% of requests in production for weeks before and after switching each request from Python to Go.
That is a boundary, a way to prove the change safe, and control over when users meet the new code. It was not free: begun in late 2019, the migration remained a primary engineering focus for years. But the work shipped continuously and users never felt a cutover.
The pattern is not software-specific
Madison Square Garden underwent a roughly billion-dollar renovation across three consecutive offseasons from 2011 to 2013 — seating, concourses, audiovisual systems, locker rooms, infrastructure. The constraint was simple: it had to remain operational throughout. Work was phased around the sports calendar and compressed into summer closures, so the Garden never missed a Knicks or Rangers season. The result was not a new arena but a substantially modernized one, delivered in increments.
The Santiago Bernabéu went further (retractable roof, new façade, 360-degree video board, retractable pitch) and hosted matches through most of a 2019–2024 rebuild. The exception proves the rule: when the pandemic emptied stadiums anyway, Real Madrid moved home matches to its training-ground stadium for a season and used the crowd-free window to accelerate the heaviest structural work.
When shutting down is not an option, iterating is the only strategy left.
A rewrite and its alternative, run on the same system
One of the more useful comparisons in The Rewrite Trap is a case where both approaches were tried on the same software.
A SaaS company's main reporting system had four problems: reports could take over five minutes to return; the metrics were seven years out of date; the UI was several iterations behind the rest of the site; and the technology was a mix of server-side PHP and Ember while everything else had moved to React.
Those four problems formed what the authors call musketeering: all for one and one for all, fix everything or fix nothing. No point fixing performance because the report returns the wrong data. No point adding metrics because the design is out of date. No point updating the design because there is no upgrade path. No point updating the technology because it fixes neither performance nor data. Musketeering is the ultimate in tight coupling. Every problem is chained to the others, so the only apparent moves are replace nothing or replace it all.
The team's plan: Snowflake, Kafka, a new Java service, a React UI. Ready for beta in six weeks. None of the technology was new to the company, so the rewrite would be "nothing but extending existing systems."
Jeffrey's alternative was smaller and less dignified: extract REST endpoints from the server-rendered reports, build the new React UI against the existing data model, release the facelift, and ask customers what they cared about most. The manager described it as "frosting a turd and iterating toward a cupcake," and Jeffrey agreed. The company was serving turd today, had been for years, and would be throughout the rewrite. The least it could do was add frosting.
What happened: the rewrite missed six weeks, then six months. Beta customers liked much of it, and did not care about some of the hardest features. Some calculations disagreed between old and new reports, so the team had to debug both to find out which number was right. Then the first real release went to the top 1% of customers by data volume, who were impressed. Until the bill came. Supporting that 1% cost 20x what had been budgeted for everyone. It could not be rolled out, and could not be kept running.
Ten months in, the salvage plan reused what the rewrite had produced. The new React UI did not care whether it talked to Java-and-Snowflake or PHP-and-MySQL, and the data transformations already worked out could be re-implemented as MySQL views. Two months later the new UI shipped to the smallest 80% of customers. Four months after that, 90%. A different database technology later took it to 98%, within budget.
What separates the successes
- Nothing rides on a single launch. Every successful case above has many small reversible releases instead of one irreversible one.
- Correctness is proven before it is trusted. Parallel runs, logged disagreements, and comparison against live traffic do the work that a QA sign-off before a cutover only pretends to.
- The business never stops. Khan Academy served users throughout. The Garden never missed a season. The reporting customers got a better UI while the deeper work continued.
- There was a real forcing function. Khan Academy faced end-of-life on its platform. That is a business case. "The code is unpleasant" is not.
- They took years and everyone knew it. None of these were fast. The difference is that value arrived throughout instead of at the end.
What each approach cost
The reporting story is the honest version of what "successful rewrite" usually means. Neither approach replaced the old system in six weeks, nine months, or eighteen. What separates them is the bill along the way. The iterative path improved the customer experience quickly. The rewrite never fully reached production, and its failure took the managers, then the developers, then the executive sponsor. Within six months it was an entirely different team.
Rewrites consume people, teams, and sometimes entire organizations. The technical failure is the cheap part.
