Modernization without losing the business logic

When a system becomes hard to change, the usual proposal is to replace it. The language is familiar: rewrite, rebuild, move to a modern stack, break it into services. The assumption underneath is that the old system is mostly a technical problem.

It usually is not.

A system that has been in production for ten or fifteen years contains decisions the organization no longer remembers making. Pricing exceptions. Approval paths. The way an order is allowed to proceed when inventory is incomplete. Those rules are not sitting in a requirements document. They are sitting in the code, in stored procedures, and in the habits of the people who still know which screen to avoid.

The business logic is the asset

People call this "legacy" as if age were the defect. Age is often the evidence that the system survived contact with the business. The defect is that the knowledge is trapped in a form that is expensive to change.

If you throw the system away, you do not start from a clean model of the business. You start from a partial memory of it. The first year of the new system is then spent rediscovering rules that the old one already enforced, usually after a customer or an auditor finds the gap.

Modernization should treat the existing behaviour as a source, not as an embarrassment. Some of it should be kept. Some of it should be changed on purpose. Almost none of it should disappear by accident.

Understand before you split

Distributed architecture is often sold as the modernization. It can be useful. It can also freeze a misunderstanding in more places.

If the team cannot draw the current system's responsibilities on one page, they are not ready to cut it into services. A poorly understood monolith, split into eight services, is still poorly understood. It is only harder to run.

I look for seams that already exist: a module that already has a different lifecycle, a data set that already has a different owner, an integration that already fails independently. Those are candidates. Invented boundaries, drawn because a slide asked for microservices, are not.

Migration is part of the architecture

The new system is not the only design problem. Getting there is a design problem of its own.

Data has to move while the business keeps operating. Identities have to remain valid. Two systems may have to share a process for longer than anyone wants to admit. I learned this the slow way, working on products that could not be taken down for a clean cutover. The migration path is part of the architecture. If it is left as a later operations task, it will dictate the architecture anyway, under worse conditions.

A strangler approach — replacing one capability at a time while the old system continues to run — is less dramatic than a rewrite. It is also how most organizations actually survive the change.

New technology does not remove old constraints

A new language, a new database or a new cloud vendor can make some work easier. It does not remove the constraints that made the old system complicated. Those constraints were usually business constraints: audit, latency, multi-tenant isolation, the need to keep last year's documents readable.

If those constraints are still true, they will reappear. The honest modernization plan names them early and decides which ones are still worth paying for.

I am not against replacing technology. I am against replacing it before the team can say what must remain true after the replacement.

Architecture that can still change

The goal is not a modern system. The goal is a system the business can keep changing.

That requires clearer boundaries, better tests around the rules that matter, and an architecture that does not punish a small product change with a large technical one. It also requires enough humility to keep the parts of the old system that already work.

Good software architecture is not about choosing the newest technology. It is about building systems that can evolve with the business. Modernization is the same idea, applied to a system that has already evolved once and now needs help doing it again.