Legacy System: What It Is, Why Businesses Keep One and How IT Teams Contain and Migrate It
What a legacy system is, why businesses keep running unsupported technology, the risks after Windows 10 end of support, and how IT teams and MSPs contain, monitor and migrate legacy systems, with 2025-2026 data from GAO, Ensono and StatCounter.
Updated: November 2026
Plenty of client estates have one: the PC that runs the lab machine, the accounting app nobody can reinstall, the server the last admin warned about two years ago. A legacy system keeps working long after its vendor stops supporting it, and that gap between "works" and "supported" is where the risk lives. This guide covers what counts as legacy, why businesses keep these systems, and how IT teams and MSPs contain, monitor and migrate them without breaking the business that depends on them.
TL;DR
- The definition. A legacy system is hardware or software still in production after its vendor stopped fixing it, or that nobody can safely change.
- Why it stays. It works, replacement is expensive, and some equipment only talks to old software.
- The risk. No security patches, so every month the gap to a patched system grows.
- The plan. Contain it on its own network, monitor it closely, then migrate it on a schedule.
What Is a Legacy System?
A legacy system is a piece of technology the business still depends on, but which can no longer be maintained the normal way. Usually that means the vendor stopped shipping security fixes. Sometimes it means the vendor is gone, the code has no owner, or the one person who understood it left.
Age isn't the test. A 15-year-old IBM i box with a support contract is old, not legacy. A three-year-old PC on Windows 10 with no Extended Security Updates is legacy, because nothing patches it anymore. The question is simple: if a new vulnerability shows up tomorrow, does anyone ship a fix?
What makes it legacy is the combination: business-critical, wired tightly into how the company works, and unsupported or unchangeable. Remove any one of the three and it's just an old system.
Here's what that looks like in a typical client estate.
| Type | Example | Why it's stuck |
|---|---|---|
| Operating system | Windows 10 PCs outside ESU, Windows Server 2012 R2 | Hardware fails the Windows 11 check, or an app only runs there |
| Equipment controller | Windows XP or 7 PC running a CNC machine, lab analyzer or imaging device | The equipment vendor never shipped drivers for anything newer |
| Line-of-business app | A custom Access database, an old ERP, a 32-bit practice management app | No source code, no vendor, or the upgrade is a full re-implementation |
| Infrastructure | An out-of-support hypervisor, an old firewall, end-of-life server hardware | It runs everything else, so nobody wants to be the one who touches it |
Why Businesses Keep Legacy Systems
The short answer: it works, and replacing it costs money that has to come from somewhere. A production machine with a perfectly good controller doesn't get scrapped because Microsoft stopped patching the PC bolted to its side.
Budgets make the call stickier. In Ensono's 2025 State of IT Modernization report, a survey of 500 US and UK IT decision-makers at companies with $500 million or more in revenue, 49% said legacy maintenance costs ran over plan in the past year. 86% said budget limits hold back their other projects, and 9 in 10 reported at least one skills gap slowing modernization. Those are large companies with large IT teams. A 40-seat client feels the same squeeze with less room.
Government is no different. In July 2025, the US Government Accountability Office ranked 11 federal legacy systems as the most critical to modernize, from 69 that agencies submitted. GAO found these systems used outdated languages, ran unsupported hardware and software, and had known security vulnerabilities. Of the 10 systems GAO flagged in 2019, agencies had finished modernizing three by February 2025.
Then there's the human side. Some systems stay because the person who could replace them is busy, or gone. In a July 2026 r/sysadmin thread, a new IT manager found most physical hosts at end of life, plus a year-old warning email from the long-time server admin that went nowhere. Nobody decided to keep the old servers. Nobody decided anything.
The Risks of Running a Legacy System
Nothing breaks on the day support ends. The system boots, the app opens, the users don't notice. What stops is the maintenance, and the risk builds quietly from there.
Unpatched vulnerabilities. Windows 10 reached end of support on 14 October 2025. Eleven months later it still accounted for 27.82% of Windows traffic worldwide in September 2026, per StatCounter. Every Patch Tuesday adds fixes that a Windows 10 PC outside ESU never receives. Its distance from a patched machine grows by a month, every month.
The cost of staying patched. Extended Security Updates buy time, at a price that's meant to hurt. Commercial ESU for Windows 10 costs $61 per device in year one and doubles each year, so three years cost $427 per device. Our Windows 10 end of life guide has the full date table, including LTSC editions with their own clocks.
Breach cost. IBM's 2025 Cost of a Data Breach report put the global average breach at $4.44 million. An unpatched system on a flat network is one of the cheapest ways in for an attacker, and one of the most expensive for the client.
Compliance and insurance. HIPAA, PCI DSS and cyber insurance questionnaires all ask some version of "do you run unsupported software?" Answering yes isn't automatically a fail. Answering yes with no documented compensating controls usually is.
Integration debt. Old systems often can't do modern authentication. No MFA, no SAML, no conditional access, sometimes SMBv1 or NTLMv1. So the legacy box becomes the exception in every security policy, and exceptions are where attackers go looking.
Knowledge loss. The fewer people who understand a system, the longer an outage on it lasts. A legacy app with one expert is one resignation away from being a mystery.
Servers run on their own clock. The next big one is Windows Server 2016, which leaves extended support in January 2027.
How to Contain a Legacy System
Containment is what you do on day one, before any migration plan is signed. The goal is to make the system hard to reach, hard to abuse and easy to rebuild. The practices below come straight from what sysadmins report doing with machines they can't replace.
- Put it on its own network segment. A dedicated VLAN with deny-by-default firewall rules. Allow only the ports and hosts it needs, and block internet egress unless the vendor needs a specific endpoint.
- Reach it through one door. Admin access only through a jump host or a privileged access tool, with MFA on that door, since the system itself may not support it.
- Take away the easy wins. No local admin for users, no email or web browsing on the box, USB storage blocked, unused services turned off.
- Allowlist what runs. AppLocker or Windows Defender Application Control on Windows, so only the app and its dependencies execute.
- Keep a way back. A tested image backup stored offline, and spare hardware if the system depends on a specific board or card.
- Write down the exception. Who owns the risk, why it's accepted, the compensating controls, and the review date.
That last one matters more than it looks. It turns "we know it's bad" into a decision someone signed, with a date to revisit it.
This r/sysadmin thread from April 2026 is a good snapshot of where teams landed six months after Windows 10 support ended. The top reply describes XP machines running equipment on an open network, with the admin wishing they could get them onto a separate one. Further down, one admin keeps two XP controllers for six-figure machines fully cut off from outside connections, down to USB, with pre-built spares tested on a schedule. Another says to announce your own cutoff date to every client, then stop supporting tickets from Windows 10 machines after it.
The isolated XP pair is what containment looks like when it's done well. Old, yes. Reachable, no.
How to Monitor Legacy Systems
You can't contain what you haven't found. Start with an inventory of every device and its OS build, then flag anything past its vendor's support date. On Windows, two lines per device tell you most of it:
powershellGet-CimInstance Win32_OperatingSystem | Select-Object Caption, Version, BuildNumber, LastBootUpTime Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 1 HotFixID, InstalledOn
Run that across every client and you get a list of OS versions and last-patch dates. Anything on Windows 10 without ESU, Server 2012 R2 or older, or with no update in 60 days goes on the legacy register. OpenFrame can run a script like this across a client's devices and collect the output in one job, which turns the inventory into a report rather than a week of remote sessions.
Once a system is on the register, watch it more closely than the rest of the fleet, because it can't defend itself with patches. Alert on new outbound connections from its segment, logons outside the usual accounts or hours, new services or scheduled tasks, failed backups, and disk health warnings on old hardware. Old disks fail without asking first.
Review the register monthly. Each entry should have an owner, a reason, a containment status and a target date. If the target date passes twice, that's a conversation with the client, not a note in the ticket.
How to Migrate a Legacy System
Containment buys time. Migration spends it. Pick the route by what the system does and what's stuck about it, not by what's newest.
| Route | What it means | Fits when |
|---|---|---|
| Upgrade in place | Same app, supported OS or version | The hardware and app both support the newer version |
| Rehost | Move it as-is to new hardware or a VM | The hardware is the problem, the software is fine |
| Replatform | Move to a managed or cloud version of the same thing | The vendor offers a supported hosted edition |
| Replace | Buy or build something new and move the data | The app has no future and the data matters |
| Retire | Switch it off and archive the data | Nobody uses it, or the process it served is gone |
Order the work by risk times effort. A legacy PC that browses the web and opens email goes first, even if it's cheap. An isolated equipment controller with no network access can wait for the equipment's own refresh cycle.
You don't have to replace everything at once. The session below walks through modernizing legacy systems in steps, which is how a small IT team or an MSP can make progress without a big-bang project.
Whatever the route, the steps look alike. Pilot on one system or one site. Run old and new in parallel until the business signs off that the numbers match. Keep a rollback plan until that sign-off. Then decommission properly: wipe the disks, remove the accounts and firewall rules, and update the register so the system doesn't haunt the next audit.
What MSPs Should Put in the Contract
For an MSP, a legacy system is also a pricing problem. It takes more time, it carries more risk, and the client often doesn't see either.
So write it down. A legacy exception register reviewed in the quarterly business review. A signed risk acceptance for each system the client chooses to keep. A separate line item or surcharge for supporting it, because it costs more to look after. And a cutoff date, announced early, after which unsupported systems are best-effort only.
That's not punishing the client. It's showing them the real cost of the old box next to the cost of replacing it, and letting them make the call with the numbers in front of them. Plenty choose to replace once they see both lines.
The Short Version
Find every legacy system, write down why it's there, and put it behind its own door. Watch it more closely than anything else on the network. Then migrate in order of risk, one pilot at a time, and decommission properly when you're done.
For the device side of that plan, our IT asset lifecycle guide covers refresh cycles, so the next generation of hardware doesn't turn legacy by accident.

Ilona Kozak
Head of Product
Hi, I'm Ilona, a Head of Product at Flamingo. I work on OpenFrame, defining product direction, prioritising what we build, and ensuring it delivers real value to the MSPs who depend on it. I focus on detail, process improvement, and close collaboration with engineering and design to deliver reliable, well-considered outcomes.
Related Content
Frequently Asked Questions
/blog/legacy-system
Still deciding?
Ask Mingo answers from our docs and customer stories.