Every digital transformation plan assumes you can replace the old systems. Most of them are wrong. The old systems refuse to die, because they’re still running the business. You can’t turn off the thing a company depends on because your roadmap says it’s 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.
The transformation plans that bother me most treat legacy as a cleanup chore for phase two. Whoever writes that line isn’t the person who gets the call when the old system goes down at night, and the people who do get that call stopped believing it years ago. I’d take a leader who admits on page one that some of the old stuff is staying over one who promises a clean sweep and then misses every date.
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
What happens when legacy hardware can no longer be maintained?
Here’s 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 didn’t 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 couldn’t be dead. That’s 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. That 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 maintain.
But we were stuck with it. The application itself was unchanged, ancient, and unsupported, just running on better plumbing now. We hadn’t solved the legacy problem. We’d bought time. That’s often the most you can do. I don’t like that answer, and I never will. Buying time feels like losing when you’d planned to win. But keeping a business running on something nobody can replace yet takes real skill, and I don’t have much respect for executives who sneer at that work from a conference room.
That’s the reality of legacy. You don’t always get to replace it. Sometimes the best you can do is keep it alive more efficiently and accept that it’s part of your world for the foreseeable future. Virtualizing a dying system onto modern hardware is among the most useful moves in the whole transformation toolkit, because it decouples ancient software from the failing physical machines it was trapped on, and it’s 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, onto a new platform. At the same time it moved us off a 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 is.
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’re not just changing the engine. You’re rebuilding the foundation the whole business sits on while the business keeps running on it.
The people who pay for a botched migration are rarely the ones who scheduled it. They’re the clerk staring at an order that vanished, the employee whose paycheck came out wrong, the customer who got charged twice. Anyone who squeezes testing out of a migration plan to hit a date is gambling with other people’s livelihoods, and I don’t think that deserves to be called leadership.
That’s 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.
What counts as a legacy system?
Legacy covers more than old vendor systems. It’s 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’s 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, doing something important, until the day it stops and nobody knows how to fix it. I blame management for that more than the code. Somebody approved that app, somebody let its author walk out the door without writing anything down, and nobody set aside an hour to understand it while that person was still in the building.
And then there’s 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 running unnoticed on a box tucked under a desk in some department, set up years ago by someone who needed it and never told anyone.
It’s no backups, no monitoring, no redundancy, no place in any of your plans, and it’s been running payroll or order processing or something equally important the whole time. That’s always a problem, and it’s always a surprise, and almost every organization has one waiting to be found.
I don’t blame whoever set up that box. They had a job to do, IT probably couldn’t help them fast enough, and they solved it themselves. The blame belongs to organizations that make the official route so slow that a machine under a desk looks like the sensible choice, and then act shocked when they find it.
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
How should a transformation plan treat legacy systems?
The mistake transformation plans make is treating legacy as a thing you’ll clear out of the way. You usually won’t. 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’re 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 go, which the team can modernize in place, and which it has to carry forward, and it budgets for carrying them. The clean-slate plan is a fantasy, and companies reward it far too often. The leader who promises to sweep everything away collects the applause at kickoff, and the people who inherit the mess take the blame two years later when the old system is still running payroll.
When I ghostwrite a transformation book, the legacy chapter is often the most honest one, because it’s where the executive admits what they couldn’t change. That honesty separates a useful book from a victory-lap brochure, and it’s the part the next leader needs to read. You can see how I work with technology leaders on the technology ghostwriting page.
Frequently Asked Questions
Because they’re still running the business, and you can’t 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’re simply stuck with because it works and nobody fully understands how to rebuild it.
Often the best move is to virtualize it. That keeps it alive more efficiently instead of 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’re 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’re 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. That makes it both critical and dangerous to touch.
It’s discovering that something critical has been quietly running on a forgotten machine set up years ago by someone who never told anyone. It’s no backups, no monitoring, no redundancy, and no place in any plan, yet it’s 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 couldn’t change. That honesty makes the book useful. You can see how I work on the technology ghostwriting page.
