Somewhere in your building right now, there's a system running that the vendor stopped supporting eighteen months ago. Maybe longer. You probably know about it. Your IT team definitely knows about it. And everyone has quietly agreed that because it still works - still loads, still processes, still does what it did yesterday - it can wait.
I want to challenge that, because "it still works" is doing an extraordinary amount of heavy lifting in that sentence.
When a platform vendor declares a product end-of-life, the emails they send are easy to file away. They arrive with long timelines and measured language. There's usually a migration path suggested, a successor product named, some dates that feel comfortably far away. And because the system doesn't actually stop functioning on that date - the lights don't go off, the data doesn't vanish - it's remarkably easy to treat the whole thing as advisory rather than urgent.
We've been meaning to sort it out, but it's not a priority right now. The system works, the team knows it, and replacing it is a massive project we can't justify this quarter.
I hear this constantly. And I get it - genuinely. Migration is disruptive, expensive, and politically difficult. But what I've learned from watching firms defer this decision over and over is that the choice you're actually making isn't "should we modernise?" It's "do we want to make this decision on our own terms, or under someone else's?"
Because the decision always gets made eventually. The only variable is how much it costs and how much control you have when it does.
Let me translate this for anyone who isn't in IT, because the technical language around end-of-life obscures what's really happening.
When a vendor declares a product end-of-life, three things stop. Security patches. Technical support. Compatibility guarantees.
On the patches: if someone discovers a vulnerability in the software after that date - and vulnerabilities are discovered in mature software all the time - nobody fixes it. The hole stays open. Permanently. On support: if something breaks, you're on your own. Your support contract, if you still have one, covers a product the vendor no longer stands behind. And on compatibility: the other systems your platform connects to - your CRM, your email platform, your payment processor, your authentication tools - will keep updating themselves. When those updates break the connection to your end-of-life system, the vendor's position is, essentially, not our problem.
The platform doesn't stop working on the end-of-life date. That's the bit everyone clings to. But it stops being maintained. And the gap between where your system sits and where the rest of the world has moved grows wider every single week.
Think of it like a house where the builder has said, "Right, we're done maintaining this property." The roof doesn't collapse the next day. But when it starts leaking six months later, you're not calling the builder. You're calling whoever you can find, at whatever rate they charge, hoping they can patch something designed by someone who's long since moved on.
I want to be specific here, because the generic "it's risky" framing doesn't land with most managing partners. Too abstract. So here are five risks, each with a concrete scenario attached.
Security exposure that gets worse, not better
This is the big one. After the end-of-life date, every vulnerability discovered in your platform is a vulnerability that will never be patched. The system becomes permanently - and increasingly - exploitable.
Here's what that looks like in practice. A CVE - a publicly disclosed security vulnerability, catalogued and searchable by anyone, including people with bad intentions - gets published for your platform. Before end-of-life, the vendor would have issued a patch within days or weeks. After end-of-life, nothing happens. The vulnerability sits there, documented, known, and open. Your IT team might apply a workaround - a firewall rule, an access restriction - but those workarounds are plasters on a wound that can't heal.
According to McKinsey's 2025 research, enterprises are burning 40% of their IT budgets maintaining legacy systems. A meaningful chunk of that spend is exactly this kind of workaround - patching around problems that should have been fixed at source.
And the kicker? If you do get breached, and the forensic investigation reveals you were running software the vendor had publicly declared unsupported, that's a very uncomfortable conversation with your insurer. And your regulator. And your clients.
Compliance risk hiding in plain sight
If you operate in a regulated industry - financial services, legal, healthcare, anything touching personal data under GDPR or its equivalents - your compliance obligations almost certainly require you to maintain and patch the software that handles sensitive data.
I sat with the COO of a wealth management firm in the Midlands last year - about 200 staff, solid reputation, the kind of business that's been around long enough to have accumulated a lot of quiet technical debt. They'd just been through a routine audit. The auditors flagged their end-of-life CMS as a finding - not because anything had gone wrong, but because running unsupported software that processed client data was, in their view, a control deficiency. The remediation cost wasn't the problem. The problem was that it triggered a broader review of their technology governance, which consumed three months of senior management time and resulted in two other systems being flagged.
The system worked. It hadn't been breached. But its mere existence in an unsupported state created a compliance event. That's the thing about regulatory risk - you don't need something to go wrong. You just need an auditor to notice that something could go wrong and that you knew about it.
Integration brittleness - the one nobody sees coming
This is the risk I find most firms underestimate. Your end-of-life platform doesn't exist in isolation. It connects to other systems - your CRM, your authentication provider, your analytics tools, your payment gateway, your marketing automation platform. Those systems are actively maintained. They receive regular updates. And those updates are tested against current, supported platforms.
When Salesforce pushes an API update, they test it against current integrations. They do not test it against your end-of-life CMS from 2017. When your SSO provider upgrades their authentication protocol, they verify compatibility with supported platforms. Not yours.
I've written separately about how digital platform fragility affects organisations - there's a companion piece on the cost of standing still that covers the financial dimension in more depth. But the integration risk deserves its own spotlight because it's the one that tends to break suddenly and without warning. One morning your CRM sync just... stops. Or your login flow breaks for 30% of users. And when you call the vendor of the system that pushed the update, they tell you - politely but firmly - that they don't support integration with your platform anymore.
We worked with a professional services firm - a mid-sized consultancy, maybe 150 people, based in the South East - where exactly this happened. Their marketing automation platform pushed a routine update that changed how form submissions were processed. Their end-of-life CMS couldn't handle the new format. Lead capture broke silently - forms appeared to submit successfully, but the data wasn't reaching the CRM. They lost three weeks of inbound enquiries before anyone noticed. Three weeks. That's not a technology problem. That's a revenue problem.
What made it worse was that nobody had been watching for it. The integration had worked fine for two years. There was no alert, no error message visible to anyone outside the dev team. Just a quiet, expensive silence.
Rising maintenance costs that never show up in one line item
Here's something I find genuinely fascinating about end-of-life platforms: the cost of maintaining them almost never appears as a single, alarming number on a budget spreadsheet. Instead, it's distributed across dozens of small costs that individually seem reasonable.
A freelance developer who's one of the few people left who knows the platform, charging a premium because they know it too. Workaround hours from your internal team who've learned to route around the platform's limitations. The opportunity cost of features you can't build because the platform can't support them. The extra testing cycles every time you update anything connected to it.
I spoke to a CTO at a law firm last month - good firm, top 50 in the UK - who told me they're paying their legacy platform developer 40% above market rate simply because there's nobody else available who understands the system. And that developer knows it. He wasn't smug about it, to be fair. He seemed almost embarrassed. But he's also not going to volunteer a pay cut.
I've seen firms where the true cost of maintaining an end-of-life system - when you actually add it all up - exceeds the annual cost of a modern replacement platform. But because those costs are spread across different budgets, different teams, and different line items, nobody ever sees the total. It's like a subscription you forgot to cancel, except it's fifteen subscriptions and they're all getting more expensive.
The shrinking talent pool
This one creeps up on you. The engineers and developers who know your end-of-life platform are, by definition, specialists in something the market has moved away from. They're getting older. They're retiring. They're moving to firms that work with current technology. And the graduates coming out of university have never touched your platform and have no interest in learning it.
Every year that passes, the pool of people who can maintain your system gets smaller and the cost of accessing that pool gets higher. This isn't a problem you solve with recruitment. It's a structural constraint that only gets tighter.
Here's where this gets properly uncomfortable. Each of those five risks compounds independently. But they also compound together.
A security vulnerability discovered in year one might be manageable - you apply a workaround, restrict access, move on. By year three, you've accumulated multiple unpatched vulnerabilities, your workarounds are stacked on top of each other, your integration points are increasingly fragile, and the developer who built the original workarounds has left. The system that was "fine" in year one is now a lattice of temporary fixes maintained by people who inherited it rather than built it.
The "we'll deal with it eventually" position doesn't stay neutral. It gets worse. The compounding effect means the cost and complexity of migration increases the longer you wait - and not linearly. An emergency migration forced by a breach or a critical integration failure typically costs two to three times what a planned migration would have cost. And it happens on a compressed timeline, under pressure, with fewer options.
I keep coming back to that McKinsey stat: 70% of large-scale transformations fail. Bain's 2024 research puts it even more starkly - 88% fail to achieve their original ambitions. But here's the thing nobody mentions when quoting those numbers: a disproportionate share of those failures are reactive transformations. Migrations forced by circumstances rather than planned with intention. When you're migrating because your platform has already broken, you don't have the luxury of doing it properly.
Even if your end-of-life platform isn't causing you active pain today, it's almost certainly blocking you from doing anything meaningful with AI. And that's starting to matter in ways it didn't eighteen months ago.
Gartner's 2025 research found that 68% of organisations report legacy systems obstruct AI adoption. When you look at why, it makes complete sense. Modern AI tools - content personalisation, automated document processing, intelligent search, the agentic AI applications that are rapidly moving from experimental to practical - need structured data, clean APIs, and modern content architectures. An end-of-life CMS built in 2015 typically offers none of those things.
So while your competitors are exploring how AI can accelerate their client delivery and improve their operational efficiency, your end-of-life platform is quietly ensuring you can't even start that conversation. It's not just holding you back from where you need to be today. It's holding you back from where you'll need to be in eighteen months.
I want to be honest here, because I think the technology industry does a disservice to senior leaders by making migration sound simpler than it is. Migration is genuinely disruptive. It costs real money. It takes real time. And it carries real risk. Pretending otherwise would be patronising.
But it carries less risk than the alternative.
The practical approach isn't to panic and replace everything at once. That's how you end up as one of the 88%. The practical approach is methodical.
Start by mapping what you've actually got. Which systems are end-of-life or approaching it? What do they connect to? What data do they hold? What business processes depend on them? Most firms I work with don't have a complete picture of this until they actually sit down and document it. We've found systems on client estates that nobody in the current team even knew existed. Genuinely. Not a metaphor.
Then assess by risk, not by age. A legacy internal wiki that holds no sensitive data and connects to nothing is a very different proposition from an end-of-life CMS that processes client enquiries, connects to your CRM, and holds personally identifiable information. Prioritise by actual risk exposure - security criticality, compliance implications, integration dependencies - not by which system annoys people the most.
Build the business case before the forcing event. This is the move that separates the firms that migrate well from the firms that migrate badly. A planned migration has a known cost, a predictable timeline, and a defined outcome. A reactive migration - forced by a breach, an audit finding, or a critical failure - has an unknown cost, a compressed timeline, and typically produces poor decisions made under pressure. We've published a detailed guide on this - The Replatform Reckoning - that walks through the three-year cost comparison and the business case framework. If you're at the stage where you know this needs addressing but need help structuring the conversation with your board or finance director, that's probably your next read.
And phase it. Address the highest-risk systems first. A phased approach that tackles the most exposed systems first and works outward is almost always more successful than a big-bang replacement. Cheaper, lower risk, and it gives you the chance to learn from each phase before starting the next one.
The managing partner or operations leader who's been told the end-of-life system "still works" is operating on a definition of "working" that excludes the costs already being absorbed, the risks already being carried, and the opportunities already being missed.
I'm not saying you need to drop everything and migrate tomorrow. But you do need to understand what you're actually choosing when you choose to wait. You're choosing to let the risk compound. You're choosing to let the maintenance costs climb. You're choosing to fall further behind on AI readiness. And you're choosing to let the eventual migration happen on terms dictated by a breach, an audit, or a system failure rather than terms you've set yourself.
Honestly, I've lost count of the conversations I've had with senior leaders who said some version of "we knew we should have done this two years ago." Every single one of them. And the frustrating thing is that the migration itself usually wasn't as bad as they'd feared - it was the circumstances they'd let it happen in that made it painful. The rushed timeline. The board breathing down their necks. The client they had to call to explain why their data might have been exposed.
Do it on your terms. The platform will get replaced either way. The only question is who's deciding when.