Legacy application modernisation

What is legacy application modernisation?

Modernisation means moving a system that runs on outdated technology onto a current one, together with its data and business logic. In practice it takes one of three routes: a rewrite, a gradual replacement of modules while the old system keeps running, or wrapping the old core in a modern interface and API. The choice depends on how much company knowledge sits in the old code and how costly an interruption would be.

What we meet most often are applications on .NET Framework, Delphi, Visual Basic and Access, databases in DOS era formats (dBase, Clipper, FoxPro) and terminal systems running on old Windows versions. They share one trait: the company depends on them and fewer and fewer people can change them safely.

When to rewrite and when only to cut the risk

A rewrite from scratch sounds attractive and is usually the most expensive and riskiest option. A legacy application holds dozens of decisions made over the years that nobody remembers but that are still needed. Rewriting blind means discovering them one by one, normally after go live and normally under pressure.

So we often start with gradual replacement: the new system takes over function after function while the old one keeps running until it is empty. The company works throughout and the risk spreads across stages instead of piling into a single switchover day. Sometimes less is enough: isolate the old system from the network, add backups and modern access, and postpone the rewrite until there is a business reason for it.

We will say plainly when modernisation makes no sense. If an off the shelf system covers ninety percent of your process, it is more honest to point at deployment and data migration than to rebuild the same thing.

What happens to the data in old databases

Data is usually the most valuable part of a legacy system and the most common source of trouble during migration. We start with an inventory: what sits where, which fields are actually used, where the duplicates and historical debris are, and which relationships exist between tables without any documentation to describe them.

Then we build a migration that can be run repeatedly and verified with numbers: how many records went through, how many were rejected and why. We rehearse it as many times as needed before touching production. The old data stays in a read only archive so nobody has to fear something disappeared.

Where AI fits into this

Modernisation is the best moment to add what did not exist when the system was written. What usually earns its place is natural language search across company documents and order history, hints while entering data, automatic description and categorisation of tickets, and pulling data out of incoming invoices and documents.

We approach it without excitement. AI goes where it shortens a specific task and the effect can be measured, and it goes in line with GDPR and the AI Act: it is clear what data reaches the model, where it is processed and who has access. When data cannot leave the company, we build something that runs locally or in our own infrastructure inside the European Union.

The rule is simple: first the system has to work and be secure, only then clever. Bolting AI onto an unstable application is the fastest way to put the team off it.

How we keep migration risk down

The biggest risk is not technology but an interruption to the business and data loss. So the old system stays alive until the new one proves it does the same job. For a period both run in parallel and we compare results on the same data.

Then come the boring things that actually decide the outcome: a full backup before every stage, a rollback plan, testing on a copy of the environment, and acceptance by the people who use the system daily rather than only by IT. Users learn the new tool before the old one is switched off, not on the day of the switchover.

Why we are the ones to do this

We do two things at once and that is the advantage here. We run company IT, so we understand the environment these applications live in: servers, network, permissions, backups and what happens when something stops working on a Wednesday afternoon. At the same time we build our own SaaS products that we maintain for years.

Because of that, modernisation with us does not end where a typical software house stops: code delivered, good luck. The new system stays under our care alongside the rest of your infrastructure, or we hand it to your team with documentation if you prefer.