In most cases, the answer is: migrate gradually, rather than rewriting everything from scratch. A ‘big bang rewrite’ looks great on a slide, but in practice it means years of work, a freeze on business development, and a real risk that the new system will never catch up with the old one. The ‘strangler fig’ approach – gradually replacing parts of the old system with new ones until the old one ‘dies out’ – allows for modernisation on the fly, without halting business operations and with the option to back out at any stage. A rewrite can sometimes be justified, but less often than one might think. Below, we explain when each approach makes sense and what conditions must be met for a gradual migration to actually succeed.
Two myths that cloud the decision
Discussions about modernisation usually get bogged down by two false assumptions. The first: ‘This system is beyond saving; we need to rewrite the whole thing.’ The second, the opposite: ‘It works, so we’ll leave it as it is.’ Both are pitfalls.
The first approach leads to a costly overhaul, which all too often results in the budget being exceeded and the project being abandoned. The second ignores the fact that technical debt does not stand still – the risk of failure increases, knowledge of the system is lost, and requirements such as DORA begin to demand things that simply cannot be demonstrated on an old, undocumented stack. The real choice isn’t ‘rewrite or do nothing’. It’s ‘which modernisation path to take so as not to disrupt the business’.
Why does a big-bang rewrite so often fail?
Rewriting the entire system from scratch has a number of inherent drawbacks that only become apparent as the work progresses.
Functionality freeze. For months, and more often years, the new system does not match the old one in terms of functionality. The business waits, but the competition does not. This is the most costly aspect of a rewrite, although it does not appear in the budget.
The hidden logic that nobody has written down. The old system contains hundreds of business rules developed over the years – in Delphi, VB6 or the old Java EE. When rewriting the code from scratch, it’s easy to lose track of them, as they aren’t recorded in any documentation, only in the code itself. This can result in subtle errors that only come to light once the system goes live.
The ‘second system’ effect. A team that is given the chance to ‘get it right this time’ has a natural tendency to over-engineer the project and add features that nobody needs. The scope swells, and the deadline slips further away.
One major switchover point. An ‘all-at-once’ migration means a single day on which all traffic is switched over to the new system. This also represents a single major point of failure, which is very difficult to roll back safely.
What is a strangler fig?
The name comes from the strangler fig, which gradually wraps itself around a tree until it dies. In IT modernisation, it works like this: you build new functionality around the old system and redirect traffic to it bit by bit. The front-end or routing layer determines whether a given request is handled by the old or the new component. Over time, more and more traffic is routed to the new system, until the old system can finally be taken offline.
Two elements are key here. The façade, which controls the flow of traffic and allows it to be switched over gradually. And the anti-corruption layer, which acts as an intermediary between the old system’s model and the new one, so that the new code does not inherit all the flaws of its predecessor.
The advantage is fundamental: you deliver value incrementally, the risk is spread across many small steps, and you can pull out at any stage. The business keeps running because there’s never a ‘big switch-over’ moment.
The conditions without which a phased migration will not succeed
The strangler fig isn’t magic. It has a few strict prerequisites.
Zrozumienie tego, co przenosicie. Nie da się bezpiecznie „stranglować” systemu, którego nikt nie rozumie. Podstawą jest aktualna dokumentacja architektury oraz inwentaryzacja procesów, która pokazuje, które funkcje są krytyczne i jak systemy są ze sobą powiązane. Bez tego przenosicie logikę w ciemno.
Isolable components. It must be possible to isolate modules or domains that can be replaced independently. The Event Storming method helps to define these boundaries in line with actual processes, rather than a random division of the code.
Testability and flow control. To switch between sections safely, you need test coverage and the ability to control what goes to the old component and what goes to the new one.
Discipline. The greatest risk with a strangler fig is leaving a ‘temporary’ dual setup in place permanently. The migration must have a clear end goal: to decommission the old system, not to maintain both indefinitely.
When, however, does a rewrite make sense?
Rewriting from scratch can sometimes be the right choice, but only in specific circumstances. When a platform or technology is no longer supported and cannot be meaningfully integrated with the new code. When the system is small enough that rewriting it costs less than setting up a phased migration. Or when the business model changes fundamentally and the old rules are going to be scrapped anyway.
Even then, one rule applies: first, reconstruct your understanding of the old system. Otherwise, you’ll simply copy it out, losing the rules that were precisely what made it work.
How to decide
The practical approach is simple. Start with visibility – work out exactly what you have and which processes are critical. Assess whether the system can be broken down into isolatable parts and what risks each of them entails. Choose the smallest, most valuable first step that can be safely implemented and, if necessary, rolled back. Make gradual migration the default approach; treat a rewrite as a deliberate exception, not as a starting point.
At Finture, we start by regaining an understanding of the system: automated, always up-to-date architecture documentation (S*.doc) and a process inventory provide a roadmap on which we can plan a safe sequence of steps. Based on this, we design and implement the modernization as a custom solution, step by step, without disrupting business operations.
FAQ
What is a strangler fig?
When is it better to rewrite a system from scratch rather than migrate it gradually?
Why is a ‘big-bang’ rewrite risky?
What is needed to migrate a legacy system safely?
Is a phased migration slower than a full migration?
Are you wondering whether your system in Delphi, VB6, or legacy Java EE is suitable for a phased migration or whether it needs to be rewritten? Let's talk—we'll start with a system map, not with a predetermined answer.
