Most businesses have one: the system everyone works around. It runs orders, stock or billing, it was built a long time ago, and the one person who really understands it is not far from retirement. Legacy system modernization sounds expensive and risky, so the system stays. Then one day the decision gets made for you.
Here are seven signs it's time to plan the move, a quick self-check to run with your team, and what a low-risk modernization looks like in practice.
Why old systems get harder to live with
Age alone isn't the problem. Plenty of old software does its job well. The trouble is what tends to come with age. The U.S. Government Accountability Office, reviewing federal IT in a 2019 report, noted that about 80% of a planned $90 billion annual IT budget went on operating and maintaining existing systems.
It warned that legacy systems can become more expensive to maintain, more exposed to cyber risk and less effective at their job as they age. The 10 critical systems it singled out were between about 8 and 51 years old.
Private companies see the same pattern at a smaller scale. CIOs surveyed by McKinsey estimated that tech debt amounts to 20% to 40% of the value of their entire technology estate.
7 signs you need legacy system modernization
1. Only one or two people know how it works
If the system's logic lives in one developer's head, you carry a key-person risk. A holiday, an illness or a resignation can stall the business.
Check: Is there written documentation of what each screen and report does? Could someone new fix a fault next week?
2. It, or the platform under it, is out of support
Unsupported software stops getting security fixes. The UK's National Cyber Security Centre warns that weaknesses in obsolete products stay unpatched and can be exploited by relatively low-skilled attackers. Its guidance is blunt: the only fully effective way to remove that risk is to stop using the obsolete product.
Check: List the operating system, database and any packaged components, each with its end-of-support date.
3. Your team keeps a spreadsheet beside it
When people export data every day to do in Excel what the system can't, the spreadsheet has quietly become the real system, with no access control and no record of who changed what.
Check: Ask each team which spreadsheets they couldn't work without.
4. It can't connect to anything new
You want a portal for customers, an app for drivers or automated invoice matching, and every idea stops at "the old system can't talk to it."
Check: Count the projects shelved in the last two years because of integration.
5. Small changes take weeks
Adding a field, a report or a new tax rule should be routine. If every change needs a specialist, a long test cycle and crossed fingers, the system is costing you speed as well as money.
Check: Look at the last five change requests and how long each took.
6. Keeping it running eats the budget for anything new
If most of your IT spend goes on keeping the lights on, little is left to improve the business. The same McKinsey survey found CIOs diverting 10% to 20% of the budget meant for new products to dealing with tech debt.
Check: Split last year's IT spend into "keep it running" and "new capability."
7. Customers and staff notice
Slow screens, updates that only run overnight, orders customers can't check online, new hires who need weeks to learn the workarounds. When the system turns up in customer complaints or exit interviews, it has become a business problem.
Check: Ask your customer service lead and your newest hire what frustrates them most.
A quick self-check
Tick each statement that's true of your core system:
Fewer than three people could fix it if it broke tonight.
It runs on software or hardware past its end-of-support date.
At least one team relies on a side spreadsheet to do its job.
A project in the last two years was dropped because the system couldn't connect.
Simple changes take more than a couple of weeks.
More than half of IT spend goes on keeping it running.
Customers or staff complain about it by name.
One or two ticks: keep an eye on it and start writing down what it does. Three or four: build a plan this year. Five or more: standing still is probably riskier than moving.
What low-risk modernization looks like
The fear behind most delays is the big-bang switch: one weekend, everything moves, and Monday is chaos. You don't have to work that way. A safer approach replaces the system one module at a time:
Map what the old system really does. Sit with the people who use it and write down every screen, report and workaround, including the parts nobody documented.
Pick the safest module to replace first. Often a self-contained area such as stock or orders.
Run old and new side by side. Copy the records across, then compare record counts and totals until the figures match.
Switch only on approval. People move to the new module when the person you name signs off.
Repeat. The old system shrinks piece by piece until you can switch it off.
This is how our legacy modernization projects run, with the new code and every migrated record held in accounts under your name.
Rehost, rebuild, replace or retire?
Option | What it means | Fits when |
|---|---|---|
Rehost | Move the system as it is onto newer infrastructure or the cloud | The software works but the hardware or platform is aging |
Rebuild by module | Rewrite it in current technology, one area at a time | The business logic is valuable and specific to you |
Replace with a package | Move to an off-the-shelf product and retire the old system | Your process is standard and a package covers it well |
Retire | Switch it off, archive the data and move what little is still used elsewhere | Few people use it and nothing new depends on it |
Many projects mix these. If you're weighing a package against a rebuild, our custom software development page explains how a rebuilt system is scoped, owned and handed over.
When to leave it alone
Modernization isn't always the answer. If the system is supported, secure, rarely needs changing and isn't blocking anything, the cheapest option may be to keep it, document it and let newer tools read its data. Where it has no way to connect, a software robot that types into its screens can buy useful years without touching the core.
If you keep it, make keeping it safe. Write down what it does, train a second person who can support it, test that your backups actually restore, and put its end-of-support dates on your risk register. Then review the seven signs once a year.
Frequently asked questions
How long does legacy system modernization take?
It depends on the size of the system, how many modules it has and how clean its data is. Working module by module means one part of the business sees results early, instead of everyone waiting for the whole thing.
Will we lose data in the move?
You shouldn't. Every record should be copied, counted on both sides and reconciled against the old system before anyone relies on the new one.
What if nobody documented the old system?
That's common. What it does can be worked out from the screens, reports, data and the people who use it every day, and written down as part of the project. You end up with documentation the old system never had.
Do we have to stop work during the switch?
No. With old and new running side by side, staff keep working in the old system until the new module is proven and approved.
If a few of these signs sound familiar, a short call is a sensible next step. Book 30 minutes with a founder and walk us through your system. You'll leave knowing which part we would move first and how your team keeps working in the meantime. If replacing it is the wrong move, we'll tell you.
