“We’d want it, but we’ll never get the budget.”
“It’s too much effort. And not only on your end.”
“I know AI is really good, but our case is different. Our system is very complicated.”
These are the sentences I hear most often when we talk with companies about their legacy systems. Most of them know very well that they run on an old codebase. Nobody needs to explain to them that the technology underneath is ten years old. But there’s either that “it’s working, don’t touch it” vibe, or a very real fear of the effort an upgrade would take.
Until recently, I would have agreed with most of them. Then came a week in October that put all three sentences to the test.
The week that put it to the test
On a Wednesday afternoon in October, my phone wouldn’t stop ringing. Clients, friends, people I hadn’t heard from in a while. All of them were asking some version of the same question: “Should we switch it off?”
A critical security hole had been found in PHP, the programming language behind roughly 70% of websites. Its details went public before a fix was ready, and attacks started hours before the fix was released. Governments in the Netherlands, France, Denmark, Finland, Canada and Australia took some of their websites offline as a precaution. We wrote up the technical side of what happened in a separate article.
Once the fix was out, the answer depended on one thing only. Systems running on a current version got the update the same day, often within hours, and kept running. For older systems, there was no official fix. The only safe option was to switch them off and figure out next steps in the morning. Some older versions eventually received emergency patches, which is very unusual, but by then decisions had already been made and some systems had been offline for hours. You can’t plan around that kind of luck.
Same night, same vulnerability, two very different outcomes.
“It’s working, don’t touch it”
I understand this one better than any other. A system that works is a system nobody worries about. Changing it brings risk, costs money and doesn’t add any new features. So it waits for next year.
The problem is that software ages even when nobody touches it. Every system stands on languages, frameworks and libraries that their makers support for a few years and then leave behind. A system that doesn’t move with them keeps working, but it slowly drifts out of support. You don’t see it until the day you need to act fast.
And I expect those days to come more often. AI is making it much faster to find vulnerabilities and to turn them into working attacks. Earlier this year, a security researcher used an AI model to find a critical vulnerability in WordPress, and the model put together a complete working attack in about ten hours. The same tools are available to people with far worse intentions.
“We’d want it, but we’ll never get the budget”
This one was fair for a long time. Upgrading a ten-year-old system is rarely just an upgrade. In most cases it’s a complete rewrite, because so much has changed underneath it. That used to mean a team of developers for many months, and a budget that never won against anything more urgent.
That math has changed. The part that used to take the most time, the development itself, now takes weeks instead of months for the kind of systems we work on, and the price follows the effort. My colleague Samuel wrote about the numbers in What legacy code migration actually costs in the AI era, so I won’t repeat them here. The short version is that projects which wouldn’t have survived a budget meeting a year ago now make sense.
“It’s too much effort. And not only on your end.”
This is the one where I want to be the most honest, because it’s partly true. AI made development dramatically faster. It did not make everything faster.
Your team will still need to test the new system, decide what should work differently, and check that the migrated data is correct. That part doesn’t disappear, and I’d be suspicious of anyone who promises otherwise. What changed is the proportion. Development used to be the longest part of the project. Now it’s the shorter part, and most of the time goes into exactly the things where your people matter: testing, data, and getting everyone to actually work in the new system. We plan for that from day one, so it doesn’t come as a surprise in the third month.
“Our case is different”
Every client says this, and in a way every one of them is right. Every system is specific. But specific doesn’t mean impossible.
In the last few months we migrated a complete SaaS digital product and a core system for a medical clinic. Right now we’re working on an ERP system for a non-standard B2B e-commerce business and a document management system for a mid-sized company. None of them was simple, and every one of those clients would have told you their case was different.
When I say AI, I don’t mean ChatGPT or someone typing prompts into a coding tool. I mean a hybrid team: senior engineers and an architecture of AI agents working together in a well-defined development process. We can rebuild a system from its existing code, from a written specification, or even from the running application itself when the original code isn’t available. Experienced people review every change. That process is what makes a complicated system manageable.
What to do now
If you’re not sure where your systems stand, start with three questions for whoever runs them, whether that’s your internal team or an external vendor:
- Do you know every system you run for us, and which versions it runs on?
- Which of them are past the end of their support?
- What happens to them on the next day like this?
If the answers are clear and calm, good. If they aren’t, it’s worth addressing sooner rather than later.
And once a system is modernized, the goal is to never fall that far behind again. That’s why we’re making regular upgrades a standard part of our maintenance agreements. On a current stack, keeping up is routine maintenance, not a project.
If you have a system like that and keep postponing it, I’m happy to talk. Tell me what you’re running and what worries you about it, and I’ll give you an honest view of what’s possible and whether it makes sense now. You can book a call with me directly or read more about how we approach legacy modernization.