Quick Overview
There’s a version of this story playing out in engineering firms across the UK right now.
A quoting system built in the early 2000s still runs the business. It works, mostly. But the developer who built it retired, the server it lives on is out of warranty, and last month a major client asked whether your systems could integrate with their procurement platform. The honest answer was no.
If that sounds uncomfortably familiar, you’re in the right place. This isn’t a guide about whether legacy systems are a problem. You already know they are. It’s a guide about where to start, because that’s the question that actually stalls modernisation projects.
By the end of this article, you’ll know how to assess what you have, which approach suits your firm, what it’s likely to cost, and how to avoid the mistakes that turn a sensible project into an expensive one.
The instinct to leave a working system alone is understandable. Engineering firms are built on reliability, and “if it isn’t broken, don’t fix it” has kept plenty of machinery running for decades. Software, though, breaks differently. It doesn’t seize up overnight. It becomes slowly more expensive, more fragile, and more limiting until the cost of keeping it exceeds the cost of replacing it.
The application modernisation statistics across industries tell the same story: maintaining ageing systems quietly consumes budgets that could fund improvement instead.
Three pressures make this urgent for UK firms specifically.
The knowledge that keeps your system alive is walking out of the door. Many engineering businesses depend on systems written in VB6, Delphi, or old AS400 environments. The people who understand these platforms are retiring, and the pipeline of developers learning them is effectively empty. Every year you wait, the pool of people who can maintain your system shrinks, and their day rates rise accordingly.
Certification and insurance expectations have hardened around modern, patchable systems. Cyber Essentials certification is increasingly a condition of winning contracts, particularly in defence, utilities, and public sector supply chains. Unsupported operating systems and unpatched applications make certification difficult or impossible.
Add UK GDPR obligations around data handling, the audit trails expected under ISO standards, and the records behind UKCA marking, and legacy software becomes a commercial liability, not just a technical one.
Your clients are digitising, and they expect you to keep up. Larger manufacturers and main contractors are pushing digital requirements down their supply chains: electronic data exchange, live project reporting, integration with their systems. Firms that can’t participate get quietly moved down the preferred supplier list. This is where digital transformation for engineering stops being an abstract idea and starts affecting the order book.
Technical debt behaves like financial debt. The interest compounds. The question isn’t whether to pay it down, but whether you do it on your own schedule or when a failure forces your hand.
Not every system in an engineering business carries the same risk, and modernisation rarely means replacing everything at once. In practice, UK engineering firms most often modernise a familiar shortlist.
If several of these describe your firm, that’s normal. Naming what you’re dealing with is the first exercise in the roadmap below, so consider this a head start.
Some firms modernise because of a strategic decision. Most modernise because the warning signs became impossible to ignore. Here’s what those signs look like in practice.
Only one or two people understand how the system works. If a single retirement or resignation would leave you unable to maintain critical software, you have a business continuity problem wearing a technology costume.
The software has passed its supported life. No patches, no security updates, no help when something breaks. You’re on your own with software your operations depend on.
The system can’t talk to anything else in the business. Modern tools assume integration. If moving data means manual re-entry or CSV exports, you’re paying a hidden labour tax every single day.
The information exists, but getting at it is a project in itself. A straight answer about job profitability or workshop capacity shouldn’t require hours of manual assembly from three different systems and a spreadsheet.
Updates quietly stopped arriving, and nobody flagged it. Unsupported systems accumulate known vulnerabilities. Insurers and certification bodies are paying attention to this, even if nobody internally is.
Growth means bolting on another manual process. New product line, new site, new client requirements: each one needs a workaround because the system can’t flex. The workarounds then become their own legacy problem.
The technology is shaping how candidates see the business. Skilled engineers and administrators notice when a firm runs on decades-old software. It colours their impression of the whole operation.
One or two of these might be manageable. Three or more, and the risks of not modernising are almost certainly growing faster than the cost of addressing them.
“Modernisation” covers several very different strategies, and choosing the wrong one is where budgets go to die. The industry typically frames the options as a set of Rs, and our broader guide to legacy application modernisation unpacks each in depth. Here they are in plain English, ordered roughly from least to most involved.
| Approach | What It Means | Best For | Relative Cost |
|---|---|---|---|
| Rehost (“Lift and Shift”) | Move the application as-is to new infrastructure, usually the cloud | Stable systems on failing hardware | Low |
| Replatform | Move it with modest upgrades, such as a managed database or updated runtime | Systems that work well but sit on unsupported foundations | Low to Medium |
| Refactor | Restructure the existing code without changing what it does | Valuable systems with maintainability problems | Medium |
| Rearchitect | Materially alter the design, for example breaking a monolith into services | Systems that must scale or integrate in ways the old design prevents | Medium to High |
| Rebuild or Replace | Rewrite from scratch, or adopt an off-the-shelf product | Systems beyond economic repair, or where a modern product now fits | High |
So, rewrite vs replatform vs rehost: which is right? The honest answer is that it depends on two questions. First, does the system still match how your business works? If yes, cheaper approaches like rehosting or replatforming preserve that fit. If the business has outgrown the system’s logic, moving it to the cloud just gives you the same problems on newer servers.
Second, how good is the underlying code and data? A well-structured system with messy infrastructure suits replatforming. A tangled codebase holding clean, valuable data often justifies a rebuild, with careful data migration as the centrepiece.
Most real projects mix approaches: rehost the stable parts, rebuild the one module causing daily pain. That’s not indecision. It’s good engineering.
Here’s how to modernise a legacy system step by step, in the order that actually reduces risk. The first two steps cost relatively little and tell you almost everything you need to know.
Map every system, who uses it, what it connects to, and what happens if it fails. Most firms discover their real system landscape is bigger and messier than anyone thought: shadow spreadsheets, forgotten Access databases, integrations held together by scheduled exports. Document dependencies especially. The quoting tool might look standalone until you learn the workshop schedule reads from it. This audit becomes the single source of truth for every decision that follows.
Rank systems by the friction and risk they cause, not by how old they are. The oldest system isn’t automatically the most urgent. A twenty-year-old tool that runs quietly and reliably can wait. A five-year-old system that blocks a major client integration cannot. Score each system against a few simple criteria: operational risk, cost of workarounds, compliance exposure, and how much it constrains growth. Your starting point is usually obvious once it’s on paper.
Pair every priority system with one of the approaches above, and pressure-test the choice. This is where the audit pays off. With dependencies and data quality documented, you can judge whether a system needs a light touch or a rebuild. Be sceptical of anyone recommending a full rewrite of everything, and equally sceptical of anyone promising the cloud alone will fix a system your business has outgrown.
Break the work into stages that each deliver something usable, with the old system as a safety net. Engineering firms can’t pause production for a software project, which is why sensible modernisation is phased. Run old and new in parallel during transition. Migrate data early and validate it obsessively, because historical job records, drawings, and costing data are often the most valuable asset in the whole project. Done well, this is how you modernise legacy software without downtime: nothing is switched off until its replacement has proven itself.
Make integration, security, and adaptability part of the design, not an afterthought. Modernisation is the one moment you get to set the foundations properly. That means open APIs so future tools can connect, cloud infrastructure that scales with the order book, and security built in from the start. It’s also the natural moment to prepare for Industry 4.0: machine data, sensor feeds, and AI-driven analysis all need modern systems underneath them. Firms that treat modernisation as a foundation, not a patch, only pay for the disruption once.
The question every director asks first, and the one most articles dodge. Costs vary widely with scope, so treat the figures below as indicative market ranges for UK projects rather than quotes. They exist to help you budget in the right order of magnitude.
| Project Tier | Typical Cost (GBP) | Typical Timeline |
|---|---|---|
| Small-Scale Projects | £15,000 – £40,000 | 4 – 12 weeks |
| Mid-Scale Projects | £40,000 – £120,000 | 3 – 8 months |
| Large-Scale Projects | £120,000 – £350,000+ | 8 – 18 months |
Here’s what each tier typically covers in practice:
A useful comparison: what does the legacy system cost you now? Manual workarounds, maintenance premiums for scarce skills, lost bids, and downtime add up to a figure most firms have never actually calculated. Modernisation looks expensive until it’s set against that number.
Several variables explain why two similar-sounding projects can carry very different price tags.
The most reliable way to control cost is the phased approach from the roadmap: each stage produces something usable, and you can pause, adjust, or accelerate between phases with real information rather than guesswork.
Modernisation projects rarely fail for technical reasons. They fail for predictable, human ones. These are the patterns worth guarding against.
Replacing everything at once is the most tempting option and the most dangerous, because it concentrates all the risk into one cutover date and delivers no value until the very end. Phase the work instead, and let each stage prove itself.
Firms that jump straight to choosing software discover mid-project that a forgotten dependency breaks the plan. The audit feels slow, but it’s the fastest step in the whole project once you count the rework it prevents.
The system exists to run the business, so the people who run the business need to shape its replacement. When workshop supervisors, estimators, and office staff are consulted late or not at all, the result is technically modern software that nobody wants to use.
Code can be rewritten. Twenty years of job history, costings, and design records cannot be recreated. Data migration deserves planning, budget, and validation from day one, not a line at the bottom of the schedule.
A development team that has never seen a works order or a BOM will spend your budget learning your industry. Ask any prospective software modernisation company how engineering and manufacturing businesses actually operate, and listen carefully to the answer.
Avoid these five, and you’ve already sidestepped the majority of the ways these projects go wrong.
For years, the economics of modernisation were dominated by one brutal fact: understanding an old, undocumented system took almost as long as rebuilding it. AI is changing that equation, and it’s worth understanding how, because AI-powered legacy modernisation is quickly moving from novelty to standard practice.
AI tools can read a legacy codebase, map its structure, and surface the business logic buried inside it in a fraction of the time manual review takes. For firms whose original developers are long gone, this recovers knowledge that seemed lost and shortens the discovery phase considerably.
Much of the heavy lifting in converting code between languages and frameworks can now be done by AI. Human engineers still review, correct, and test everything, but the starting point is dramatically further along than a blank page.
Proving the new system behaves like the old one is one of the riskiest parts of any modernisation. AI-generated test suites can compare outputs across thousands of scenarios, catching discrepancies that manual testing would miss.
Once your data is out of its silo and onto a modern platform, AI becomes a working tool rather than a project method: predicting maintenance needs, flagging anomalies in job costing, and turning years of dormant records into decision support.
The practical effect is that projects which were uneconomic three years ago are now viable, particularly for mid-sized firms. If you priced modernisation a while ago and flinched, it may be worth pricing it again.
Small rehosting or replatforming projects typically run a few weeks to three months. Rebuilding a core business application usually takes six to twelve months, delivered in phases so value arrives well before the end. Multi-system programmes run longer, but a well-planned project should show working results within the first quarter.
Yes, and for engineering firms this should be a non-negotiable requirement. Phased delivery, parallel running, and staged cutovers mean the old system stays available until its replacement is proven. Disruption is a symptom of poor planning, not an inherent cost of modernisation.
Modernise when the system still matches how your business works and the problems are technical: old infrastructure, poor integration, unsupported platforms. Replace when the business has outgrown the system’s underlying logic, or when a modern off-the-shelf product now covers what once needed bespoke software. The audit in Step 1 usually makes the answer clear.
It moves with you. Data migration is a core part of any properly scoped project, including cleaning, mapping, and validating records so decades of job history, costings, and documents remain accessible in the new system. In many projects, historical data ends up more usable than it ever was in the legacy system.
Yes. Modernisation projects are delivered remotely with structured communication, so location within the UK is no barrier. Discovery workshops, progress reviews, and support all work the same whether a firm is in Sheffield, Glasgow, or Southampton.
If this article has done its job, you now have a clearer picture than most firms start with: you know what an audit involves, which approach categories exist, what UK projects broadly cost, and where the traps are. The distance between “we should do something about the old system” and a funded, de-risked plan is shorter than it looks. It starts with an audit, not a leap.
At Zealous System, this is the work we do. As an AI-powered software development company providing legacy software modernisation services to UK firms, we combine application re-engineering experience with the AI-assisted analysis and migration techniques described above, which means faster discovery, safer migrations, and budgets that stay closer to their estimates.
Our team has delivered legacy system modernisation for the energy industry, rebuilding ageing operational software into a modern, maintainable platform, and modernised the reporting module of a legacy eLearning system, turning locked-away data into usable insight. Different sectors, same underlying challenge: critical systems that had outlived their foundations.
If you’re weighing up where your own firm should start, a conversation costs nothing and usually saves a lot of second-guessing. Bring your messiest system and your hardest questions. Let’s talk.
Our team is always eager to know what you are looking for. Drop them a Hi!
Ruchir Shah is Technology Head at Zealous System with hands-on expertise in AI/ML, Microsoft Azure, .NET, Node.js, Python, React, and Angular. He leads enterprise software development, champions digital transformation, and mentors developers building the future of intelligent apps.
Comments