Modernizing a legacy system without stopping the operation

Almost every conversation about modernization starts wrong, because it starts with the technology: "it's on PHP 5," "it uses jQuery," "it runs on its own server." None of that is, by itself, a problem.

A system is legacy when changing it costs more than it should, and nobody can predict the cost. That's the useful definition, because it connects to money.

The signs that actually matter

Not the age of the code, but these:

Nobody can estimate a change

If the answer to "how long does it take to add this field" is "depends, we'd have to see what else it touches," the system has lost its modularity. Changes propagate through paths nobody has mapped.

There's no safety net

Without tests, every deployment is a bet, and because every deployment is a bet, deployments happen rarely. Because they happen rarely, each release piles up a lot of changes, which makes something breaking more likely and figuring out what broke it harder. It's a loop that closes on itself.

The knowledge lives in one person's head

When there's exactly one person who understands how the billing module works, the risk has stopped being technical and become organizational.

The operation depends on manual steps

Someone runs a script at month's end. Someone adjusts a record by hand when the process fails. Those patches are signs the system no longer models the current business well.

The stack blocks decisions

This is where technology does enter, but as a consequence: a language version with no security support, an abandoned dependency, a database that no longer gets patched. The problem isn't that it's old — it's that it can no longer be updated without touching everything else.

The four strategies, with their real costs

These aren't ideological alternatives — they're different answers to different situations, and they combine.

Strategy	What it involves	When it fits	Its cost
Rehosting / replatforming	Move the system to modern infrastructure without touching the logic	The problem is operational: outages, backups, scaling, server costs	It doesn't improve the code at all; the maintainability ceiling stays the same
Refactoring	Restructure the code internally, without changing behavior	The system does the right thing, but it's expensive to change	It produces no visible functionality, so it needs explicit backing from the business
Gradual replacement	Take the system out piece by piece, module by module, with old and new coexisting	The system is large and the operation can't stop	Two systems have to be kept running in parallel for a good while
Full rewrite	Build the replacement and switch from one to the other	The system is small, or its domain changed so much the current logic no longer fits	The highest risk of all, and it grows with size

Why a full rewrite fails so often

Not because of technical incompetence. For two structural reasons:

The business can't be frozen. While the replacement gets built, the old system keeps receiving changes: a new law, a big client asking for something, a bug that needs fixing. The rewrite project is chasing a moving target, and every change to the old one has to be implemented twice.

The old system contains rules nobody documented. Years of special cases — the client that gets billed differently, the discount that only applies at one branch, the rounding accounting insists on — live in the code and nowhere else. They show up once the new system is already in production and someone notices the numbers don't add up.

That's why gradual replacement is, in most cases, the more reasonable bet: each module that gets migrated delivers value right away, and if something goes wrong, what fails is one part, not everything.

What a gradual replacement looks like in practice

The pattern is known as the strangler fig — the fig tree that grows around the host tree and gradually replaces it until it can stand on its own. Applied to software:

1. Put a layer in front. Routing at the entry point (a reverse proxy, or application-level routes) that decides which requests the old system handles and which go to the new one. At the start, everything goes to the old one.
2. Choose the first module by risk and value, not by ease. The best candidate is usually something with clear boundaries, frequent changes and low coupling — reporting, say, or an integration with a third party. The last thing worth touching first is the transactional core.
3. Define where the truth comes from. This is the point that decides whether the project works. For each piece of data, one system owns it and the other reads from it. Two systems writing to the same table without a clear rule is the number one source of inconsistencies.
4. Migrate, redirect traffic, and only then delete. The old code gets removed once the new one has been in production for a while, not on the day of the switch.
5. Repeat, measuring. Each migrated module should reduce the time the next changes take. If it doesn't, the order chosen was wrong.

Before writing a single line

Three things worth more than any architecture decision:

• Tests over current behavior. Even if there are few and they're high-level. Without them there's no way to know if the replacement does the same thing, and "does the same thing" is the requirement nobody writes down but everyone assumes.
• An inventory of integrations. Everything that consumes the system: reports, other software, a file someone downloads, a direct database query the accountant runs. Whatever isn't in the inventory is what breaks.
• A measurable success criterion. Time to ship a change to production, incidents per month, hours of manual work. Without a baseline, modernization gets judged by feel — and the project always "feels" like it's taking long.

Our approach

At id3a we don't start from "it needs a rewrite." We start by understanding what hurts and how much it costs:

• Review of the current architecture and dependencies, including what no longer has security support.
• Identifying the points that concentrate risk and the ones that concentrate change requests — they're not always the same ones.
• A staged plan where each stage delivers something usable on its own.
• Migration with both systems coexisting, so the operation doesn't stop.
• Tests and documentation as part of the work, not as a later phase that never arrives.

Sometimes the conclusion is that it doesn't need modernizing yet, and that it's worth investing in tests and updating dependencies instead. That's an answer too.

Let's talk about your system