Why legacy software stays in service
An application can be fifteen years old and still be essential to the business. It processes orders, supports customer accounts or connects systems that have grown around it. Everyone would like it to be easier to maintain. Nobody is keen to discover what breaks when it is replaced.
That is why older software can remain in service long after a company would prefer to modernise it. The replacement has to earn its budget, and the business needs to keep running while the work is done.
AI gives companies a reason to revisit those decisions. It can help engineers understand unfamiliar code, update components and prepare tests. Some projects that previously looked too expensive may now be worth pursuing. To judge that properly, we need to consider the whole journey from the existing application to a dependable replacement.
What the evidence does—and does not—show
There is evidence behind the enthusiasm. Three randomised field experiments involving 4,867 developers found that access to an AI coding assistant increased completed tasks by around 26%. That is a meaningful improvement, although it does not tell us that a complete modernisation project will cost 26% less.
There are also examples closer to the work itself. An Anthropic case study reports that LG CNS completed an enterprise migration in seven months at roughly half the estimated cost of a conventional rebuild. It is a promising vendor-reported result, with a comparison based on what the alternative was expected to cost.
Results like these make a strong case for trying the tools on a real project. They leave plenty to establish about your own application, including how much effort will go into integration, data migration and checking that everything still behaves correctly.
Diagnose the constraint before choosing a rewrite
Before deciding to rewrite an application, establish what is making it difficult to live with. Perhaps a framework is no longer supported. Perhaps every new feature requires changes across several systems. Or perhaps one troublesome component is responsible for most of the maintenance work.
Each situation calls for a different response. Updating the runtime or replacing a single component may deliver the benefit the business needs. A full rewrite makes sense when its value justifies the effort of reconstructing and validating the entire system.
Preserve the knowledge hidden in the old system
The code you inherit may contain years of useful knowledge. An unusual calculation might exist because of a particular contract. A seemingly redundant check may protect against a problem that only occurs at month end. Those details are easy to lose if the aim is simply to produce cleaner code.
AI can help engineers explore those details and explain how parts of an application fit together. Thoughtworks has described this use of AI to understand existing systems as an important opportunity in modernisation. The explanations still need checking against the running software and the people who use it.
Consider a billing calculation. The new version may look perfectly reasonable and pass its tests, yet round amounts differently from the old one. That difference can matter to every invoice. The team needs agreed examples of the expected results, including awkward cases, before replacing the calculation.
AI can help write the tests too. But tests built from the same mistaken assumption as the new code will not catch the mistake. Historical examples, trusted reference data and business review give those tests something independent to check.
Use a representative pilot to measure the whole job
This is where a carefully chosen pilot becomes valuable. Choose a real business function with an integration, some data and at least one difficult exception. It should be manageable enough to complete, while teaching you something useful about the wider project.
Count all the work. Time spent reviewing suggestions, correcting errors and investigating unexpected behaviour belongs in the calculation alongside the time saved writing code. Record defects and elapsed delivery time as well. A faster first draft is useful only if the team can turn it into an accepted result efficiently.
Give the engineers an approved environment for the tools, clear rules for handling source code and customer data, and limited access to systems. Keep someone accountable for the architecture and the release decision.
Replace one capability at a time
Where practical, use what the pilot teaches you to replace one capability at a time. Gradual replacement allows the business to check results while the remaining system keeps working. Agree how data will be reconciled, how failures will be handled and when the old component can finally be switched off.
Plan with ranges, not promises
For an initial engagement, we suggest allowing two to four weeks to assess the application and another four to six weeks for a representative pilot. At that point, there should be enough evidence to make a better decision about the next phase, including its budget and likely obstacles.
For the wider project, the following ranges are useful starting points for a conversation. They are illustrative planning allowances, not measured industry averages or delivery promises. They run from project kickoff, including assessment and pilot where applicable.
The first two ranges assume a dedicated team of roughly four to six people, accessible source code, usable environments and an available business owner. A larger programme needs its own staffing plan. Poor data, external suppliers or limited release windows can extend any of these schedules.
The calendar also depends on which work AI accelerates. In a simplified twelve-month programme, cutting a five-month engineering phase by 40% saves two months before additional setup or review. The other seven months of work still need to happen.
| Type of project | Illustrative timeframe |
|---|---|
| A bounded upgrade or component replacement | 2–4 months |
| A business application with a manageable number of integrations | 4–9 months |
| A core platform or portfolio of connected applications | 12–24 months or longer |
Translate engineering acceleration into business savings
The same principle applies to costs.
Imagine a modernisation project budgeted at €1 million. Of that, €600,000 covers work that AI can accelerate. If the team reduces the effort in that work by 40%, at unchanged rates, the gross saving is €240,000. Allow another €50,000 for additional tools, training and assurance, and the revised budget is €810,000.
That is a net saving of 19%. It is an illustrative calculation, not a TechHub case study or a forecast for every project. Normal testing and review are already included in the starting budget; the extra allowance covers only additional costs.
The benefit also depends on how the team is funded. If the same employees remain on the payroll, saved effort may mean more capacity for other work rather than a lower cash bill. Hosting, licensing and support savings should be measured separately, allowing for the period when both systems have to run.
Expect the economics to improve—but keep measuring
Looking ahead, we expect repeatable modernisation work to become more economical as tools improve and teams build up proven migration patterns. The first project has to establish much of the approach. Later projects can reuse that work when the applications share technologies and similar business requirements.
There is no dependable percentage by which costs will fall each year. Better tools still have to work with the organisation’s data, decisions and delivery process. Recheck the economics after each release, especially when changing tools or expanding into a less familiar part of the system.
Start with one application and one business objective
At TechHub Europe, we recommend starting with one application and a clear business objective. Understand what must keep working, test the approach on a representative piece of the system, and use the results to plan the next investment. That gives everyone involved a firmer basis for discussing cost, timing and risk.
If an older application is becoming difficult to support, contact hello@techhub.eu. We can discuss where an assessment would be useful and which part of the system would make a sensible starting point.