If your Tomcat website is running on an older Java runtime, upgrading at the right time can improve compatibility, security, and long-term stability. In a managed hosting environment, the question is not only whether a newer runtime is available, but also whether your application, frameworks, and deployed libraries are ready for it. For UK-based hosting customers using Tomcat, JSP, or servlet applications, the safest approach is to review runtime changes before upgrading, test the app in a staging copy, and only then switch the live site.
In a hosting control panel such as Plesk, with a Java hosting service like My App Server, you can often choose from ready-to-use Tomcat and JVM versions or configure a custom runtime manually. That flexibility is useful, but it also means the timing of an upgrade matters. A runtime that is too old may expose security issues or block newer application features. A runtime that is too new may break legacy code, older frameworks, or third-party libraries that your site still depends on.
When an upgrade should be considered
You should plan a runtime upgrade for a Tomcat website when one or more of the following apply:
- Your current Java version is no longer receiving security updates.
- Your application framework requires a newer Java release.
- You are seeing warnings about deprecated APIs, TLS support, or library compatibility.
- You are preparing a new deployment and want a supported baseline.
- Your hosting account includes a newer Tomcat or JVM option that better matches your application stack.
- You need to meet internal security or compliance requirements for supported software.
In practical terms, upgrade decisions are usually driven by one of three needs: security, compatibility, or operational stability. If your site is still functioning, that does not automatically mean the current runtime is the best choice. Many Tomcat applications keep working on older versions until they suddenly fail after a framework update, a certificate change, or a library refresh.
Signs that your current runtime is too old
Security updates have ended
The most common reason to upgrade is that your Java runtime has reached end of support. When that happens, the runtime may still launch your application, but it no longer receives fixes for newly discovered vulnerabilities. For a hosting environment, that is an important risk, especially if the application processes logins, forms, uploads, or payments.
Application dependencies now require a newer Java version
Modern frameworks and libraries often set a minimum Java requirement. For example, a new version of a web framework, XML library, mail library, or build tool may no longer support your current runtime. If you are planning an application update, check the runtime requirement before you deploy.
You need better TLS and protocol support
Older runtimes may have weaker default security options or incomplete support for modern TLS settings. If your application connects to external APIs, payment gateways, authentication services, or mail providers, an upgrade may be needed to avoid connection errors.
You are seeing runtime-related errors in logs
If logs contain class version errors, unsupported major.minor version messages, missing modules, or reflective access warnings, the runtime may not match what the application expects. These errors often appear after a WAR redeploy or a library update.
The site is stable, but future maintenance is becoming harder
Even if your Tomcat website is running well today, staying on a very old runtime can make future updates more difficult. You may find that newer tools, build pipelines, or library versions no longer fit the old environment. Upgrading early, in a controlled way, usually reduces maintenance work later.
When you should not upgrade immediately
A newer Java runtime is not always the right first move. In some cases, you should delay the upgrade until you confirm application compatibility.
- The app was built for an older Java release and has not been tested on newer versions.
- You rely on a legacy library with known compatibility limits.
- You have no staging copy and cannot safely test before changing production.
- The site is mission-critical and the deployment window is limited.
- Your current runtime is still supported and your application is stable.
If the application is business-critical, change the runtime only after testing a copy of the site in a separate environment or at least validating the WAR file in a non-production setup. In managed hosting, the safest rule is simple: if you cannot test it, do not rush the upgrade.
How Tomcat, Java, and the hosting panel work together
Tomcat is the servlet container that runs your Java web application. The Java runtime is the JVM that actually executes the code. In many hosting setups, these two layers are managed separately, which is useful because a Tomcat version and a Java version do not always need to change at the same time.
With a service such as My App Server in Plesk, you may be able to:
- install a ready-made Tomcat and Java version combination with one action;
- switch to another supported runtime from the control panel;
- upload and configure a custom app server or private JVM;
- restart, stop, or monitor the service from the hosting interface;
- deploy WAR-based applications more easily.
This is especially useful for small and medium Java hosting workloads where you need control over the runtime without managing a full dedicated application server stack. It is also helpful when you need to keep one application on an older Java release while preparing another project for a newer one.
How to decide whether to upgrade
1. Check the application’s Java requirement
Start with the software documentation. Look at the minimum and recommended Java version for your application, framework, and major libraries. If you use Spring, Struts, Jakarta EE components, or other Java frameworks, confirm the supported versions before changing anything.
2. Review Tomcat compatibility
Some applications do not only depend on Java; they also expect a specific Tomcat branch or servlet API level. If you plan to upgrade Java, verify that your Tomcat version still matches your application and deployed web.xml or annotation-based configuration.
3. Audit your custom code and libraries
Check for:
- old bytecode targets in the build process;
- third-party JARs compiled for older Java releases;
- libraries that use internal JDK APIs;
- code that depends on removed or deprecated classes;
- hard-coded paths or file access assumptions that changed over time.
4. Test in a staging copy
Before changing the live runtime, clone the application into a test environment and run the same deployment package there. This helps you catch startup failures, session issues, encoding problems, and hidden library conflicts. If your hosting setup includes a spare instance or custom app server configuration, use it for validation first.
5. Check logs after startup
After any runtime change, review the Tomcat logs carefully. Look for startup errors, class loading problems, warnings about unsupported options, and application-specific exceptions. A site that loads the homepage may still have broken background jobs, login flows, or file upload functions.
Practical upgrade scenarios
Scenario 1: You are still on an old but working runtime
If the site is stable and the runtime is still supported, you can often wait until the next planned maintenance window. However, you should already prepare the next version, especially if your current environment is more than one major release behind. Use that time to test the app on the newer runtime and update any incompatible dependencies.
Scenario 2: You are deploying a new version of the application
This is usually the best time to upgrade. A new deployment gives you a natural checkpoint to align the runtime with the current application requirements. It is often easier to update the runtime before rollout than to retrofit it later after users are already on the new version.
Scenario 3: A library update forces a newer Java version
When a dependency upgrade requires a newer JVM, treat it as part of the release plan. Do not update the library alone on production if the application has not been tested on the target runtime. Update the staging environment first and confirm that Tomcat starts cleanly and the app behaves as expected.
Scenario 4: Security policy requires a supported runtime
Many organisations require actively supported software versions. In that case, the upgrade becomes a scheduled maintenance task rather than an optional improvement. If you host your application through Plesk and My App Server, use the control panel to select a supported runtime and then validate the app against it before going live.
Recommended upgrade process in a hosted Tomcat environment
- Back up the application, configuration files, and any uploaded content.
- Note the current Tomcat and Java versions.
- Check the application’s supported Java range.
- Review recent release notes for Tomcat, the JVM, and your key libraries.
- Create a staging copy or test instance.
- Install or select the new runtime in the hosting panel.
- Deploy the same WAR or application package.
- Test login, forms, file upload, background tasks, and external integrations.
- Review logs for warnings and errors.
- Schedule the production switch only after validation.
If your hosting platform lets you choose from several prebuilt Java/Tomcat versions, use the most appropriate supported combination instead of jumping to the newest release without checking compatibility. In a shared hosting or private JVM setup, stability is usually more valuable than being first to adopt a runtime change.
What to check before switching versions in Plesk
Before you change the runtime through a control panel, confirm the following:
- the selected runtime is available for your account and service type;
- the application root and context path are correct;
- the deployed WAR matches the new Java level;
- environment variables and JVM options still make sense;
- file permissions and writable directories are unchanged;
- the application uses the correct Java encoding and locale settings if needed;
- any cron jobs, schedulers, or background tasks also use the new runtime.
These checks matter because a Tomcat website can fail after a runtime change for reasons that are not strictly Java-related. A file permission issue, incompatible startup script, or outdated JVM option may look like a Java problem even when the root cause is configuration.
Common compatibility problems after an upgrade
Class version errors
This usually means some part of the application was compiled for a newer Java version than the runtime you are using, or vice versa. Rebuild the application with the correct target release and confirm the runtime selected in hosting matches that target.
Removed or restricted APIs
Older code may depend on APIs that are no longer available or are now strongly encapsulated. Updating the code or library is usually the right fix.
Startup failures caused by JVM options
Some JVM flags that worked on older versions may be ignored or rejected on newer ones. Review custom startup parameters and remove outdated options before restarting Tomcat.
Encoding, time zone, or locale differences
Some applications behave differently when the runtime defaults change. If your site processes multilingual content, dates, or external data feeds, verify these settings carefully after an upgrade.
Best practice for UK Tomcat hosting customers
For UK hosting customers, the key decision is usually to balance stability with supportability. A runtime upgrade should happen when the application needs it, when security support is ending, or when you are planning a controlled maintenance update. The best results come from keeping a clear record of the current version, testing the next version in advance, and using the hosting control panel to manage the switch in a predictable way.
If you are using My App Server, take advantage of the ability to manage a private JVM and Tomcat instance inside your hosting account. That gives you better separation from other services and makes it easier to adjust the runtime to your application rather than forcing the app to fit a fixed environment.
FAQ
How often should I upgrade the Java runtime for a Tomcat site?
There is no fixed schedule, but you should review it whenever Java or Tomcat reaches end of support, when you upgrade frameworks or libraries, or when you plan a major application release.
Should I always use the newest Java version available?
No. The newest version is not always the safest choice for an existing application. Use the newest version only if your app, Tomcat version, and libraries support it.
Can I run different Java versions for different applications?
Yes, if your hosting service and control panel support separate app server or JVM instances. That is often a practical approach when one application is legacy and another is modern.
What is the safest way to upgrade?
Test first, then switch. Back up the site, verify compatibility, deploy to staging, review logs, and only then update the live runtime.
Do I need to change Tomcat and Java at the same time?
Not always. Sometimes only the Java runtime needs to change. In other cases, the application may also require a Tomcat update. Check both requirements before making a decision.
What if my app works now but uses an unsupported runtime?
You should plan an upgrade soon. An unsupported runtime can continue to run for a while, but it increases security and maintenance risk over time.
Conclusion
You should upgrade the runtime for a Tomcat website when the application, security policy, or future maintenance needs make the current version a poor fit. In a hosting environment with Plesk and My App Server, the process is manageable because you can choose or configure the Java runtime, deploy the application, and test it before going live. The safest approach is to treat runtime changes as planned maintenance: confirm compatibility, test carefully, and only then update the production site.