This article explains what both approaches involve, when each makes sense, and provides a practical framework for determining which path fits your circumstances best. If you are still working out whether your system qualifies as legacy in the first place, start with our guide to what a legacy system is.
Two Approaches, Briefly Defined
Modernise means improving or updating an existing system incrementally, layer by layer, without switching it off. The core logic stays in place while interfaces, integrations, and infrastructure are brought up to date.
Rewrite means building a replacement from scratch in new code, then migrating away from the old system. The existing codebase is not our starting point; it's exactly what we're getting replaced.
A third option — replace with off-the-shelf software — is worth keeping in the frame. For some businesses, a well-configured commercial product is faster, cheaper, and lower risk than either approach above.
What Do We Mean by Rewrite vs. Modernise?
The terms get used loosely, which causes confusion when businesses try to scope a project or compare quotes from different suppliers.
Modernisation covers a wide range of interventions: replacing an outdated front end while keeping the database intact, building integrations that allow an old system to communicate with modern tools, re-platforming to cloud infrastructure without rewriting application logic, or updating a system module by module over time. The guiding principle is that you work with what exists rather than replace it wholesale.
A software rewrite is categorically different. First, you build a new system, then transition to it. The old system either runs in parallel during the transition or gets switched off when the new one is ready. Nothing carries over automatically, which means data needs to be migrated, business logic requires reconstruction, and every workflow is up for re-implementation.
Legacy system modernization (to use the US spelling that dominates much of the available research) covers both approaches depending on context. When suppliers talk about it as a service, they usually mean modernisation in the incremental sense. When a business says, "We need to modernise," they may be referring to rewriting without realising the difference. Understanding the distinction before you scope the work saves significant time and money.
The Case for Modernising
Incremental modernisation is the right course of action in a greater number of situations than most businesses expect, including instances where the system feels too old or too broken to bother with.
The core architecture still has value. If the fundamental data model, the business logic, or the processing that sits at the centre of the system is sound, tearing it out and rebuilding it from scratch destroys real value. The parts that are causing problems, such as the interface, integrations, and reporting layer, can often be replaced independently. This is where modernisation is not just cheaper but genuinely better.
The business cannot absorb major disruption. A full software rewrite requires a period where two systems run simultaneously, or a very risky hard cutover. For a business processing orders, managing stock, or running client-facing operations, either scenario is a serious constraint. Modernisation allows the business to keep running throughout.
The investment case for a full rewrite is hard to justify. McKinsey & Company research found that tech debt can account for up to 40% of the total value of an organisation's technology estate. The maintenance burden is real. Rewriting, on the other hand, costs a lot up front and doesn't guarantee a return, while modernisation makes small improvements over time at a more predictable cost.
The team understands the system. Institutional knowledge about how a system works, including the nature of edge cases, the location of business rules, and the reason why certain things are handled the way they are, is very valuable. Modernisation preserves that knowledge, while rewriting starts from zero and risks losing it entirely.
The Case for Rewriting
In some cases, the best thing to do is to completely rewrite the software. But it is a mistake to treat it as the default for any system that appears antiquated.
The foundation is genuinely beyond repair. Working around some systems is more expensive than replacing them. The reason for that is the technical debt they have accrued over the years from patches on top of workarounds on top of workarounds. When the cost of each new change is measured in weeks of specialist time and the risk of breakage is high with every update, the economics shift. For a fuller picture of how that accumulation happens, see our guide to technical debt.
The platform or language is dead. Systems built on technologies that no longer have active developer communities or vendor support present a particular problem. You cannot modernise around a foundation that is incapable of being maintained. If the core is built on something that has no viable path forward, the options narrow considerably.
The business has changed fundamentally. A system designed to support a business model that no longer exists will not modernise well. If what the business does now is very different from what the system was built to handle, such as different processes, a different scale, or a different commercial model, you are trying to adapt something to a purpose it was never meant to serve.
The original supplier has disappeared. Bespoke software built by a development house that no longer exists, with no documentation and no surviving codebase knowledge, leaves limited options for incremental improvement. In some of these situations, rewriting from documented requirements is more practical than reverse-engineering what was there.
The honest qualification: even when a rewrite is justified on technical grounds, it remains a high-risk undertaking. According to the Standish Group's CHAOS research, large IT projects succeed less than 10% of the time. A rewrite that runs longer than expected, which most do, compounds cost and risk with every passing month, leaving a business to maintain two systems simultaneously while the new one is not yet ready.
The Risks Nobody Talks About
In 2000, Joel Spolsky published "Things You Should Never Do, Part I" about Netscape's decision to rewrite its browser from scratch. The rewrite took three years, burned enormous resources, and handed market share to competitors. His central point: the messy, hard-to-read code in a legacy system often encodes years of bug fixes and business logic that is invisible until you try to replicate it and discover it is missing.
This is the risk of a rewrite that does not appear in project plans: the loss of accumulated business logic. Every workaround, every edge case handler, every undocumented rule the system quietly enforces — these represent real operational knowledge. A rewrite built from stated requirements will miss most of them, because nobody knows they exist until the new system fails to handle them.
The second risk is dual maintenance, which we've briefly mentioned above. During any rewrite of a meaningful scale, the old system continues to run and still requires fixes, updates, and security patches. The business is paying to maintain two systems while only one is generating value. On top of it all, this process usually takes longer than anticipated.
The sunk cost problem runs in the other direction, too. Businesses sometimes continue investing in modernisation of a system that is beyond saving. The reason is that they have already spent a lot of money on the project, so stopping feels like a waste. It's critical to calculate not what has been spent but what continuing to spend will allow to achieve.
A Decision Framework: Which Path Is Right for You?
The answer depends on your specific situation. These questions are designed to help you think through it systematically.
How sound is the core architecture?
If the fundamental structure of the system — the way data is organised, the core processing logic, the database design — is still fit for purpose, modernisation is usually the better route. The problems at the surface can be addressed without touching the foundation.
If the core architecture cannot support what the business needs — cannot scale, cannot be extended, cannot be made secure without fundamental reconstruction — then modernisation is building on sand. A rewrite becomes more defensible.
Can your business tolerate disruption during the transition?
Modernisation keeps the business running throughout. Each change is incremental and reversible. There is no moment where everything stops.
A rewrite requires either a parallel running period — expensive and complex — or a hard cutover where the new system goes live and the old one is switched off. If your tolerance for operational disruption is low, that is a meaningful constraint on the rewrite option.
What is your realistic timeline?
Modernisation delivers results in stages. Early phases can show tangible improvement within weeks. The full programme may take a year or more, but the business sees progress throughout.
A rewrite delivers nothing until it is finished. For a system of any meaningful complexity, that is typically measured in months at minimum, often longer. If you need to show progress or meet a deadline, a rewrite rarely fits the timeline.
What does your budget actually allow?
Modernisation costs are more predictable, since each phase has a defined scope and cost. If budget runs out, you stop at a logical point with a system that is better than it used to be.
A rewrite involves a large number of unknowns and an upfront commitment to the full cost. Scope tends to expand during discovery, timelines slip, and the final cost of most rewrites exceeds the original estimate. If your budget has a firm ceiling, that is a serious limitation. Before committing either way, it is worth building the financial case for legacy system modernisation so the comparison is grounded in real numbers rather than estimates.
How well is the existing system documented?
If the system has good documentation, such as clear specifications, known business rules, and documented workflows, a rewrite has a reasonable chance of reconstructing what exists. If documentation is poor or absent, a rewrite will almost certainly miss significant operational logic that currently lives only in the code. The less you know about what the system actually does, the higher the risk.
Real-World Scenarios
The three scenarios below are illustrative — composite examples based on patterns that come up regularly in UK SMBs, not documented case studies of specific companies.
Where modernisation was the right call
A UK professional services firm had been running a client management system for a solid few years. The interface was outdated, it could not connect to their new document management platform, and onboarding new staff took weeks. The underlying data model and business logic were sound. There were fifteen years of client records, billing history, and workflow rules that accurately reflected how the business operated.
Incremental modernisation replaced the front end, built the integration, and updated the reporting layer, while the core stayed in place. The project took six months, and the business ran normally throughout. A rewrite would have taken longer, cost more, and risked losing embedded business logic. The same principle applies when the underlying store is a bespoke desktop database — see our guide to replacing an Access database without losing business logic.
Where a rewrite was justified
A logistics company had built a bespoke route planning and dispatch system ten years earlier. The development firm no longer existed, there was no documentation, and the system ran on a platform that had been end-of-life for four years. It could not connect to any modern mapping or fleet management tools without a complete rebuild of the integration layer.
A rewrite was the right decision, not because the system was old, but because there was no viable path to extend it. It was meticulously scoped, operated for six months concurrently with the old system, and featured a structured programme to capture the business logic that was solely present in the code.
Where a hybrid approach worked
A manufacturing business needed to modernise its production planning ERP. A complete rewrite was too costly and disruptive, and a full modernisation was not possible because the reporting module was permanently broken and actively causing operational problems.
The business chose to rebuild the reporting module from scratch while modernising the rest incrementally. The most critical broken component got a rewrite; the functional parts got modernisation. This hybrid path suits many real SMB situations more than either option taken to its extreme.
The Middle Ground: When Both Approaches Combine
The most practical path for many SMBs is neither a full rewrite nor pure incremental modernisation. It is a combination, applied intelligently to different parts of the system.
Software engineers call this the Strangler Fig pattern, a term coined by Martin Fowler. The name comes from a tree that grows around an existing structure over time, eventually replacing it. In terms of software, you add new parts to the old system and gradually move functions to them until the old system is completely replaced and never turned off all at once.
For a business leader, the practical implication is straightforward. You identify the parts of your system causing the most pain or carrying the most risk, and address those first — whether that means modernising them or rebuilding them. The parts that are working adequately get left alone or improved incrementally. Over time, the legacy system is replaced piece by piece rather than all at once.
This approach is slower than a full rewrite and more complex than a straightforward modernisation. That being said, it has a lot less risk than either of them, gives value over time instead of just at the end, and keeps the business running the whole time. For most UK SMBs weighing up legacy software modernisation, it is the path worth understanding in most detail before committing to either extreme.
For context on what the modernisation process looks like in practice, see how we work.
Key Takeaways
- Modernise when the core architecture still has value, the business cannot absorb major disruption, and the problems are at the edges of the system rather than the foundation.
- Rewrite when the foundation can't be fixed, the platform is dead, or the business has changed so fundamentally that adapting the existing system is not viable.
- Both approaches carry risks that are routinely underestimated: rewrites lose embedded business logic; modernisation can become sunk cost investment in a system that cannot be saved.
- A hybrid approach, i.e., rebuild the most broken parts, modernise the rest, often carries less risk than either option taken to its extreme.
- The decision depends on your specific situation: the state of your architecture, your tolerance for disruption, your timeline, and your budget.
If you have read this and are still not sure which path fits your situation, that is a reasonable place to be. The right answer usually requires looking at the specifics of what you have. That is exactly what a discovery conversation is for.