I know this sounds odd coming from a company that makes its living from legacy modernisation.
But that is exactly why I can say it credibly: legacy modernisation is not always the right decision. In fact, in my experience at least a third of all "let's modernise everything" projects involve systems that really shouldn't have been touched. At least not then, not that way, and not for that reason.
55% of European companies still run critical systems that are at least ten years old. That is not necessarily a problem. Sometimes it is wisdom.
What is a legacy system - and why isn't it necessarily a problem?
Before we start, let's clarify the term. In IT, "legacy" has become pejorative over time - as if it meant outdated, bad, something to be ashamed of.
In reality, a legacy system is simply a system that has been running for a long time, carries business logic, and has had business processes built around it. That is not a problem. It is value.
Most legacy systems in financial services are still running after 15-20 years because they do what they do reliably. An insurance core system isn't "legacy" because it is bad - it is legacy because it was written in 1998 and has since been filled with ten thousand business rules, each reflecting a real business need.
That business logic is the real value. Not the technology - that genuinely is outdated. But the knowledge encoded in it is not.
When not to modernise your legacy system - 4 situations
1. When you don't know exactly what it does
This is the most common and most dangerous situation.
The system runs. Everyone uses it. But nobody knows exactly how it calculates value X, why contract type Z gets special handling, or what the strange logic in module Q is that means "don't touch it or it falls apart".
If there is no documentation and the original developers have long since moved on, the first step before modernisation is not refactoring but understanding. A discovery phase that maps and documents the existing business logic is more important and more valuable than the modernisation itself. Companies selling modernisation rarely say so.
We always do. Because we know from experience: whatever moves into the new system undocumented will fail undocumented - just on more expensive technology.
2. When modernisation is really IT fashion - not a business need
It happens - and it is hard to put more politely - that a modernisation project is driven not by a business need but by technological curiosity or outside pressure.
"We should move to microservices." "Everyone is in the cloud already." "The developers are bored with Java 8."
These can be valid considerations - but they are not sufficient reasons to touch a working, critical system. If the primary driver of modernisation is not a concrete, measurable business problem but simply "being modern", proceed with great caution.
You don't modernise an insurance core system because Spring Boot 3 is out. You modernise it because the current system can't support the speed at which new products need to be launched, or because compliance requirements can no longer be met with the current architecture.
If there is no such concrete business reason - wait.
3. When the in-house skills for the transition are missing
Legacy modernisation doesn't end at delivery. Someone has to operate, develop and maintain the new system. If the organisation lacks the competence to handle the new technology, modernisation creates a new dependency rather than removing one.
I have seen this up close. A financial services organisation modernised a 15-year-old Java system - onto a microservice architecture, Kubernetes and a cloud-native approach. The project was a technical success. Afterwards, the operations team that had previously run a monolith suddenly had a distributed system it didn't understand.
The result: operating costs doubled, troubleshooting time tripled, and six months after go-live external help had to be brought in. That wasn't the fault of the modernisation - it was the fault of a lack of preparation.
4. When a deadline is forcing the decision
"We have to do it because support is ending." "There's a compliance audit next year." "The CEO said it must be done by Q3."
Urgency is a poor adviser in legacy modernisation. Experience is clear: deadline-driven modernisation projects tend to skip the preparatory work - documentation, uncovering business logic, planning an incremental approach - that ensures success.
The end result: a rushed modernisation that is unstable for months after go-live and costs more to operate than the old system.
If support really is ending, that doesn't necessarily mean the system stops working. It means the vendor no longer issues security patches. That is a risk that must be managed - but not necessarily with a complete rewrite.
When you must modernise after all - 4 clear signs
To be fair: there are four situations where legacy modernisation is not optional but a strategic necessity.
Integration is no longer possible. If new business needs - mobile apps, API-based partner connections, real-time data services - can't be met because of the existing system's technical limits, and an API layer is no longer a sufficient solution, modernisation is necessary.
Maintenance costs exceed the value. If changing the system is disproportionately expensive, if every change triggers an avalanche of regression defects, and if developers who understand the technology can no longer be found, the cost of maintenance grows exponentially. In that case modernisation is cheaper in the long run.
Compliance requirements can no longer be met. Financial services regulatory requirements - DORA, central bank rules, GDPR - sometimes impose system requirements that simply cannot be implemented in the existing architecture. That is a clear signal.
Business growth is blocked. If IT can't keep up with business change - new products, new channels, new partners - and this causes real lost revenue or competitive disadvantage, modernisation pays off.
Legacy modernisation: incremental change or a complete rewrite?
If one of the four signs applies, the question is no longer whether to modernise. The question is what to modernise and how.
There are two basic approaches:
Incremental modernisation (the strangler fig pattern) - new components are gradually built around the legacy system and take over its functions module by module. The legacy system keeps running until the last module has moved over. It is slower but safer - and for critical systems in financial services it is almost always the right path.
A complete rewrite - a new system is built from scratch to replace the legacy one. It looks faster, but is usually slower and riskier. In our experience, nine out of ten successful legacy modernisations are incremental refactoring, not rewrites. The main problem with a complete rewrite is the invisible business logic - the ten thousand small rules baked into the legacy system over the years that nobody has fully documented.
How we approach legacy modernisation at FrontX
Before making any legacy modernisation recommendation, we carry out a discovery phase. We map the existing system's business logic, identify the real pain points and examine the alternatives.
Sometimes the outcome is that we don't recommend modernisation - at least not now, not that way. That may seem odd coming from an IT consultancy. In fact it is the most valuable service we can provide.
Because a badly timed or badly planned legacy modernisation project costs more than maintaining the existing system. And the client needs to be told that.
If you are facing a decision about a legacy system and would like someone to look at it from the outside, we are happy to talk: frontx.hu/en/company/contact
A question for you
Have you come across a legacy modernisation project that, in hindsight, should never have been started? What was the sign that could have been seen in advance?
Frequently asked questions
When is it not worth modernising a legacy system?
It is worth postponing in four situations: when the system's business logic isn't documented, when modernisation is driven by technology fashion rather than a concrete business problem, when the organisation lacks the competence to operate the new system, and when the project is deadline-driven and skips the preparatory phase.
What is the difference between incremental legacy modernisation and a complete rewrite?
Incremental modernisation (the strangler fig pattern) builds new components around the legacy system module by module - the legacy system runs until the last module has moved over. A complete rewrite builds a new system from scratch. The incremental approach is slower but safer - in our experience, nine out of ten successful legacy modernisations are incremental, not rewrites.
What are the clear signs that legacy modernisation is needed?
Four clear signals: integration with new business needs is no longer possible, maintenance costs exceed the value, compliance requirements can't be met in the current architecture, or business growth is blocked.
What is a legacy system discovery phase?
A discovery phase is a short preparatory stage - usually two to four weeks - in which we map the existing system's business logic, identify the real pain points and examine the alternatives. It determines whether modernisation is needed at all and, if so, with which approach. Without it, legacy modernisation is flying blind.
How long can a legacy system be maintained?
The question is not how old the system is, but what business value it carries and what problems it causes. Many legacy systems in financial services run stably after 15-20 years because the business logic encoded in them represents real value. The decision should be driven by business need and maintainability, not age.
László Behán is Managing Director and Co-Founder of FrontX Kft. He was previously CIO of Signal Biztosító, Head of Development and Data Warehousing at Groupama Biztosító, and Operations Director and a member of the Board at LeasePlan Hungaria. He has 25 years of IT and business leadership experience in financial services.
LinkedIn: linkedin.com/in/laszlobehan | FrontX insights: frontx.hu/en/insights
