Modernise or rewrite an existing application?

An old application becomes hard to change, and the temptation is clear: start again. The code “no longer makes sense”, releases are frightening, one person holds the knowledge. A rewrite promises a clean system. It also promises months without visible value, then a cutover where the old and the new must agree about the data. That second part is usually the real subject.

Before choosing, name what is stuck. Not the feeling. The cost of the next change, the risk of touching the system, and what the business loses if nothing moves.

Why older applications become hard to change

Age does not explain it on its own. An old codebase that is understood, with tests on the rules that matter, can still be changed. What seizes up is the pile of decisions nobody wrote down.

Deployment is manual and nobody wants to touch it on a Friday. Business logic is split between a screen, a batch and a trigger. There is no reliable way to know whether a change broke a rare case. The development environment no longer looks like production. Dependencies cannot be updated without side effects.

Knowledge sits on top of that. If one person knows why a calculation is the way it is, every change waits on their calendar. The software is not only hard to modify. It is hard to hand over.

Signs that modernisation is becoming necessary

A few signals show up together:

• a small change takes a disproportionate amount of time, repeatedly;
• fixes create regressions on paths nobody had in mind;
• legitimate business requests are refused because “the system cannot do that”;
• workarounds — exports, double entry, local scripts — now carry part of the process;
• a release is an event, not a routine;
• the platform version is no longer maintained, and a security fix is waiting for that reason.

One of these signs does not justify a project. Several of them, on a tool that carries critical work, justify at least comparing the options. The problem is framed from the client’s side in modernising business software.

Option 1: keep maintaining it

Maintenance is a decision, not a failure. It is rational when the software still does the job, requested changes are rare, and the risk of touching it is higher than the cost of continuing.

It stops being rational when “we don’t touch it” becomes the default, including for a vulnerability or a business obligation. Maintaining still requires a minimum: knowing how to deploy, knowing who is responsible, having a usable copy of the data, and not depending on a machine nobody could rebuild.

If those conditions hold, the right move may be to document the few critical paths and put a repeatable deployment back in place, without opening a rewrite.

Option 2: modernise in slices

Modernising, here, means changing the system by zones while it keeps serving the business. The useful pattern is strangling: the new path takes over one specific case, the old one continues for the rest, and the boundary is explicit.

In practice that means a few levers, not a visual refresh:

• isolate a domain — a case type, a calculation, an integration — behind a stable interface;
• stop adding rules in the zone you have decided to leave;
• cover that zone with tests on the cases that hurt, before moving it;
• make deployment repeatable, often with cloud and operations, so each step can be reversed;
• switch over when the new zone holds in real conditions, not when it looks finished on a demo environment.

The pace is less spectacular than a rebuild. It ships a useful path before the programme is over, and it keeps the old system as a net until the figures agree.

Option 3: rewrite

A rewrite is justified when the underlying constraints make everything else too expensive. The data model cannot carry real cases without permanent contortion. The platform has no upgrade path left. Responsibilities are so mixed that isolating a zone costs as much as rebuilding it. Or the business has changed shape, and the tool encodes an organisation that no longer exists.

You still have to rewrite the right system. Rebuilding screen by screen freezes the workarounds into the new one. The preparation is the same as for new software: roles, decisions, exceptions, which data is the reference. Scoping and architecture before opening a new repository avoids rebuilding the old problem in a newer syntax.

A rewrite also costs attention. While it moves forward, the old system has to keep living. If the team cannot do both, the plan is wrong, however good the target looks.

Option 4: replace it with something that already exists

Sometimes the custom system no longer pays for itself. The process has become standard, the local differences are habits rather than advantages, and a product on the market covers the need at a lower cost — licence, integration and rollout included.

The test is not “does a product exist”. It is “are our differences still worth the cost of carrying them”. If they are not, the project changes shape: configuration, data migration, interfaces to what you keep, and a deliberate drop of a few peculiarities.

If they are, a generic tool often ends up surrounded by informal custom work. Better to know that before signing.

The real subject is the data

Users judge the new system with one question: are my cases in there, and are they right?

Migration is not a script you run at the end. It is a design constraint. Which entities move? Which history must stay readable, and which can sit in an archive? Which keys let you reconcile old and new? What is the quality of the data today — duplicates, inconsistent statuses, fields used for something other than their name?

An honest plan expects a gap. You compare counts of open cases, stock, balances, not only row counts. You decide in advance which gap is acceptable on cutover day, and who is allowed to correct it afterwards.

Without that comparison, the cleanest rewrite fails when it meets the business. New code has no memory. The data does.

Avoid the big bang

Switching everything off on a Friday night assumes the new system is complete, the data is right, partner interfaces have followed, and people know how to work in it on Monday. Those conditions are rarely true together.

Coexistence is slower to explain and safer to live through. The old system stays the reference for paths not yet moved. The new one takes one flow, with a clear way to see where a case sits. You can roll one zone back without rolling the whole project back. You do not ask people to type twice, except for a short, measured window.

A big bang is sometimes unavoidable, for example when a partner interface will only talk to one system. Then it is prepared as an operation: a rehearsal on a copy, stop criteria, a named role for each person on the day. It is no longer a hope.

How do you choose?

The grid below does not produce a score. It forces the criteria that actually change the decision.

Criterion	Useful question
Criticality	Can a few hours of downtime be absorbed, or does the flow stop with the tool?
Debt	Is the cost of the next change still readable, or is every request a discovery?
Knowledge	Does someone still know why the rules are this way, and can they write it down?
Dependencies	Which systems and partners break if the data contract changes?
Value of the custom work	Does what sets you apart live in this tool, or in the way of working around it?
Horizon	In three years, will this process still exist in this shape?

If criticality is high and knowledge is thin, start by making the system deployable and observable before replacing its core. If the custom work has little remaining value, look at a product you can buy before writing code. If the data is dirty, no scenario skips that step.

Building the replacement, or the new zone, comes after that sort. The better decision is not the one that creates the most new code. It is the one that makes the next change ordinary, without losing the history the business relies on.