"We will only migrate when Java 8 is actually no longer supported." I hear this kind of statement all the time when talking to IT managers. Their platform is stable, nothing seems to be broken, so why invest time and budget in an upgrade?
Until the moment they discover their vendor no longer builds new features for their version. Or that security patches are no longer available.
Suddenly, upgrading becomes urgent. Contracts expire, security requirements tighten, vendors end their support. What could have been solved gradually over the past few years now has to be done in a matter of months.
This scenario is all too familiar in the municipal sector: organizations that have postponed upgrades for years, even though they knew it was necessary. And then, overnight, the rules change.
Organizations that kept running old Java versions got a surprise bill in January 2023. Oracle drastically changed its licensing model from paying per user to paying per employee.
If you had upgraded earlier or switched to open-source alternatives, you would have avoided this spike in costs. But organizations stuck on outdated versions, and therefore reliant on commercial support, suddenly found themselves tied to a much more expensive contract.
It’s a perfect example of why deferred maintenance is so risky: what starts as a cost-saving measure (“let’s not upgrade yet”) turns into a financial trap.
And that’s just the tip of the iceberg.
The Oracle situation isn’t unique. I see the same pattern across countless technologies. Organizations postpone upgrades, become dependent on outdated versions, and run into identical problems.
PostgreSQL 12 reached end of life in November 2024, yet 11% of all PostgreSQL databases are still running on an unsupported version. Those organizations no longer receive security patches and can’t rely on community support for issues.
Python 3.8 lost all support in October 2024. This affects many municipal websites, data analytics tools, and automation scripts. Applications that remain on these versions become increasingly vulnerable to attacks, and external auditors will flag them as security risks.
At the same time, software cycles are getting shorter. Where you once had years to prepare for a migration, it’s now a matter of months. And the consequences of waiting keep escalating: security risks, compatibility issues, and the loss of vendor support.
Hardware eventually breaks, that’s obvious. But many leadership teams underestimate that the same is true for software. When a printer fails, you immediately see the problem. Software keeps running… until it doesn’t.
“It still works. Why would we spend time and money on something that isn’t broken?”
It’s an understandable thought, right up until systems go offline due to a security flaw. Or until the vendor pulls the plug.
Sixty percent of all data breaches originate from systems that weren’t patched. And the average cost of a breach? Easily several million euros. For municipalities, the impact isn’t just financial, it’s reputational. Trust from citizens depends on secure digital services.
Why? Because everything happens under pressure.
You need expensive consultants who can respond immediately. Systems may need to go offline for emergency migrations. Mistakes happen, mistakes that cost even more to fix later.
A migration you could have planned calmly over twelve months becomes a crisis operation squeezed into three.
And when you’re under pressure, switching vendors isn’t an option anymore. You’re forced to adopt their newest version. Vendors know this. When you’re in a weak position, they can increase prices because moving away from them has become too complex and time-consuming.
You’re no longer in control of their roadmap, they are.
The problem is that many organizations don’t see software lifecycle management as a strategic priority.
The organizations that do take it seriously allocate time for continuous updates—just like your phone installs updates regularly. They schedule migrations well in advance rather than waiting for hard deadlines.
They make conscious choices about the technologies they adopt. Open-source alternatives can often deliver the same functionality as costly commercial software, without vendor lock-in.
And most importantly: they don’t treat maintenance as a cost, but as an investment in stability and security.
Collaboration can make all of this easier. In the municipal sector, I’ve seen excellent examples of joint knowledge sharing and joint planning. Why should every municipality figure out the same migration separately? Share knowledge, share costs, share risks.
Software lifecycle management is becoming more important by the day. Support windows are shorter. Security requirements are stricter. Vendors are getting more creative with their pricing models.
The question isn’t whether you need to update your software.
The question is when, and whether you’ll do it proactively or reactively.
Remember the “three times as expensive” part?
At WeAreFrank!, we have years of experience with complex migrations, from Java upgrades to complete platform transitions. We’ve successfully migrated the Frank!Framework itself to the latest Java standards.
We help organizations with the technical side of migrations, but also with strategic planning. Because the best migration is the one you start before you’re in trouble.
Curious how we can strengthen your software lifecycle management? Book a free strategy session