4eBusiness GmbH – home
Historic red-brick factory hall at dusk, partly covered in scaffolding, with a modern glass-and-steel extension and a construction crane; work carries on behind the windows

Refactoring or rewrite? What executives should know about legacy systems

Improve step by step or rebuild from scratch? How to recognize the right path for your legacy system, and why a radical fresh start succeeds less often than it promises.
Legacy modernizationRefactoringTechnical debt

Marc AntwertingerManaging Director

Published
Reading time
7 min

Almost every company has one: a system that has run reliably for many years, that nobody likes to touch and that only a handful of employees still understand in detail. By the time small changes take months or the platform it runs on no longer receives security updates, the question can no longer be put off: refactoring or rewrite?

The desire for a clean fresh start is understandable, but it is one of the riskiest decisions in IT. This article shows what a legacy system really costs, when incremental modernization pays off, when a rewrite is justified and why the best solution often lies somewhere in between.

What a legacy system really costs

Age alone is not the problem. In his classic Working Effectively with Legacy Code, software expert Michael Feathers defines legacy code simply as “code without tests.” What matters, then, is not the year a system was built but whether it can be changed safely. Without that safety net, every change becomes a gamble. Releases become less frequent, development takes longer, and knowledge is concentrated in a few heads.

This technical debt has a price. In a 2020 McKinsey survey of 50 CIOs at large financial services and technology companies, respondents put their technical debt at 20 to 40 percent of the value of their entire technology estate before depreciation. They also reported that 10 to 20 percent of the budget for new products was diverted to dealing with legacy issues instead of innovation.

Then there is regulation. Germany's NIS2 Implementation Act has been in force since December 6, 2025. It requires the companies within its scope to take security measures when maintaining their IT systems, “including vulnerability handling and disclosure”* (Section 30 BSIG). Management must implement these measures and monitor their implementation (Section 38 BSIG). A legacy system without security updates thus becomes a matter for top management.

Refactoring: modernizing while the business keeps running

Martin Fowler, author of the classic Refactoring, describes refactoring as a change made to the internal structure of software “to make it easier to understand and cheaper to modify without changing its observable behavior.” In other words, the system is not replaced but cleaned up step by step. Tangled modules are separated, outdated libraries swapped out, frameworks upgraded to current versions. Automated tests safeguard every step; often they have to be written first.

For company leadership, this route has tangible advantages. The risk stays low because each change is manageable and can be reversed. The system continues to deliver value, the domain knowledge stored in the code is preserved, and the budget can be managed in stages. Refactoring reaches its limits when the foundation no longer holds: when the programming language or platform has no future, or when the business model has changed so much that the system's basic structure no longer fits. At that point, you are merely renovating a facade while the real problem remains behind it.

Rewrite: the tempting fresh start

A rewrite promises modern technology, a clean architecture and an end to all legacy baggage. In April 2000, software entrepreneur Joel Spolsky dissected this dream using the example of Netscape. The browser maker had decided to rewrite its code from scratch. To Spolsky, this was “the single worst strategic mistake that any software company can make.” By then, the last major release was almost three years old, and Netscape, as Spolsky put it, “sat by, helplessly, as their market share plummeted.”

His core argument still holds today: old code looks messy, but it is full of experience. Behind many an odd-looking line lies a bug fix, and each of these bugs, Spolsky writes, “took weeks of real-world usage before they were found.” A rewrite throws this knowledge away. Then there is the second-system effect that Fred Brooks described as early as 1975 in The Mythical Man-Month: with the successor system, teams want to make up for everything that fell short the first time, and the scope keeps growing. Meanwhile, the legacy system still has to be maintained, often with new requirements that keep moving the rewrite's target.

Switching over in a single step, known as a big bang, is particularly risky. In April 2018, the British bank TSB migrated to a new IT platform. Immediately afterwards, there were massive disruptions in its branches and in telephone, online and mobile banking, affecting a significant proportion of its 5.2 million customers. The bank did not return to business as usual until December 2018. In 2022, the UK regulators FCA and PRA fined it a combined £48.65 million. “The failings in this case were widespread and serious,” said Mark Steward, then Executive Director of Enforcement and Market Oversight at the FCA.

Strangler fig in the rainforest, its pale aerial roots wrapped like a net around the trunk of an old host tree
Namesake of the strangler fig pattern: a strangler fig envelops its host tree and eventually outlives it. (Image: AI-generated)

The third way: incremental replacement

Between renovation and demolition lies an approach that Fowler named after a plant whose growth he observed on vacation in Queensland, Australia: the strangler fig. It germinates in the crown of a host tree, sends its roots down the trunk into the soil and eventually outlives its host. Applied to software, this means placing an interface in front of the legacy system and using it to redirect one function after another to new components. The old system shrinks until it can be switched off.

Fowler's reasoning is down to earth: “Replacing a serious IT system takes a long time, and the users can't wait for new features.” He and his colleagues have seen the simple-sounding plan of building an exact replacement “go down in flames most of the time.” A gradual approach, by contrast, makes “both investment and returns occur gradually and visibly.” For management, this is the crucial point: every stage delivers usable results, and the project can be reprioritized without losing money already invested.

Modern tools change this calculation only in part. AI assistants now help to make sense of undocumented code and to add missing tests. But they relieve no one of the fundamental decision or of responsibility for the result.

How to recognize the right path

Five questions are usually enough to assess the situation. Is the system's business logic still correct, or has the business changed fundamentally? Are the programming language, frameworks and platform still maintained? Are there tests, documentation and people who understand the system? Can it be broken down into parts that can be replaced individually? And how long can the company do without new features?

If the logic and the technical foundation are sound, refactoring is almost always the more economical route. If the foundation is outdated, there is hardly any way around a rewrite. It should then follow the strangler fig principle, however, not a big bang. A rewrite in one go is only justifiable for small, well-understood systems whose failure would not put the business at risk.

Conclusion: a business decision

Refactoring or rewrite is less a technical question than a business one. It is about risk, tied-up capital and speed. In most cases, the winner is not the radical cut but continuous, well-planned modernization that preserves what works and builds new things where they deliver the greatest benefit.

This requires an honest picture of the current state, from code quality and dependencies to the security situation. This is exactly where 4eB comes in. As part of our IT consulting, we analyze systems that have grown over the years and work with you to develop a modernization plan that fits your budget and business goals. As your partner for software and app development, we then put it into practice: through refactoring, version upgrades or the incremental replacement of individual components – without jeopardizing day-to-day operations.

Sources

* Our translation of a quote from a German-language source. The images in this article are AI-generated.

We'll work with you to determine whether refactoring, incremental replacement or a rewrite is the right path for your system – free of charge and without obligation.

Want to modernize your legacy system with a clear plan?

More articles