Legacy system: what it is, when it is a risk and how to modernize it without stopping work
Your system works, but nobody dares touch it: its version is out of support, the provider who built it no longer answers and every change breaks something else. This guide helps you size the risk, choose the route and change providers without switching the operation off.
What a legacy system is
In short: a legacy system is software your company still uses every day but can no longer change safely.
It is not the same as an old system. A ten-year-old system that is kept up to date, backed up and understood by more than one person is not legacy. A three-year-old one built on a version that no longer gets patches, with no documentation and known only to whoever wrote it, is.
In mid-sized companies it usually looks like one of these:
- An online store or a portal custom-built years ago, on a version of PHP or of its framework that no longer receives security updates.
- An internal desktop system that only runs on one office computer.
- An Access database or a spreadsheet full of macros that the operation depends on and nobody else can edit.
- A system built by a provider that has closed, moved on or takes weeks to reply.
Legacy does not mean it should be thrown away. It usually holds years of business rules that work. The problem is that those rules are trapped in something that can no longer move.
When a legacy system becomes a risk
While it works, it is easy to put off. These signs say waiting no longer pays:
- The language or framework version no longer gets security patches. PHP 7, for example, stopped receiving them between 2019 and 2022, depending on the version. If your system takes payments online or stores customer data, that gap is yours.
- Your hosting no longer offers that version, or charges extra to keep it.
- Only one person knows how it works, and they are not on your payroll.
- You do not have the code, server access or the database in your company's name.
- Every small change takes weeks and breaks something somewhere else.
- It cannot connect to what you need today: your invoicing, your ERP, WhatsApp or a new payment gateway.
- Nobody has ever tested restoring a backup.
With one or two signs there is time to plan. With several, the risk is that a failure makes the decision instead of your company.
What to check before deciding
Before talking about rewriting or upgrading, you need a diagnosis. It is not a long document: it is knowing what you have, who owns it and what must not break.
| What to check | Why it matters |
|---|---|
| Access: code, server, database, domain and email | Without it nothing can be done safely. The first step is having it in your company's name. |
| Versions: language, framework, database and server | They say how much support is left and how big the jump to upgrade is. |
| What is critical: payments, orders, invoicing, inventory | It is what gets tested first and what cannot fail on the day of the switch. |
| Integrations: payment gateway, invoicing, shipping, ERP | Every connection is a dependency with its own versions and credentials. |
| Data: how much, how clean and where it lives | Data migration is usually the longest part and the most underestimated. |
| Real use: who uses which screen and what nobody uses anymore | What nobody uses is not migrated. It is often a large part of the system. |
The four ways to modernize it
There is no single answer. These are the routes, from least to most change:
| Route | What it is | It fits when |
|---|---|---|
| Secure and maintain | Upgrade versions, close security gaps, sort out backups and document it, without changing what the system does | The system does its job well and is only out of date |
| Upgrade in parts | Replace it module by module while the old system keeps running, until none of it is left | The system is large and cannot stop, but some parts are in the way |
| Rebuild in stages | A new system, with what the old one already did well and without what nobody uses, going live in stages | The version jump is so large that upgrading costs almost as much as building |
| Replace with off-the-shelf software | Move to a packaged product (an ERP, an online-store platform) and retire your own system | What the system did no longer sets you apart and a standard product covers it |
The two in the middle are the most common in mid-sized companies. And they combine: first secure what is there, to buy time, then replace it in parts.
The rule for choosing is the same as with any software: what is part of how you compete (your sales rules, your pricing, your after-sales) is worth having custom; what is the same in every company (accounting, payroll) usually fits better in a packaged product.
How to modernize without stopping operations
The goal is that your customers and your team do not notice the change, except that the system finally does what they were asking for.
- Secure access and backups first, and test that a backup can actually be restored.
- Set up a copy of the system outside production. That is where it is upgraded and tested; the live system is left alone.
- Write tests for what is critical: that a payment can be taken, an order placed and an invoice issued. If those pass, the rest can be fixed.
- Upgrade or replace in parts, and put each part live on its own while the rest of the system keeps working.
- Rehearse the data migration more than once with real data, before the day of the switch.
- Switch over at a quiet time, with a plan to go back to the previous version if something fails.
- Afterwards, maintain it: scheduled updates so the system never falls behind again.
The most expensive mistake is rewriting everything in secret for a year and switching all at once. In stages it takes as long, but the risk is spread out and every stage is already useful.
How to change providers without losing your system
A legacy system often comes with a provider problem: whoever built it no longer offers support, or it no longer makes sense to stay with them. A new provider can take over a system it did not build, as long as it has what it needs.
What to ask your current provider for, in writing:
- The complete code, in a repository in your company's name.
- Access to the server, the database, the domain and connected services (payments, email, invoicing).
- Whatever documentation exists: how it is installed, how it is deployed and what each integration does.
- The list of pending changes or known problems.
If the contract with the previous provider does not say who owns the code, check it before you ask. The guide on software development contracts explains which clauses settle it, so the next contract does not repeat the problem.
The new provider should start with the diagnosis above, tell you what state the system is in and propose a route in stages. If the first thing they propose is rewriting everything without having looked at it, be wary.
Frequently asked questions
What does legacy mean in software?
A legacy system is one your company inherited from another era or another provider: it still works, but it can no longer be changed or maintained safely.
Does the whole system have to be rewritten?
Almost never all at once. Often it is enough to upgrade versions and secure it, or to replace it in parts while it keeps running. Rewriting makes sense when the version jump costs almost as much as building, and even then it is done in stages.
How much does it cost to modernize a legacy system?
It depends on the route. What drives the cost: how far behind the versions are, how many integrations it has, how much data needs migrating and how well documented it is. That is why the diagnosis comes first, and the proposal comes in stages, each with its own scope.
What if the previous provider will not hand over the code?
Check your contract first: it should say who owns the code. If the system runs on a server in your name, the code is usually there. If there is no way to recover it, the route is to rebuild in stages from how it works today and from the data, which can always be exported.
Can I keep selling online while it is modernized?
Yes, that is the point. Everything is upgraded and tested on a copy; each part goes live on its own, and the final switch happens at a quiet time with a plan to go back if something fails.
Has your operation outgrown spreadsheets?
Tell us how you sell, quote and serve today. We'll tell you what we would build, and in what order.