Our Java estate ran on a version more than a decade old, on a framework version that had stopped receiving security fixes. Everything worked. Nothing could be upgraded without touching everything.

We brought in a specialist partner to help us move forward. Here is what the work actually involved and what I would scope differently.

The argument that got the work funded.

An unsupported runtime stops getting security patches. So do old framework versions. Every month on them adds known flaws that only an upgrade can fix.

Our security team listed fourteen outstanding vulnerabilities that existed only because of version age. That list did more for the business case than any argument about developer productivity.

Our first plan jumped straight to the latest version. It stalled within a month.

Each major version removes or changes things. Jumping several at once means facing every breaking change together, with no way to tell which one failed.

We restarted with one long term support version at a time. Each step was smaller, testable, and shippable on its own.

Our partner recommended this in the first week. We had overruled them initially, which cost a month.

A simple report kept the programme honest.

Each quarter we showed three things. Which runtime and framework versions each service was on. How many known vulnerabilities remained. And which dependencies were still blocking the next step.

That page told the business exactly where we were. Effort reports had told them nothing useful.

Nothing moved until the test coverage could support it.

Our core services had tests covering perhaps a third of what mattered. Upgrading with that coverage means finding breakage in production.

The first phase was all test work. Tests that recorded what the system does today, including odd behaviours people relied on.

That phase took a quarter and produced nothing visible to the business. It is the reason every later step was uneventful.

The runtime upgrade was straightforward. The libraries were not.

We had over two hundred dependencies. Some abandoned. Some pinned to versions that would not run on newer runtimes. A few forked years ago by somebody who had left.

Each needed upgrading, replacing, or removing. That accounted for most of the effort, far more than changes to our own code.

A Java development company experienced in this work knows which libraries cause trouble and what to replace them with. That knowledge saved us weeks.

Our main framework was three major versions behind.

Same approach. One version at a time, with tests passing at each step, deployed before moving on.

Configuration changes were the main effort. Defaults changed between versions, and several behaviours we relied on now had to be switched on explicitly.

The rule that kept the business on side.

Every upgrade step reached production before the next began. No long branch, no big bang.

That meant the business saw security fixes land every quarter rather than waiting a year for a single release. It also meant any problem appeared small and early.

A Java development company that proposes a long parallel branch is proposing the riskiest version of this work.

One part of the work improved something beyond the upgrade itself.

Our reporting queries ran directly against operational databases and slowed them down at month end. As part of the modernisation, reporting moved to a separate store feeding our data analytics and visualization services.

That was not strictly necessary for the upgrade. It was the natural moment, because we were already touching the data access layer.

The partner should leave behind a team that can do this again.

Our engineers paired with the partner on every upgrade step. By the final framework upgrade, our own team led it and the partner reviewed.

That was a deliberate choice, and it cost some speed early on. It is why the next upgrade will not need outside help at all.

The temptation to rewrite everything as microservices was strong.

We resisted, and our partner agreed. Our microservices migration strategy extracted two components where scaling or change rate genuinely differed. Everything else stayed in the upgraded monolith.

A rewrite would have taken two years and delivered nothing until the end. The stepped upgrade delivered security improvements every quarter.

●      Test coverage as its own phase, funded explicitly.

●      One long term support version per step, never more.

●      A dependency audit before any upgrade estimate.

●      Named owners for every forked or abandoned library.

●      Extraction only where there is a specific reason.

Does this affect reporting?

Often. Our data analytics and visualization services moved off the operational database during the work, which improved both.

How long does this take?

Ours took five quarters for three runtime versions and three framework versions. Most of that was tests and dependencies.

Should the partner stay after the upgrade?

For a tapering period. A Java development company that leaves on the day of the last upgrade takes context your team still needs.

Can our own team do it?

Yes, with time. A Java development company brings knowledge of which upgrades cause trouble, which is what saves the time.

Should we rewrite instead?

Rarely. Stepped upgrades deliver value continuously. Rewrites deliver it at the end, if at all.

How do we stay current afterwards?

A standing allocation for upgrades every quarter. Falling behind again is how this became a project.

We are on a supported runtime and framework, with the security list cleared.

More usefully, upgrading is now routine rather than a programme. The test coverage and dependency hygiene we built for the modernisation are what make that possible. A Java development company helped us get there, and the discipline to stay there is ours.