Should you modernize or replace your legacy systems?

Modernize incrementally unless the foundation is genuinely unsalvageable. Full rewrites routinely take twice as long as planned, and the business stands still while they run. Uliasti, a Zürich engineering firm that modernizes systems for banks and SMEs, uses the framework below to make this call. It usually takes two weeks, not two quarters.

Age is not the problem. Risk is.

A fifteen-year-old system that runs reliably, costs little and changes rarely is not a problem, whatever it looks like. The questions that matter are different ones. Can you change it safely, or does every release break something? Can you still hire or contract people who know it? Does it block something the business needs in the next two years, like a new channel, a regulatory requirement or an integration?

If the answer to all three is comfortable, spend your money elsewhere. Legacy is not a technology category, it is a risk category.

The signals that favor modernization

Modernizing means keeping the core and fixing it from the outside in. It wins when:

• The system does its core job correctly, and the pain sits at the edges: integrations, reporting, the user interface.
• The domain logic inside it is valuable and nowhere documented. A rewrite would have to rediscover years of encoded business rules, and it would rediscover them in production.
• The business cannot tolerate a feature freeze. Rewrites consume the team that would otherwise ship improvements.
• Your own people know the system. Their knowledge transfers directly into modernization work and is mostly wasted in a rewrite.

When replacement is the honest answer

Sometimes patching is the expensive option. Replacement deserves a serious look when:

• The platform or runtime is end-of-life and no longer receives security patches.
• Nobody you can realistically hire knows the stack, and the last people who do are leaving.
• The core data model no longer matches the business. If every new feature fights the schema, the schema has already lost.
• A vendor lock makes each year more expensive than the last, with no exit path inside the product.
• You are honest about the numbers and one more year of workarounds costs more than a rebuild of that component.

Note that most of these argue for replacing a component, not the whole landscape at once.

The strangler pattern, in practice

The method we use for almost every modernization is incremental replacement behind a stable interface. Build the new capability alongside the old system, route a slice of real traffic to it, verify, move the next slice, and retire the old part when nothing calls it anymore. Every step ships value and every step is reversible. There is no big-bang cutover weekend, which is where rewrite projects traditionally go to die.

This approach has a useful side effect: the integration layer you build to strangle the old system is the same layer you need to add AI to existing workflows. Many of our clients do both in one movement.

How to decide in two weeks

You do not need a six-month study. A focused assessment produces a defensible decision:

1. Inventory the system and map what actually depends on it, including the undocumented spreadsheet-and-export dependencies.
2. Score the risk: change failure rate, staffing exposure, security posture, vendor situation.
3. Put numbers on both paths: cost of operating and patching for three more years versus cost of incremental replacement.
4. Write the decision on one page, with the trigger conditions that would change it.

We run this as a fixed-scope engagement through our strategy and advisory practice, and the build work, when there is build work, is done by our engineering team. For the data layer specifically, see how we approach enterprise data architecture.

Frequently asked questions

Is modernizing cheaper than replacing?

Usually, but not always. Modernization spreads cost over time and keeps the business moving, which is why it wins by default. Replacement is cheaper only when the platform is end-of-life, unstaffable or fighting the business at the data-model level. The honest comparison is three years of total cost on each path, not the first invoice.

How long does incremental modernization take?

First production improvements in one to three months, because you ship slice by slice. A full replacement of a core component typically runs six to eighteen months, but the system keeps working and improving the whole way through, which is the point.

Our vendor ended support. Do we have to replace now?

You have to act, not necessarily replace. Options include isolating the system behind a controlled interface, contracting security review for the frozen version, and strangling the highest-risk functions first. End-of-life raises urgency; it does not by itself choose the strategy.

Can we modernize and introduce AI at the same time?

Yes, and it is often the most efficient sequence. The stable interfaces, event streams and data access you build for modernization are exactly what an AI integration needs. Doing both in one program avoids paying for that plumbing twice.