Preparing for Tomcat 9 EOL: Migration and Support Options

Apache Tomcat has been a foundational component of enterprise Java infrastructure for decades. It powers customer-facing applications, internal business systems, APIs, and countless other workloads that organizations depend on every day. Yet for many teams, Tomcat upgrades are rarely isolated events. They often trigger a cascading series of changes across frameworks, Java versions, build pipelines, and application code.

That reality is why the recently announced end-of-support date for Apache Tomcat 9 deserves attention now, even if March 2027 still feels distant. Organizations running Tomcat 9 today need to begin assessing their options before that deadline arrives. 

Start Planning Your Tomcat Migration

When Will Tomcat 9 Reach End-of-Life?

The Apache Tomcat team has announced that support for Tomcat 9.0.x will end on March 31, 2027. 

Why Tomcat 9 EOL Matters

When a platform reaches end of life (EOL), the immediate concern is usually security. Unsupported software no longer receives community security updates, leaving organizations responsible for managing newly discovered Tomcat CVEs on their own.

But security is only part of the challenge.

For many enterprises, Tomcat is deeply embedded within a broader Java ecosystem. Applications may rely on older versions of Spring Framework, Spring Boot, Java, third-party libraries, or internally developed components. Upgrading Tomcat can quickly become a modernization project that impacts multiple teams and systems.

The latest State of Open Source research highlights how widespread Tomcat remains within enterprise environments. More than one-third of surveyed organizations reported using Tomcat 9, demonstrating that many enterprises still have migration work ahead of them. 

What Are the Biggest Tomcat 9 Migration Challenges?

In this section, we'll review some of the biggest hurdles team encounter when upgrading Tomcat. 

The Namespace Change From Javax to Jakarta

One of the most significant hurdles for organizations planning a Tomcat upgrade is the transition from the legacy javax.* namespace to jakarta.*. 

Tomcat 9 represents the last major Tomcat release built around the traditional javax ecosystem. Moving to newer Tomcat releases frequently requires evaluating application compatibility with Jakarta EE APIs and updating framework dependencies. This transition is a major undertaking because of the scope of code and dependency changes involved. In other words, it's not a simple find-and-replace exercise, and teams will need to allocate significant time and resources to execute it — or partner with a third-party like OpenLogic for Tomcat migration assistance.  

Java Requirements and Jakarta EE Specifications

Tomcat 9 implements the Java EE 8 specification while Tomcat 10.1 and 11 use the new Jakarta EE 10 and 11 specifications, respectively. Tomcat 10.1 requires Java 11+ while Tomcat 11 mandates Java 17+. Using Java 21+ with Tomcat 10.1 and 11 will unlock advanced features such as virtual threads that became available as part of Project Loom; watch the video below to learn more and visit the Tomcat project website for more version specifications. 

Common Breaking Changes

One of the most common issues our customers encounter is performance degradation when moving from Apache Tomcat 9 to either version 10.1 or 11. This is usually due to a 3rd party library that had to be upgraded. For example, if Hibernate was upgraded as part the migration, then the performance can degrade due to internal changes in query parsing, result processing, or database connection handling introduced in newer major versions. 

This is usually noticed after the application goes live — and why it is important to have a repeatable set of performance test scripts to get a baseline and then determine how performance has been affected after an upgrade. Tomcat performance degradation after an upgrade is rarely due to upgrading; it is usually due to an unsuspected 3rd party library being used in the application. Newer versions of these frameworks like Hibernate often feature heavier annotation processing, more robust security defaults, and different caching mechanisms that can result in higher CPU and memory consumption out of the box compared to their older counterparts.

The defaults in the configuration files such as server.xml, context.xml and web.xml in Tomcat 10.1 and 11 have changed. Copying deprecated Tomcat 9 configuration files into a 10.1 or 11 environment will work, but you may miss out on improvements to thread pooling, connection behavior, and memory management. It may be necessary to port over necessary specific modifications to the new environment. 

If your application was tuned for the older CMS garbage collector in Java 8, then it may perform differently in Java 11+. This is because the default garbage collection in Java 9+ was changed to the G1GC algorithm. Profile the applications memory usage and adjust the JVM arguments specifically for the new Java runtime.

Be aware that starting in Java 11 that JAXB (javax.xml.bind) was removed which breaks XML marshalling/unmarshalling. Also removed was the JAX-WS module (javax.xml.ws) which deals with SOAP web services. CORBA (javax.corba), Commons Annotations (javax.annotations), and Java Activation Framework (javax.activation) were also removed, which can cause issues. 

Assessing Your Current Environment

Before selecting a migration path, organizations should inventory their current Java stack. Questions worth answering include:

• Which version of Tomcat are you currently running?
• Which Java runtime versions support your applications?
• Are you using Spring Boot 2.x, Spring Framework 5.x, or other components approaching or already beyond community support?
• What third-party libraries depend on javax APIs?
• Which applications are most critical to business operations?

A comprehensive inventory helps reveal hidden dependencies that can expand project scope later. 

Possible Blockers 

Here a few common situations where we have discovered blockers that have delayed application releases: 

• Applications that have a continued reliance on obsolete frameworks like Struts 1, early Spring 3.x/4.x, or early Hibernate versions. These frameworks have CVEs which may not be fixed and are incompatible with modern servlet containers and newer Java runtimes.
• Customers that have tight database coupling where heavy business logic embedded directly in SQL stored procedures or highly complex object-relational mapping (ORM) structures that break when database drivers are updated. 
• Homegrown authentication and authorization mechanisms built before modern standards such as OAuth2 or OID existed. These are highly error-prone to refactor.
• Heavy reliance on open source libraries that have not been maintained in a decade (very old versions of Apache Commons, Log4j 1.x, or Guava). These create massive security compliance gaps (CVEs).

Three Paths Organizations Can Take

Some organizations may be able to migrate immediately. Others will need a phased strategy that combines support, risk reduction, and modernization planning.

Option 1: Upgrade Directly to a Newer Tomcat Release

For organizations with relatively modern applications, upgrading directly to a supported Tomcat release may be the most straightforward approach. The Apache Tomcat project provides migration tooling to help facilitate transitions. The benefit is clear: continued community support, access to new features, and a more future-ready platform.

The drawback is that the migration effort may be larger than expected if application dependencies require substantial changes. That's when working with a vendor with deep Tomcat expertise and experience managing complex Tomcat migrations can make a difference and minimize disruption. 

Option 2: Modernize the Broader Java Stack

In some environments, Tomcat 9 EOL becomes an opportunity to modernize holistically rather than performing a narrow application server upgrade. While more resource intensive, this approach can reduce technical debt and improve long-term maintainability. 

Along with Tomcat, organizations may choose to upgrade:

• Java runtimes
• Spring Framework versions
• Spring Boot versions
• CI/CD processes
• Security and observability tooling

Here are a few combinations of Java, Spring, and Apache Tomcat versions which are currently industry standard:

• Java 17 + Spring 6.0 + Spring Boot 3.x + Tomcat 10.1: This combination is where most of the industry is landing currently. Spring Boot 3.0+ requires Java 17+ and Jakarta EE. Tomcat 10.1 is the embedded default in Spring Boot 3.x and is what implements the Jakarta Servlet 6.0 specification that Spring Boot 3 requires. 
• Java 21 + Spring 6.1/Spring Boot 3.3 or Spring 6.2/Spring Boot 3.5.x + Tomcat 10.1/11: Java 21 unlocks virtual threads which Spring Boot 3.2+ can turn on. This has the potential to be a big performance boost for I/O-bound Tomcat thread pool constrained applications.

Option 3: Extend Support While You Plan

Not every organization can complete a complex migration before community support ends. Business-critical applications, regulatory requirements, staffing constraints, and competing priorities often make aggressive upgrade timelines unrealistic.

Tomcat long-term support can provide an interim strategy by delivering ongoing security maintenance while organizations plan and execute migrations on a schedule that aligns with business needs.

At OpenLogic, we believe long-term support should not be viewed as a permanent destination. Instead, it provides additional runway to modernize responsibly while maintaining security and compliance requirements. 

When Should You Start Preparing for Tomcat 9 EOL?

A common mistake is treating EOL dates as future problems.

The closer organizations move toward March 2027 without a plan, the fewer options they may have. Engineering resources become constrained, testing cycles get compressed, and unexpected compatibility issues can force rushed decisions.

Starting now allows teams to:

• Prioritize critical applications
• Identify migration dependencies
• Build realistic timelines
• Evaluate long-term support alternatives
• Reduce operational risk

The organizations that navigate EOL events most successfully are usually those that begin preparation well before support officially ends.

Final Thoughts

Tomcat 9's end of support may still be months away, but enterprise migrations don't happen overnight.

For organizations running production workloads on Tomcat 9, now is the time to assess dependencies, understand modernization requirements, and determine which migration strategy best aligns with business goals.

Whether that means upgrading directly, modernizing the broader Java stack, or leveraging long-term support during the transition, the most important step is having a plan before community support disappears.

Additional Resources

• Guide - Apache Tomcat Overview
• Webinar - Taming Tomcat 11: Tips and Tricks for Java Teams
• Blog - Troubleshooting Tomcat Errors (and How to Fix Them)
• Blog - Guide to Application Logging in Tomcat
• Blog - Apache Tomcat Security Best Practices