Replacing legacy systems with AI: how SMEs modernise software and old data

In many small and mid-sized companies, a legacy system carries day-to-day business: an Access database from 2008, a home-grown PHP application or a web of Excel sheets. It works, somehow. But the person who built it has retired, and every change feels like open-heart surgery.

The question we now hear regularly: «Can AI help us with this?» My answer: yes, considerably. But not the way many people imagine. AI does not translate your old system into a new one at the push of a button. It takes over the most tedious steps and thereby makes projects affordable that did not add up before.

In this article I show you where AI helps and where it does not. After that, we look at moving old data in five steps and at the costs. Finally, I tell you what we recommend depending on your starting point.

Two developments are coinciding. First, legacy systems are falling out of support: Microsoft ended support for Access 2016 and Access 2019 on 14 October 2025. The programs keep running, but receive no more security updates. Anyone managing company data in them has been working with software whose security holes nobody closes any more.

Second, AI has matured at exactly this kind of work. The best-known example comes from Amazon: by its own account, the company used its AI assistant to move more than half of its production Java systems to a newer version. An upgrade took a few hours instead of around 50 developer days. Amazon puts the savings at 4,500 developer years.

These figures are a corporation's own claims and cannot be transferred one to one to an SME. But the direction is right: what used to fail on cost becomes feasible for smaller companies with AI.

A migration consists of many small, tedious tasks. That is exactly where AI plays to its strengths. Four areas bring the biggest gains in our projects:

Legacy systems contain knowledge that is written down nowhere: discount rules in a VBA macro, special handling for key accounts in line 2,400 of a PHP file. A language model reads this code and describes in plain language what it does. Weeks of code study become a list of business rules the business can review.

The old system calls a field «KdNr_alt», the new one «customer_id». With 300 fields, this mapping is days of tedious work. AI proposes it based on field names, sample values and data types. A person confirms or corrects. That saves a large share of the time without giving up control.

Old data is rarely clean: duplicates, «Müller GmbH» next to «Mueller GmbH», addresses in a single free-text field. AI recognises such patterns and splits, for example, «Hauptstr. 5, 10115 Berlin» into street, house number, postcode and city. Every proposal lands as a change list with the business, not directly in the database.

Before you replace a system, you have to record how it behaves. These are called characterisation tests: for a set of real inputs, the legacy system's output is recorded. The new system must deliver the same results. AI writes such tests in large numbers, and this is exactly where many migrations otherwise fail for lack of time.

To be completely honest: AI does not replace decisions. It finds the discount rule in the macro, but it does not know whether that rule still applies or is a leftover from 2012. Only someone who knows the business can judge that.

The same goes for acceptance. Whether the new system calculates correctly is confirmed by accounting, not by a model. And AI only reads what it can see. If business rules exist only in one employee's head, the only thing that helps is talking to her.

A third point concerns data protection. Customer data, personnel files and supplier terms do not belong unchecked in just any AI model. We therefore work with pseudonymised samples or with models that run in the EU. How that works is described in our article on LLM self-hosting costs.

Bottom line: AI speeds up the legwork, the responsibility stays with you.

The software is often the smaller problem. The real question is: how do you get twenty years of data cleanly into the new system? We always work in five steps:

We almost always plan the trial run twice. The first one reveals the surprises, the second proves they are fixed. A cutover without a trial run is a gamble with your customer data.

A trial run is only as good as its reconciliation. At the end of every run, there should be a report that answers three questions:

Only when this report has no open points do we set the cutover date.

With larger systems, not all parts move on the same day. An intermediate layer then routes requests to the old or new system depending on the function, module by module. This is known as the strangler fig pattern. How we implement it technically is shown in our article on Next.js as an integration layer for legacy systems.

A common misconception: all data has to go into the new system. That is rarely true. Many old records only exist because retention periods are running. In Germany, for example, accounting vouchers must now be kept for eight instead of ten years, while annual financial statements remain at ten years.

Such data often belongs in a readable archive, not in the new operational system. That makes the migration smaller, faster and cheaper. Such an archive can be a simple database with a search form. If your tax adviser requires more, you use an audit-proof archiving system. Which retention periods apply to you is best clarified with your tax adviser.

How it all fits together is shown by a scenario we encounter in this or similar form quite often: a wholesaler with 25 employees. Since 2009, it has managed orders, customers and suppliers in an Access database with 30 tables, 15 forms and a few thousand lines of VBA code. A former employee built it.

The result is a web application with login and roles that runs in the browser and receives security updates. The knowledge about the business rules now lives in documentation instead of one person's head. That removes the biggest risk of the legacy system.

The honest answer: it depends on three factors. How many tables and sources are there? How clean is the data? And how many business rules are hidden in the code that nobody has documented?

For orientation, we publish our price ranges from real projects, as on our page on software modernisation. A first replaceable module of manageable size costs €8,000 to €20,000. Fully replacing a module with login and roles costs €20,000 to €60,000. All prices are net.

What AI changes: it shifts the costs. Code analysis, field mapping and tests become considerably cheaper. Conversations with the business, decisions and acceptance stay just as demanding. Especially with smaller systems such as an Access database, this tips the calculation: replacing it can become cheaper than two or three more years of patching the legacy system.

One more word on duration: don't plan the data migration as the last step. If you only think about the data at the end, the launch of the new system almost always slips. We start the inventory in the first week of the project.

Not every legacy system needs the same path. Here is our position, as we present it in initial calls:

Our position in one sentence: AI makes replacing your legacy system affordable, but only a solid plan makes it safe.

If your legacy system is holding you back, we clarify three questions together: does replacing it pay off compared to keeping it running? Which data has to move, and which goes to the archive? And where does AI save the most in your case?

In 30 minutes you will know whether and how replacement pays off for you. Book a no-obligation video call here. You will also find our approach and price ranges on the page software modernisation.