Stop Rewriting Working Java Applications: Modernize Without the Cost

Independent analysis of 142 verified Java EE to Spring Boot migration projects found a median cost of $1.2 million per portfolio, an 18-month median timeline, and a 30 percent over-budget-or-timeline rate (Modernization Intel, softwaremodernizationservices.com/migrations/java-ee-to-spring-boot/). Most of that cost lands on the deployment shape rather than the business logic itself. 

For most applications, that rewrite is avoidable. 

The modernization goals driving the rewrite proposal are real. Containers, Kubernetes, fast startup, AI integration, modern Java: each is a legitimate target. Rewriting working application code is not the only way to reach them. A runtime change deploys the existing application unchanged and reaches the same destination in days to weeks per application, versus months, or, in some cases, more than a year. 

What is genuinely at stake in standards versus lock-in?

A vendor-neutral standard is the difference between an application that runs on any certified runtime and an application that runs on one. 

Jakarta EE 11 is a multi-vendor specification. Azul Payara Server 7 holds certification across Full Platform, Web Profile, and Core Profile. IBM WebSphere Liberty also certifies across all three. Eclipse GlassFish 8 is the Jakarta EE 11 Compatible Implementation. Applications written to the standard move between these runtimes as a configuration exercise rather than a rewrite. 

Spring Boot is a framework rather than a standard. A Spring application runs on Spring. Commercial support for Spring now runs through Broadcom Tanzu, following the November 2023 VMware acquisition. The application is not portable without a rewrite. 

When a rewrite to Spring is proposed as the only path to cloud-native or AI, it costs more than the destination requires, since most of what it targets is the deployment shape rather than the business logic. 

Modernization mostly changes the deployment shape, not the code

This is the distinction that decides the project. The modernization goals that cause teams to consider a rewrite – such as containers, Kubernetes, fast start-up, AI integration, modern Java versions – are each reachable through a runtime change on the existing application. 

Azul Payara Server 7 runs in containers on any mainstream Kubernetes distribution like Elastic Kubernetes Service from AWS and Google Kubernetes Service from Google Cloud or on-prem. For workloads that fit the Web Profile or Core Profile, Azul Payara Micro 7 deploys the same archive as a single executable JAR of roughly 100 MB with two-to-five-second startup. The .war that runs on the full server runs on Micro unchanged. 

The application code stays the same; only the deployment shape changes. 

What does Jakarta EE 11 add to a system already in production?

Two specifications in Jakarta EE 11 matter for teams running Jakarta EE or Java EE today, and they change what the existing application can do without a rewrite. 

• Jakarta Data 1.0 introduces a repository-style data access layer. @Repository interfaces handle relational and vector data without boilerplate, which matters for retrieval-augmented generation and any workload that needs embeddings alongside existing records. The vector capability lands inside the CDI container the application already runs in, with no separate database to procure. 

• Jakarta Concurrency 3.1 brings container-managed virtual threads into the Jakarta EE specification. For applications that have run on thread pools for years, this removes the tuning overhead for high-concurrency workloads, including model calls, without breaking the existing threading model. 

These two specs make AI possible, but the larger point is that a team running a Jakarta EE application can add these capabilities to the system already in production without standing up a second runtime or a separate Python team. 

You set the modernization timeline

Azul Payara 4, 5, 6, and 7 are all supported concurrently, with monthly security patches on a published schedule backported across every supported major version. A team that runs Java EE 7 applications lands on Payara 5 on the same javax namespace, avoiding the rewrite entirely. A team on Jakarta EE 10 lands on Payara 6, like-for-like. Payara 7 is the step-up for Jakarta EE 11, on the customer’s timeline, decoupled from the migration risk. 

This is the structural argument against the big-bang rewrite. The estate moves in waves, each application on its own schedule, against a runtime family that holds still while it does. 

Azul is a registered CVE Numbering Authority under CISA and DHS oversight, alongside Oracle, IBM, and Red Hat. The differentiator is the monthly published cadence and the backporting across every supported version, since Oracle, IBM, and Red Hat hold the same CNA status. The patch evidence an auditor asks for is already on the calendar. 

The decision

The framing question is narrower than the rewrite proposal suggests: the deployment model has to change, and the application code does not. A current, fully certified Jakarta EE 11 runtime reaches the cloud-native, AI-ready target through a runtime swap, at transparent per-vCore pricing, with one vendor for both the JDK (Azul Core, a separate Azul product) and the application server. 

That is the modernization decision enterprise Java teams face in 2026. For most applications, the rewrite adds cost without being a requirement of the destination. 

The following table compares a Spring Boot rewrite with a Payara lift and shift – the same cloud-native destination, but one path rewrites the application while the other just deploys it, faster, more efficiently, more portably.

If you are evaluating a rewrite proposal right now, start by separating what has to change from what does not. We can help you map that. Contact your Azul account team or visit azul.com/products/payara to schedule a free assessment.