In many companies with twenty or thirty years behind them there is a computer that nobody dares to switch off. It sits on a desk in the corner, or on a small server in the filing room, runs a version of Windows nobody installs any more, and holds the application where orders are entered, customer prices are calculated or next week's production is planned. It was built in Access, Visual Basic 6, Delphi or FoxPro by someone who knew the business like few others and who has since retired or moved on. It works, and everyone knows it works. Everyone also knows that, on the day it stops working, nobody is quite sure what to do.
In other companies it is an Excel workbook full of VBA macros that has grown for a decade, or an ERP built to measure fifteen years ago by a software house that has since closed, with support reduced to the mobile number of someone who still picks up out of goodwill.
This article is about replacing that system without the operation noticing. Keeping it and adding AI on top is a different conversation, which we covered in the article on adding AI to the software your company already uses.
Short answer
An old system is modernised without stopping operations by replacing it module by module. You build one new area at a time, connected to the same information, run it for two to four weeks in parallel with the old one, and only switch off the old part once the numbers match. Before building, you extract the business rules hidden in the code. A first module typically costs between €7,500 and €15,000 when it is an automated process, or between €15,000 and €25,000 when it is a single-scope portal, and goes into production in 6 to 12 weeks.
Replace it piece by piece, with the old one still on
A critical system is replaced in parts. You pick a well-defined area, build the new version of that area, run it alongside the old one until the results match, and only then switch the old part off. Then you move on to the next. At every moment the company has a system that works, and every step is small enough to be reversed.
The modernisation projects that go badly have usually tried the opposite.
Signs the old system has become a risk
None of these signs, on its own, forces a change. Three or four together do:
- only one or two people know what to do when an error message appears;
- the computer the application runs on cannot be updated, because the last time someone tried, the application stopped opening;
- a new field or a different report takes weeks, or simply cannot be done;
- nobody knows where the source code is, or they do, but nobody left can still change it and compile it again;
- someone has already tried to connect the system to the online shop, the bank or the invoicing software, and the answer was "it can't be done".
The cost of doing nothing
The first cost is dependence on people. A system that only one person understands has a single point of failure that goes on holiday, falls ill and, one day, retires.
The second is the platform. Windows 10 reached end of support on 14 October 2025 and, for businesses, it only keeps receiving security updates through Microsoft's Extended Security Updates programme, paid per device and capped at three years. Office 2016 and Office 2019, including the Access versions that came with them, reached end of support on the same date. The programs still open, but they no longer receive security fixes. And many old applications do not run well on recent versions, which leads companies to keep an out-of-date computer connected to the network on purpose, because it is the only one where the program still opens.
The third is security. It is common to find the database in a shared folder with full access for everyone, passwords stored as plain text in a table, and no record of who changed what.
The fourth, and the one that weighs most day to day, is the inability to integrate. A large customer who wants to send orders electronically, a portal for the sales team, a process that could be automated: every new requirement becomes a patch or a "no". And the worst moment to decide all of this is during a breakdown, with the operation at a standstill.
Three common ways it goes wrong
The big-bang replacement. Months of building in isolation, everything migrated over a weekend and, on Monday, the numbers do not add up and functions nobody had mentioned are missing. It is common for the company to go back to the old system "just for a few days", which then become permanent.
Copying the old system screen by screen. It looks like it removes the risk of forgetting something, but fifteen years of use leave shortcuts and workarounds behind: the "Notes2" field that ended up holding the carrier reference, the button nobody presses, the report that exists because a customer asked for it in 2012. Reproducing the screens means inheriting the bad habits. You replicate the process, not the interface.
Migrating the data and forgetting the rules. All the data comes across, but the rule that gave a 3% discount to a certain group of customers above a given volume, or the one that blocked shipments to customers with invoices more than sixty days overdue, lived in the code. Nobody knew it was there, and it is discovered when the first invoices go out wrong.
How a module-by-module replacement works
The pattern we use has a curious name in engineering, strangler, inspired by strangler figs, which grow around a tree until they replace it entirely. In plain terms, it works like this.
A new layer is built next to the old system, connected to the same information. The first module is usually something on the edges, that hurts and is not too tangled up with everything else: order and stock lookups for the sales team, a portal where customers follow their orders, the pricing calculation, or the production planning that today lives in a separate spreadsheet. That module reads data from the old system, later becomes the one that creates it and, when that happens, the equivalent part of the old system is frozen. You repeat this area by area, and the old system keeps shrinking until it has nothing left to do.
There is one technical detail that decides whether this goes well or badly: every type of information must have, at any given moment, a single owner. If customers start being created in the new system, they can no longer be created in the old one, and synchronisation runs in one direction only. Two systems writing to the same record is the fastest route to data nobody can explain. During the transition, an integration layer keeps the two aligned, for example by copying customers created in the new system back into the old one, because invoicing still lives there.
The order of the modules is not a technical decision, it is a business one. You start with what has the most impact and the fewest dependencies, and leave the core, usually invoicing and stock, until last. Quite often, in fact, the core should not be built to measure at all.
The rules that only exist in the code
The real value of an old system is not in its code, it is in the business rules that settled into it over the years and that nobody documented. They sit in Access queries, VBA modules, Delphi form events and database procedures: rounding rules, cascading discounts, customer-specific exceptions, cut-off dates.
To extract them we use three sources: the code, the people who use the system every day and know what gets done by hand because the system does it badly, and a comparison of results, in which a month of real data is run through the new rules and compared with what the old system produced. Every difference is either a bug in the new system, a forgotten rule or, fairly often, an old error that people have been correcting by hand for years.
Where artificial intelligence helps, and where it falls short
Reading old code is one of the areas where AI has genuinely changed the work. A language model can work through thousands of lines of Visual Basic, VBA, Delphi or SQL, explain in plain language what each routine does, identify which tables each screen reads and writes, point out code that is no longer called from anywhere and produce a first catalogue of business rules. Reading that used to take weeks can come down to days.
It does, however, have clear limits. It does not know whether a rule written in 2011 still applies, or whether that customer with special treatment is still a customer: that is validated with the people who know the operation. It can confidently describe a rule that is not quite what the code does, so every extracted rule is confirmed against the code and the data. And it should not translate the old code line by line, because the result is the same system with new syntax. As for confidentiality, the code and the data are analysed in environments whose contracts exclude model training.
Data: migrate once, rehearse many times
The data in a fifteen-year-old system is never clean: duplicate customers, missing tax numbers, item codes reused for different products, dates stored as text. Some of it gets fixed during the migration, some of it needs a decision from the business, and it pays to know early which is which.
The migration runs as an automated, repeatable process, rehearsed several times with real copies of the data. On the day of the final cut-over, you are repeating something that has already gone well four or five times.
Then comes the parallel run. For two to four weeks, or a full month-end close when the module handles money, both systems work at the same time and the numbers that matter are compared: the day's invoiced total, end-of-day stock, customer account balances. The old system is only switched off when the numbers match, and the rollback plan is defined before starting, not in the middle of a problem.
How we approach it
1. Diagnosis
A 30-minute conversation, free of charge and with no commitment to proceed, ideally with the system open on screen. We look at the technology, the data, who uses it and what hurts most, and the company is left with a first read of the risks and of the order in which it would make sense to replace things.
2. Mapping the rules and the data
AI-assisted code reading, interviews and data analysis. The outcome is a catalogue of rules validated by the company, which remains its own documentation whatever happens next.
More and more companies reach this stage with a prototype of the new module built in ChatGPT, Claude, Gemini or tools such as Lovable or Cursor. That shortens the discovery work and lowers the price, because the main screens and rules are already visible. The prototype does not bring user accounts, migrated real data, a connection to the ERP and the old system, backups or testing, which is precisely what this article describes. We explain the difference in the article on taking an AI-built prototype to production and on the page about AI-built apps in production.
3. First module in production
Build, integration with the old system, rehearsed migration and parallel run, with real use.
4. The following modules
One at a time, with the order reviewed after each delivery, because the first module always reveals things the diagnosis could not see.
5. Switching off the old system
The history is archived in a format you can consult without the old application, and the computer nobody dared to switch off is finally switched off. The code, the documentation and the system belong to the company.
Investment and timeline, module by module
It depends on the module, and the ranges published on our solution pages apply directly.
| Type of module | Typical example | Investment |
|---|---|---|
| One automated process | Replacing the macros that generate purchase orders to suppliers | €7,500 to €15,000 |
| Several connected processes | Orders, approvals and invoice matching | €15,000 to €35,000 |
| Single-scope portal | Order and stock lookups for the sales team | €15,000 to €25,000 |
| Multi-role platform | Customers, sales team and warehouse, each with their own permissions | €25,000 to €45,000 |
| Core operations platform | The new system becomes where the operation lives, with full migration | from €45,000 |
A first module typically goes into production in 6 to 12 weeks: closer to six when it is an automated process, closer to twelve when it is a portal. The two to four weeks of parallel running follow before the old part is switched off. The full replacement is spread over several months, and that is an advantage: the investment follows the results, and each phase is assessed before the next one is decided. What makes these timelines vary is covered in the article on how long a custom software project takes, and what each proposal should itemise in the article on what a custom software quote should include.
What moves the figure most is the number of hidden rules, the quality of the data and how you get to it. An Access or SQL Server database can be read without much difficulty. Old, poorly documented file formats, common in Delphi or FoxPro applications, take more work before a single line of the new system is written.
When the question is replacing an entire ERP, accounting and invoicing included, the conversation starts at the diagnosis, and the most frequent answer is that this part should not be built to measure. We explain why in the article on a custom ERP versus Primavera, PHC, ARTSOFT and SAP.
When it is not worth it
If the system is stable, has few users, does not need to talk to anything else, and the person who maintains it is still with the company and available to document what they know, the sensible move is a small investment: isolate the machine it runs on, make sure backups exist and have actually been tested, and write down the main rules. That buys time to decide calmly.
If what the old application does is generic, such as invoicing, accounting or payroll, the right replacement is an off-the-shelf product. Invoicing software in Portugal has to be certified by the Tax Authority (AT) and meet its own technical requirements, and certified products already keep up with them.
And if the company is heading into a merger, a sale or a reorganisation in the coming months, it is worth waiting.
Questions to answer before moving forward
- If the system does not open tomorrow morning, how long can the operation manage without it?
- Who are the people who know how it works, and how much of their time can they give to explaining it?
- Can anyone open the database outside the application, or is the data only reachable through it?
- Which parts of the system hurt most today, and which work well and can wait?
- Are there external deadlines adding pressure, such as a server move, a customer requirement, or the end of support for part of the platform?
We build internal portals and platforms that take over from the old system module by module, and process automation for the macros and spreadsheets that hold parts of the operation together today. If you have a system like this supporting your business, you can request a free diagnosis. We look at what exists, without commitment, and return a proposal with scope, timeline and investment defined, including the order in which to replace each part. We reply to contact requests within 24 business hours.
