TL;DR
Legacy systems do not die because a strategy wants them gone. I had to keep ancient systems alive for years, including one running on hardware that could no longer be maintained, with a database that no longer existed outside our shop and a few others. No vendor, no support, but it ran the business. We virtualized it to keep it breathing. Every transformation collides with legacy reality, and the systems that run the business win that fight every time.
Every digital transformation plan assumes you can replace the old systems. Most of them are wrong. The old systems have a way of refusing to die, because they are still running the business, and you cannot turn off the thing the company depends on just because your roadmap says it is obsolete.
I led transformations at a national retailer for two decades, and now I ghostwrite books for technology leaders. The legacy fight was constant, and the legacy systems usually won.
Legacy systems don’t die because your strategy wants them gone. They die when the business stops depending on them, and that takes a lot longer than any roadmap admits.Share on X
The system that should not have still existed
Here is the one I remember most. We had an old system where the hardware could no longer be maintained. The vendor was gone, out of business or moved on. The database it ran on did not exist anymore outside our shop and probably a handful of others like us, relics keeping the same dead technology alive. There was no support to call, no upgrade path, no replacement that fit. By every measure it was dead technology.
Except it ran part of the business, so it could not be dead. That is the trap of legacy: the system is obsolete and irreplaceable at the same time. We had no choice but to keep it going. What we did was virtualize it, move it onto our private cloud, which gave it modern hardware underneath and a speed boost. Virtualizing it meant the ancient software no longer depended on the failing physical hardware, because the hardware was now virtual, running on modern equipment that we could actually maintain. But we were stuck with it. The application itself was unchanged, ancient, and unsupported, just running on better plumbing now. We had not solved the legacy problem. We had bought time, which is often the most you can do.
That is the reality of legacy. You do not always get to replace it. Sometimes the best you can do is keep it alive more efficiently and accept that it is part of your world for the foreseeable future. Virtualizing a dying system onto modern hardware is one of the most useful moves in the whole transformation toolkit, precisely because it decouples ancient software from the failing physical machines it was trapped on, and it is the same one-component-at-a-time thinking I describe in digital transformation is plumbing.
When we could replace legacy, it was rarely a simple swap. One of our bigger moves took us off old hardware and an aging operating system and onto a new platform, and at the same time off an old legacy database and onto Oracle. That database migration was the hard part. The hardware and the operating system you can plan around, but moving the data itself, with everything built on top of it, is where the real risk lives. Years of data, in an old format, with applications and reports and processes all depending on its exact structure, has to be moved into the new database without losing or corrupting any of it, and without breaking the things built on top. You are not just changing the engine. You are rebuilding the foundation the whole business sits on while the business keeps running on it. That is why database migrations are where transformation projects most often go wrong, and why they deserve the most testing, the subject of why digital transformations actually fail.
The homegrown apps and the server under the desk
Legacy covers more than old vendor systems. It is all the homegrown applications a company builds over the years, each one written by someone who has probably moved on, each one doing a job nobody fully remembers the details of anymore. These are often the most dangerous, because there is no vendor, no documentation, and no one left who understands how they work. The person who wrote it is three jobs away, and the only documentation is the code itself, if you can find it. The app just runs, quietly doing something important, until the day it stops and nobody knows how to fix it.
And then there is my favorite kind of legacy, the one that makes every IT person wince. The server under someone’s desk. You think you know every machine running your business, you have your inventory, your data center, your careful records, and then you discover something critical has been quietly running on a box tucked under a desk in some department, set up years ago by someone who needed it and never told anyone. It has no backups, no monitoring, no redundancy, no place in any of your plans, and it has been running payroll or order processing or something equally important the whole time. That is always a problem, and it is always a surprise, and almost every organization has one waiting to be found.
Every IT person has the same nightmare: discovering something critical has been running for years on a forgotten server under someone’s desk.Share on X
Plan for legacy, do not pretend it away
The mistake transformation plans make is treating legacy as a thing you will clear out of the way. You usually will not. Some of it you can replace. Some of it you can modernize underneath while leaving the application alone, like virtualizing that dead-vendor system. And some of it you are simply stuck with, because it works and nobody alive fully understands how to rebuild it.
A realistic transformation accounts for that from the start. It asks which legacy systems can actually go, which can be modernized in place, and which have to be carried forward, and it budgets for carrying them. The clean-slate fantasy, where you sweep away everything old and build fresh, is exactly that, a fantasy. Real transformation happens in a world full of systems you cannot turn off, and the leaders who plan for that succeed where the ones who pretended otherwise stall.
When I ghostwrite a transformation book, the legacy chapter is often the most honest one, because it is where the executive admits what they could not change. That honesty is what separates a useful book from a victory-lap brochure, and it is the part the next leader actually needs to read. You can see how I work with technology leaders on the technology ghostwriting page.
The Guides That Get Your Book Written, Published, and Sold
Four short, practical guides on writing, publishing, and selling your book, plus the occasional note when there's something worth your time. No fluff, no daily inbox clutter. Drop your email and they're yours.
We use MailerLite to manage our list and send these emails. Your address is used only to send you what you signed up for. We will not sell it, share it, or use it for anything else, and you can unsubscribe anytime.
Frequently Asked Questions
Because they are still running the business, and you cannot turn off what the company depends on just because a roadmap calls it obsolete. Legacy is often obsolete and irreplaceable at the same time. Some can be replaced, some modernized underneath, and some you are simply stuck with because it works and nobody fully understands how to rebuild it.
Often the best move is to virtualize it, which keeps it alive more efficiently rather than replacing it. I had a system on unmaintainable hardware with a database that no longer existed elsewhere. We moved it onto a private cloud, giving it modern hardware underneath while the ancient application stayed unchanged. It decouples old software from failing physical machines and buys time.
Because you are moving years of data in an old format, with applications, reports, and processes all depending on its exact structure, into a new database without losing or corrupting any of it. The hardware and OS you can plan around, but the data is the foundation the whole business sits on, and you are rebuilding it while the business runs on it.
They were built over years by people who have usually moved on, with no vendor, no documentation, and no one left who understands them. The only documentation is often the code itself. The app quietly does something important until the day it breaks and nobody knows how to fix it, which makes it both critical and dangerous to touch.
It is discovering that something critical has been quietly running on a forgotten machine set up years ago by someone who never told anyone. It has no backups, no monitoring, no redundancy, and no place in any plan, yet it has been running something important the whole time. Almost every organization has one waiting to be found.
Yes. I led transformations for two decades and ghostwrote three on the subject. The legacy chapter is often the most honest part, where a leader admits what they could not change. That honesty is what makes the book useful. You can see how I work on the technology ghostwriting page.