Modernisation does not have to mean replacement.
- Keep what works, connect it, and rebuild only the parts that hold the business back.
- Work in small stages, each one tested against the old system before it goes live.
- Retire the old system last, and only when nothing depends on it.
Somewhere in your plant there is probably a piece of software that nobody wants to touch. It handles quotes, or job tracking, or production reporting. It was written years ago, it runs on a server that is past its support date, and one person understands how it works. It is also the reason orders go out on time.
Legacy software modernisation means updating, connecting or rebuilding applications like this in controlled stages, so they stay secure, supportable and connected while production carries on. This guide walks through twelve steps, from deciding why the system has survived this long to deciding when to leave it alone.
12 Ways to Modernise Legacy Manufacturing Software
Why industrial companies keep legacy software
It is easy to call old software a mistake. It usually is not. Industrial companies keep legacy applications because they work, and because replacing them is genuinely hard.
- They encode years of business rules, such as pricing logic, tolerances and customer-specific exceptions, that were never written down anywhere else.
- People know them. Retraining a floor team mid-order book has a real cost.
- They are wired into other things: ERP, machines, label printers, spreadsheets, scheduled reports.
- The plant cannot stop. A system that supports shipping cannot be down for a weekend of experiments.
The scale of this is well documented. Hexagon's 2025 America's State of Manufacturing report found that 72% of surveyed manufacturers cite outdated technology as a key obstacle. Parsec's 2026 State of Manufacturing survey found that 69% run a hybrid mix of legacy and modern equipment, and only 37% have a unified, data-driven strategy in place. Mixed estates are the norm, not the exception.
Why replacing it is risky
The instinctive fix is a big-bang replacement: choose a new platform, build or buy it, and switch over on a set date. It can work. But it concentrates risk into a single moment.
- Lost business rules. What the old system did that nobody documented simply disappears at cutover.
- Data migration errors that only surface once real orders flow.
- Broken integrations with machines, ERP and reporting that nobody listed.
- One cutover date with no easy way back.
- User resistance, because the new system changes everything at once.
Standing still carries risk. Microsoft ended extended support for SQL Server 2016 on 14 July 2026. Windows Server 2016 follows on 12 January 2027, and the last paid security updates for Windows Server 2012 and 2012 R2 end on 13 October 2026. Check the Microsoft lifecycle pages for the exact products under your applications. The answer to a deadline is a plan, not a panic cutover.
Assess the current system
Before changing anything, find out what you actually have. Spend a few weeks on discovery, not months, and score each application on six points.
| Check | Questions to answer |
|---|---|
| Business criticality | What stops if it fails? How many people and processes depend on it? |
| Technical health | Language, framework, database and operating system versions. Are they still supported? |
| Change frequency | How often does the business ask for changes, and how long do they take? |
| Integrations | What does it feed or read from: ERP, machines, finance, spreadsheets, label printers? |
| Knowledge | Is there documentation and source code? Who understands it, and how many people? |
| Security and compliance | Is it exposed to the network? Does it hold data or records you must retain or audit? |
The result is a short list: which systems are critical and fragile (act first), critical and stable (protect and connect), and neither (leave alone or retire).
Identify business-critical functionality
Not everything in a legacy application is worth keeping. A typical system has three kinds of function:
- Must keep: the things the business cannot run without, such as quoting rules, work-order flow, traceability records.
- Nice to have: features that are used, but could change without harm.
- Never used: screens, reports and options left over from past needs.
Find them by watching people work, not just by reading code. Ask what they do at month-end, when something goes wrong, and what they export to Excel. Hidden functions are the ones that hurt: the scheduled job that emails a report, the calculation inside a stored procedure, the label that prints automatically. If usage logs exist, use them to see what is really touched.
Separate UI, logic and data
Old applications tend to mix everything together: screens that contain database queries, business rules written into forms. That tangle is what makes them frightening to change. Untangling it, even partly, is what makes every later step safer.
Work from the bottom up. Put data access behind one controlled path first. Then move business rules into a service layer that any front end can call. Rebuild the interface last, because it is the most visible and the least risky to change once the rest is stable. Stored procedures that work well can stay. The goal is clear boundaries, not a purge.
Build APIs around existing functionality
An API layer lets new tools use the old system's functions without touching its internals. A mobile app can look up a job. The ERP can receive an approved quote. A reporting tool can read production data. None of them needs to know how the legacy application works underneath.
- Start with read-only endpoints for data other systems need. They carry the least risk.
- Add write operations only when validation rules are clear and tested.
- Put authentication, logging and rate limits in from the start.
Be honest about the limit: an API wrapper buys time and enables integration, but it does not fix an unsupported operating system or database underneath. Treat it as stage one, not the finish line. See our API integration services and legacy system modernisation work, and our business guide to REST, webhooks and FTP.
Modernise in modules
This is the heart of avoiding disruption. Instead of replacing the whole system, replace one function at a time, and route work to the new module once it is proven. Martin Fowler named the approach the strangler fig pattern: the new system grows around the old one and gradually takes over until the old one can be removed.
Choose the first module by two tests. It should hurt (people complain about it daily) and it should be isolated (few hidden dependencies). Job tracking, a customer portal or a reporting dashboard often fit. Avoid starting with the core pricing engine just because it is the most important. Importance is a reason to do it carefully, not first.
Each module should be live, used and measured before the next one starts. If priorities change, you stop with something that works.
Parallel testing
Parallel testing means running the old and new versions side by side on the same real inputs, and comparing results before anyone depends on the new one.
- Replay real history. Feed last quarter's quotes, orders or work orders through both and compare outputs.
- Define "same" first. Exact match for costs and quantities. Agreed tolerances for anything involving rounding or dates.
- Test the awkward cycles: month-end, year-end, rare product variants, returns and cancellations.
- Run in shadow mode. The new module processes live data, but the old system remains the one that counts.
- Let real users try it, with a simple way to report differences.
Every discrepancy is either a bug in the new system or an undocumented rule in the old one. Both are findings you want before cutover, not after.
Migration
Data and users move last, and in rehearsed steps.
- Clean and map the data. Decide what moves, what is archived and what is dropped.
- Rehearse the migration several times on copies, reconciling record counts and key totals each time.
- Migrate in slices, such as one plant, product line or customer group, rather than everything at once.
- Pick a quiet window, for example a planned shutdown or low-volume period, and freeze changes before it starts.
- Write the rollback plan and agree in advance what result would trigger it.
- Train and support users before and after, with someone available on the floor.
Controlled retirement
An old system is not retired when the new one goes live. It is retired when nothing depends on it.
- Switch the old system to read-only for a defined period, usually through at least one month-end and, if possible, one quarter-end.
- Monitor access. If someone still logs in, find out why.
- Archive the data in line with your retention and audit requirements.
- Remove integrations, scheduled jobs and credentials.
- Decommission servers and licences, and update documentation.
Running software you cannot afford to switch off?
We will review the system, the risks and the options, and tell you honestly whether to wrap it, rebuild part of it or leave it alone.
Talk to InfomazeWhen not to modernise
Modernisation is not always the right call. Leave a system alone, or retire it without a rebuild, when:
- It is stable, supported, rarely changed and not blocking integration or security. Ring-fence it, back it up and review it yearly.
- The process itself is going away or is about to change significantly.
- A standard SaaS product now covers the function well enough. Our guide on when to buy and when to build helps here.
- The real problem is data quality or process, not software. A new application will inherit both.
- There is no business owner for the system. Without one, nobody can decide what "correct" means.
Sometimes the most valuable output of an assessment is a clear decision to do nothing for now, with a date to revisit.
Practical checklist
- Inventory every legacy application, with owner, users, hosting and support status
- Record every integration, scheduled job, report and spreadsheet that depends on it
- Check operating system, database and framework support dates
- Confirm you have the source code, database access and credentials
- List the business-critical functions and agree them with the people who use them
- Capture business rules that exist only in code, stored procedures or people's heads
- Take a verified backup and prove you can restore it
- Separate user interface, business logic and data where practical
- Put an authenticated, logged API around the functions other systems need
- Choose the first module by pain and isolation, not by size
- Define what "same result" means before parallel testing starts
- Rehearse data migration more than once and reconcile totals and counts
- Agree cutover window, rollback trigger and rollback steps in writing
- Run the old system read-only, then archive data before decommissioning
If you also have manual workflows sitting around these systems, our article on ERP workflow automation covers the processes outside the application, and our industrial software, automation and AI page shows how it fits together.
Modernisation does not have to mean replacement.
Tell us what your legacy software does and what is putting it at risk. We will recommend the lightest sensible path.
Frequently Asked Questions
Sources: Hexagon, America's State of Manufacturing Report 2025 (as cited by Hexagon Manufacturing Intelligence). Parsec, State of Manufacturing Industry 2026. Microsoft product lifecycle dates for SQL Server 2016 and Windows Server 2012/2012 R2/2016, as reported by secondary sources; confirm against Microsoft's lifecycle pages. Martin Fowler, StranglerFigApplication.