Old Java application modernisation

The language is fine. Java 25 is the current long-term release, Java 21 and 17 are supported, and free OpenJDK builds cover all of them. What's out of support is the stack a 2008 application was built on:

• Java 8 lost Oracle's free public updates for commercial use in January 2019. Oracle sells extended support to December 2030; free builds from other vendors carry on, but every framework has moved past it.
• Struts 1 reached end of life in April 2013, with its last release in December 2008. Struts 2 is a different framework, not an upgrade.
• Spring Framework 5.3, the last version that runs on Java 8, left open-source support in August 2024, and Spring Boot 2.x in November 2023. Spring 6 and Boot 3 need Java 17 or later.
• The namespace. In 2020, Jakarta EE 9 renamed every javax.* package to jakarta.*. Tomcat 10 and later, and every current application server, use the new names, so an old application won't even deploy there without code changes. Tomcat 9 is the last version that speaks the old names.
• Everything else. Hibernate 3, EJB 2, Ant builds, applets, a WebLogic or WebSphere licence the business is still paying for.

Stay and modernise when the business logic is sound and the team, or the market you hire from, knows Java. The path is well trodden: current JDK, Maven or Gradle, Spring Boot 3, the Jakarta namespace, Hibernate 6, a current Tomcat or a container, and the Struts or JSP web layer rebuilt in stages. Most of the application survives.

Leave in stages when the web layer is most of the application and would be rebuilt anyway, when nobody left knows Java, or when the rest of the estate is on .NET or the web stack and one more platform is the cost. Then the new system is built alongside, in whatever the business can support, one process at a time behind a proxy, with the Java application still serving what hasn't moved.

Often the first, then the second. Get it building and supported first, because that removes the risk; then decide the rest with the pressure off. The assessment makes the call from the code.

1. Get it building on a current machine, from source control, with the dependencies resolved. Old Ant builds and jars checked into the tree are where the first surprises are. The assessment does this first.
2. Safety net. A test environment, a staging environment, and tests around the processes that matter, before any version changes.
3. Step the JDK. 8 to 11 to 17 to 21 or 25, fixing what each step removes. Reflection, removed modules and old crypto are the usual ones.
4. Step the frameworks. Spring 4 to 5.3 to 6, Hibernate 3 to 6, and the Jakarta namespace change, which is mechanical but touches every file.
5. Replace the web layer where it's Struts 1 or raw JSP: one screen or one module at a time, alongside the old one, behind a proxy.
6. Move the hosting. Off the licensed application server onto Tomcat or a container, in your own accounts.

Each stage has its own fixed price and each ends with the application running on something supported.

Usually Oracle, SQL Server or MySQL, and it stays where it is. Hibernate upgrades change the generated SQL, so the data layer never meets a change until the change has proven itself somewhere else: tested against a copy in a test environment, then run in staging against the live schema with results reconciled, before anything connects to live.

Yes. The JDK and framework steps each leave the application running and deployable. The web layer moves one screen at a time behind a proxy. A leave-in-stages plan runs the new system alongside and re-points one process at a time. Stop after any stage and keep everything.

The assessment is from £395 + VAT, sized on a free one-hour consultation, with an exact price before you commit. For a Java application it gets the thing building, maps every dependency and framework version, identifies what upgrades in place and what's rebuilt, and prices the stages as fixed numbers. What drives the price and the payment terms each have a page.

An application on Java 8 and Spring 4 gets no fixes for anything in its stack, and Java web frameworks have a history of serious vulnerabilities. Each year the gap to current versions widens and the upgrade gets longer, not shorter. And the application server licence keeps being paid for a platform the application doesn't need.

Get it building, make it safe, step the versions, rebuild the web layer alongside. Marc Allington has built in Java and the enterprise middleware around it, and builds in Java, .NET and the web stack now, so both staying and leaving are familiar ground. Everything we build runs on open, widely used technology, in your own accounts, with full source code and ownership transferring to you on final payment.