Modernising an old application: how to do it safely
How I work out an application nobody understands any more, how the migration proceeds, and how we make sure the new one does the same things as the old one.
One important application, one old machine
The application has done its job for 15–25 years. Everyone knows that one day it will not start. You do not have to specify anything again, the first step is fixed-price, and not everything always needs rebuilding.
A dozen applications, no overall picture
Custom tools from the early 2000s are blocking a server upgrade or an ERP change. We start with a survey that ranks them by risk and cost.
Why keeping an old application on life support is not enough
"It still works" is true right up to the day it does not. Typical situations after which there is little time left:
- The machine dies, or the Windows version it runs on stops receiving security updates. Windows 10 support ended in October 2025 and Windows Server 2016 support ends in January 2027.
- The database server, a printer or the other end of an integration changes, and the old application can no longer talk to it.
- The only person who knew the application's workarounds leaves the company.
- An auditor, a customer or an insurer asks how the calculations have been verified.
- An ERP change or server upgrade stalls because one application will not come along.
A rebuild done in a hurry is the most expensive kind. One started in time is the cheapest.
Four possible outcomes. A new application is only one of them.
The work, stage by stage
1–2 h
a few weeks · credited against follow-on work
based on the assessment
you can stop at any time
after acceptance
How an application is analysed when there is no documentation
The specification of an old application is the application itself. I do not ask you to write it again. I combine four sources:
The user shows the work
A user enters an order, calculates a quote or runs a report the way they always do. I record it.
Source code, if there is any
I go through what the code does, including the branches not seen in the demonstration. AI speeds this up a lot, but every finding is checked.
Database and files
Structure, triggers, procedures and historical data reveal what the application has actually done over the years, exceptions included.
The running application
Once the application runs, it can be probed: what happens with this kind of input.
The result is a set of concrete statements for you to confirm:
It is easier for you to say "yes, that is right" or "no, that changed in 2015" than to write a requirements specification from scratch. Rare situations, such as year-end runs, error cases and special customers, are hunted down separately because they do not show up in a single demonstration.
How we make sure the new system calculates the same results as the old one
I run the same data through both applications in isolated environments and compare the results: calculated values, rounding, reports and the changes written to the database. You get a list: these match, these differ, for this reason.
Three things I say plainly:
- Comparison proves equivalence only for the cases examined. That is why the data should span several years and include the known special cases.
- Bugs in the old application are not copied automatically. When a difference is caused by a bug in the old system, you decide which one is right.
- The new application also needs its own security, performance and environment checks. These are not part of the comparison and are done separately.
The data used for comparison stays with you. It can be used to verify the next version, another supplier or another AI-built implementation.
What kind of applications I take on
The technology is chosen to fit the situation, for example .NET and React with SQL Server or PostgreSQL. The criterion is always the same: widely known and supported for the long term, so that almost any software company can continue the work. If you have a preference or your organisation already uses something, we go with that. If needed, I suggest a suitable option. A desktop application can stay a desktop application if a browser does not suit the way it is used.
If the application can be replaced more cheaply with an off-the-shelf product, if its use will end within a few years, or if there is no source code and the application cannot be made to run. In the last case we are talking about building a new application, and I say so plainly.
The role of AI and how your data is handled
What AI does
Reads and explains old code, proposes rules, writes new implementation. It makes the work a fraction of what it would take by hand. That is why I can offer fixed prices even for small applications.
What AI does not do
It does not decide what is correct. The most dangerous mistake in this work is AI misreading an old rule and then writing both the new implementation and its tests from the same misreading. The tests pass and the result is still wrong. That is why the benchmark is always the old application's actual output and your confirmation, not the AI's interpretation.
Where your code and data are processed
- We agree in writing before starting which material may be processed in AI services.
- I do not send production data, personal data or pricing data to AI models. Testing uses anonymised or synthetic data unless otherwise agreed.
- I use Anthropic's Claude (Claude Code) and OpenAI's ChatGPT with settings under which the data is not used for model training. These services process data on their own servers, which may be located outside the EU. If that is not acceptable, no data goes to external services at all.
- During the work, source code and databases are kept in my own encrypted environment, separated from other clients. They are deleted after handover unless maintenance is agreed separately.
- If source code may not be processed in external services at all, that works too. Slower and more expensive, but it works.
A one-person supplier. What if I am not available?
A fair question, and one you should demand an answer to from every small supplier. My answer:
Handover at every stage
The source code is in your hands at the end of every stage, not only at the end. Even unfinished work can be continued.
Mainstream technology
The technologies are kept as mainstream as possible, for example .NET and React, so anyone who knows them can develop the application further. You are not dependent on me.
No platform of my own, no product of my own
Nothing is locked into my systems.
If you already have an IT partner who runs your infrastructure, I am happy to work with them: they handle the environment and ongoing support, I handle the application analysis and migration.
Frequently asked questions
I do not know what language the application was written in. Does that matter?
Does everything have to be rebuilt?
Will old data be lost?
What does this cost?
How much of my or my staff's time will this take?
The application has functions nobody uses any more. Do they have to be migrated too?
We have several applications. How do you prioritise them?
How are results verified measurably?
Can we continue with another supplier midway?
How do you work with our existing IT partner?
Is our source code processed in AI services?
Can the new application be developed further?
Do you offer ongoing maintenance?
Next step
In the first conversation I can usually say whether it is worth proceeding and what the assessment costs. No source code needed yet.