Legacy software: when to modernise and when to rewrite

In many cases legacy software is better modernised step by step than rewritten from scratch in one go. A full rewrite only makes sense in specific situations: when the technology no longer lets you make changes safely, when the software no longer reflects how you work, or when every change has become disproportionately expensive. Often the safer path is a different one: understand what you have, secure the critical parts and replace whatever no longer holds up, piece by piece, without stopping the business.

What makes software legacy?

Legacy doesn’t just mean old. Software is legacy when the business depends on it to operate but it has become hard to change or maintain. It can have been running for many years and be in excellent shape, or be fairly recent and already a problem, because it was written in a hurry, without tests or documentation.

The point isn’t age, it’s the balance between how much you rely on it and how risky it is to touch.

Signs your system is becoming a problem

• Every release is nerve-racking: updates are kept to a minimum, and when they happen something breaks elsewhere.
• Outdated dependencies: versions of the language, framework or database that are no longer supported, sometimes no longer installable on modern servers.
• Declining performance as data grows.
• Missing or thin tests: nobody knows for sure what happens when a line changes.
• No documentation: the business rules live only in the code or in someone’s head.
• The original developer is no longer available, and whoever takes over has to reconstruct everything.
• Changes are stuck: simple requests, such as a new field or a connection to another system, turn into long, uncertain jobs.

One sign alone isn’t enough to decide. The more of them add up, the more it’s time for a proper assessment.

The options compared

Option one: keep maintaining it

This is a legitimate option and often an underrated one. If the software is stable, does what you need and change requests are rare, maintaining it may be the most sensible choice. But maintaining doesn’t mean ignoring it: update critical dependencies, keep tested backups, know where the credentials are and how to get the system running again if the server fails.

Option two: incremental refactoring

Refactoring means reorganising the code without changing what it does. You work in small steps: add tests around the most delicate parts, separate responsibilities, replace outdated dependencies. Each change is released and checked before the next one.

It’s the right path when the basic structure holds up but the code has become hard to read and change. Its limit is that it doesn’t change the underlying technology: if that’s where the problem is, refactoring alone won’t solve it.

Option three: rewrite

Rewriting means building new software to replace the old one. It makes sense when the technology is no longer sustainable, when the way the business works has changed so much that the old model no longer fits, or when every change costs more than it’s worth.

Even then, how you rewrite matters a great deal.

Why a full rewrite can be risky

The “big bang” rewrite, where you work on the new system for a long time and then switch off the old one on a given day, carries real risks:

• Implicit logic: software that has run for years contains rules nobody remembers any more, added to handle a particular case. If they aren’t identified, they vanish in the new system.
• Regressions: things that used to work stop working, and often you only find out after the switch.
• Running two systems: while the new one is being built, the old one still has to be maintained and perhaps changed. Every change has to be made twice.
• Cut-over: switch-over day concentrates all the risk, data included, into a single moment.
• Late value: until the new system is complete, the people using it see no benefit.

Incremental migration and the strangler pattern

The strangler pattern is a well-known way to rewrite without a big bang. You identify clear boundaries in the existing system, such as customer management, bookings or invoicing, and replace them one at a time. Each new module takes over the corresponding part of the old system while the rest keeps running. Over time the old system shrinks until it can be switched off.

It means the two systems have to coexist for a while, so you need well-defined boundaries and a reliable way for them to communicate: this is often where APIs and software integrations come in. In return, every step can be verified and the risk is spread out.

Databases and data migration

Data is often the most valuable part of a legacy system, and the most delicate. Before promising that “everything will be kept”, you need an analysis: how the database is structured, how clean the data is, whether there are duplicates, fields used differently from how they were designed, information stored in non-standard formats.

Migration is usually prepared with repeatable scripts, tested several times on copies of the real data and checked together with the people who use the system every day. If the transition is gradual, data may also need to be synchronised between old and new for a period.

How to assess an existing application

When someone asks me to work on existing software, I always start with an analysis of the code and the system before proposing any route. What I look at:

• Access to the source code: is it available, complete and in line with what’s running in production?
• Reproducibility: can the system be installed and started in a test environment?
• Dependencies: which versions, how outdated, which have known security issues.
• Data: database structure, data quality, existing backups.
• Tests and logs: what’s already checked automatically, what you can see when something goes wrong.
• Critical areas: which parts are essential for day-to-day work and which can be touched with less risk.
• Continuity: what happens if the system stops, and how long the business can manage without it.

The outcome is a picture of what’s there, what’s at risk and which options are realistic, with clear priorities. The decision stays yours, but it’s made on concrete evidence.

When I would recommend keeping the system

There are cases where I’d advise against a rewrite:

• the software does its job well and the problems are localised;
• the difficulties come from a few areas that can be isolated and fixed;
• there’s no clear process to start again from, and a rewrite would risk reproducing today’s confusion on new technology;
• the business can’t afford a transition period right now.

In these cases maintenance or incremental refactoring deliver more value with less risk, and leave the door open to replacing individual parts later.

If you’re weighing up what to do with your software, see how I handle maintenance and evolution of existing software or get in touch for an assessment of your current system: before replacing everything, let’s assess your existing software and its evolution options. If you’re considering a new system instead, it may help to understand what drives the cost of custom management software.

Frequently asked questions

How much does it cost to modernise software?

It depends on the state of the code, the amount and quality of the data, how many modules need work and the route you choose. That’s why the first step is an analysis: without knowing the system, any figure would be a guess.

Can you change technology gradually?

Yes, and it’s often the safer choice. With an incremental migration you replace one module at a time, running old and new side by side until the old one is no longer needed.

Can the data be kept?

Often yes, but it shouldn’t be taken for granted: it first needs an analysis of the database and data quality, followed by trial migrations on real copies.