Before you move a Tomcat application, it is worth auditing the full runtime stack, not just the WAR file. In practice, most migration issues come from missing Java versions, hidden filesystem assumptions, port conflicts, external dependencies, or environment settings that were quietly available on the old host. A careful review helps you move the application with fewer surprises, whether you are switching shared hosting plans, using a control panel like Plesk, or deploying to a managed Java hosting environment with a private JVM.
If your target platform uses Apache Tomcat or a similar app server model, the safest approach is to compare the source and destination environments side by side before the first deploy. This is especially important for UK-based businesses planning a hosting change, because you usually want the migration to be predictable, compliant with your internal release process, and easy to test before go-live.
What should you audit before migrating a Tomcat application?
The most important items to audit are the application’s Java requirements, Tomcat version compatibility, external integrations, configuration files, data storage, and operational dependencies. You should also check how the app is started, where logs are written, what resources it needs, and which parts are controlled by the hosting platform or control panel.
A migration audit should answer one simple question: what does the application need in order to run exactly as it does today? Once that is clear, you can map those needs to the new hosting environment and decide what must be changed, recreated, or tested.
1. Check the Java version and JVM settings
Tomcat applications are often tied to a specific Java runtime. Even if the code compiles on multiple versions, the deployed app may rely on a certain JVM behaviour, TLS implementation, garbage collection setting, or library compatibility level.
Audit these Java items
- Current Java version in production
- Required Java version for the application and all libraries
- Whether the application needs a full JDK or only a JRE-equivalent runtime
- JVM memory flags such as
-Xms,-Xmx, and metaspace settings - Timezone and locale settings
- Any custom system properties passed at startup
If you are moving to a hosting platform with My App Server, check which Java versions are available for one-click installation and whether a custom version can be uploaded or configured manually. That matters if your app depends on an older release or on a newer LTS version.
Why this matters
A Java version mismatch can cause startup errors, SSL problems, class loading failures, or subtle application bugs. In some cases, the application will start but fail later under real traffic. That is why the Java runtime must be validated before the move, not after.
2. Confirm Tomcat version and connector compatibility
Not every Tomcat application behaves the same way across versions. Differences in servlet support, JSP handling, default connector behaviour, or security-related changes can affect the deployment.
Review the Tomcat deployment details
- Tomcat major and minor version currently in use
- Whether the application depends on a specific Servlet or JSP specification level
- Connector configuration, including HTTP, HTTPS, AJP, and port assignments
- Compression, request size limits, and timeout settings
- Any custom
server.xml,context.xml, orweb.xmlsettings
If the hosting platform offers a managed Apache Tomcat instance or a private JVM per account, verify whether the Tomcat service can be controlled from the panel and whether the required connector settings are exposed. In a Plesk-based setup, for example, service control and deployment paths may be different from what you used on the previous server.
3. Inventory application dependencies
Many migration problems are caused by dependencies that are not part of the WAR file itself. These can include shared libraries, native binaries, scheduled jobs, third-party services, or files stored outside the application directory.
Look for these dependency types
- JAR files stored in
WEB-INF/liband any external library paths - Native libraries loaded with
java.library.path - Database drivers and connection pool libraries
- Email, SMS, payment, or API integrations
- File upload storage directories
- Scheduled tasks or background workers
Make a list of every external system the application talks to. That should include databases, SMTP servers, SFTP destinations, identity providers, and internal APIs. During a migration, these endpoints may need new firewall rules, updated credentials, or adjusted hostnames.
4. Audit configuration files and environment variables
Tomcat applications often use a mix of hard-coded values, environment variables, and external configuration files. Before migrating, identify where each configuration value lives and how it is loaded.
Common files and settings to review
application.propertiesorapplication.yml- JNDI resources
context.xmlserver.xml- Custom property files outside the WAR
- Startup scripts and shell variables
- System properties set in the service definition
Check whether any secrets are embedded in configuration files. If so, plan to replace them with safer storage or panel-managed settings where possible. In a managed hosting environment, it is also useful to confirm which parts of the configuration are editable from the control panel and which require manual file edits.
5. Map filesystem paths and permissions
Tomcat applications often assume specific paths for uploads, exports, temporary files, caches, or logs. These paths may work on the old server because of local permissions or a particular directory layout. On a new host, those assumptions may break.
Audit the file paths used by the app
- Document root and deployment directory
- Upload and attachment folders
- Temporary directories
- Report or export locations
- Log file destinations
- Any hard-coded absolute paths
Also review ownership and permissions. The Tomcat service account must be able to read the application files and write only to the folders that require it. If you are moving to a private JVM setup in Plesk or a similar panel, verify that the service user has the right access to the app directory and to any writable data paths.
6. Review databases and persistence layers
Most Tomcat applications depend on a database, and migration can affect connectivity more than the application code itself. Even when the schema stays the same, small differences in driver versions, connection strings, or character encoding can cause issues.
Database audit checklist
- Database engine and version
- Schema name, table collation, and character set
- Connection pool settings
- JDBC driver version
- Read/write permissions for the application user
- Backup and restore method
If the target platform offers database services separately from the application server, confirm whether you need to create the database before deploying the app. Also check for any stored procedures, triggers, or scheduled events that must be migrated along with the schema.
7. Check logs, monitoring, and error handling
A migration is much easier when the application logs clearly enough to diagnose problems. Before moving, make sure you know where the current logs are stored and which log levels are enabled.
Review logging details
- Tomcat access logs
- Application logs
- Framework logs, such as Spring or Hibernate logs
- Log rotation settings
- Retention period
- Alerting or monitoring integrations
After migration, you want to compare startup logs, request logs, and application error logs quickly. If your hosting control panel provides service control and log access, confirm that you know where to find the right log files before you begin testing.
8. Audit web server integration and frontend dependencies
Many Tomcat applications are not exposed directly. They may sit behind Apache, use a reverse proxy, or depend on specific rewrite rules, headers, or HTTPS termination behaviour. Those settings can be easy to overlook when planning a migration.
Review the web layer
- Whether Apache or another web server sits in front of Tomcat
- Proxy headers such as
X-Forwarded-ForandX-Forwarded-Proto - Rewrite rules and redirects
- SSL certificate handling
- Session affinity requirements
- Static file handling outside Tomcat
If your new environment uses Apache and Tomcat together, test the request flow from browser to web server to app server. Misconfigured proxy headers can break URL generation, secure cookies, redirect logic, and authentication flows.
9. Identify scheduled jobs and background processes
Tomcat applications often depend on background tasks that are not obvious during a quick code review. These may include email dispatchers, import jobs, cleanup tasks, or cron-triggered scripts.
Ask these questions
- Does the application start any background threads at boot?
- Are there cron jobs or external schedulers?
- Is there a queue consumer or worker process outside Tomcat?
- Do reports or sync tasks run from shell scripts?
- Are there file watchers or batch imports?
During migration, make sure every scheduled component has an equivalent on the new platform. If the hosting environment does not support the same style of system-level scheduling, you may need to adapt the task design or use a supported control panel scheduler.
10. Verify security, authentication, and compliance requirements
A hosting migration can affect security in ways that are not immediately visible. A Tomcat app may continue to function while authentication, certificate validation, or session security silently changes.
Security items to review
- HTTPS certificates and renewal process
- Authentication providers, such as LDAP, SSO, or OAuth
- Session timeout and secure cookie settings
- IP allowlists and access restrictions
- Secrets handling and password rotation
- Data retention and backup policies
For UK businesses, it is also sensible to review internal compliance requirements before migration, especially if the application handles customer data, financial records, or regulated content. The goal is not only to make the app run, but to make sure the new hosting setup still fits your governance rules.
11. Compare resource usage with the new hosting limits
Even a well-configured Tomcat app can fail if the new environment has tighter resource limits than the old one. This is particularly important in shared hosting or private JVM setups where CPU, memory, disk, and process limits may be defined at the account level.
Measure the current resource profile
- Peak memory use
- Typical CPU load
- Disk usage growth
- Number of concurrent users
- Upload size and request size requirements
- Log file growth rate
Compare those figures with the limits of the target platform. If the app regularly uses more memory than the new JVM allocation allows, it may start but become unstable under load. Understanding the limits in advance helps you tune the application or choose a suitable hosting plan.
12. Prepare a rollback and testing plan
No Tomcat migration should happen without a rollback plan. If the new deployment reveals missing dependencies, authentication issues, or performance regressions, you should be able to return traffic to the old environment quickly.
Your testing plan should include
- Deployment to a staging or temporary domain
- Smoke tests for login, forms, uploads, and search
- Database read/write tests
- Email or notification tests
- Session persistence tests
- Error log review after startup
Keep DNS changes, certificate switches, and application cutover separate where possible. A staged approach gives you more control and reduces the risk of a service interruption.
Practical migration checklist
Use this checklist before you move the application:
- Confirm Java version compatibility
- Confirm Tomcat version and connector settings
- Export all application configuration
- List external services and integrations
- Review filesystem paths and permissions
- Back up the database and verify restore steps
- Check logging locations and log access
- Review proxy, Apache, and HTTPS behaviour
- Identify scheduled jobs and background tasks
- Verify resource limits and memory allocation
- Prepare staging tests and rollback steps
How My App Server style hosting can help
For small and medium Java workloads, a hosting platform with a dedicated Tomcat or private JVM model can simplify migration planning. With a Plesk extension such as My App Server, you can typically manage the Java runtime, deploy WAR-based applications, control the service, and choose between ready-made Tomcat versions or custom setups.
That is useful when your audit shows that the application needs a specific Java version, separate JVM settings, or a clean deployment path for JSP, servlet, or WAR-based apps. It also gives you a more direct view of the service lifecycle, which makes testing and troubleshooting easier after the move.
At the same time, it is still important to stay realistic about the platform model. This kind of hosting is well suited to practical Java hosting and Tomcat hosting for smaller deployments, but it is not the same as a full enterprise application server stack with complex clustering or heavyweight high-availability architecture.
FAQ
Should I audit only the WAR file before moving a Tomcat app?
No. The WAR file is only one part of the application. You should also audit Java version, Tomcat settings, external configuration, filesystem paths, database dependencies, scheduled jobs, and any proxy or Apache integration.
What is the most common reason a Tomcat migration fails?
One of the most common reasons is an environment mismatch, especially Java version differences or missing configuration values. Another frequent issue is a hidden dependency on files, permissions, or services that were available on the old host.
Do I need to test Tomcat applications after a hosting move?
Yes. Always test login, form submission, database writes, uploads, email sending, and any background tasks. A Tomcat app may start correctly but still fail in specific workflows if something is misconfigured.
Should I change the application before or after the migration?
Usually before, if the change is needed for compatibility. For example, if the app depends on an outdated Java setting or hard-coded path, fix and verify that in staging before switching production traffic.
Can I run a private Tomcat instance inside a shared hosting account?
In some hosting platforms, yes. If the provider supports a private JVM or managed Tomcat through a control panel, you may be able to deploy and manage the app inside your hosting account without needing a full dedicated server setup.
Conclusion
A safe Tomcat migration starts with a full audit, not a file copy. Review Java and Tomcat compatibility, configuration files, filesystem permissions, external integrations, database dependencies, logging, proxy setup, scheduled tasks, and resource limits before you deploy. If you are using a managed hosting platform with Plesk and a Java extension such as My App Server, make sure you understand how the service is controlled, where the application runs, and which runtime versions are available.
When the audit is complete, you will have a clear migration plan, a better testing process, and far fewer surprises during cutover. That is the best way to move a Tomcat application with confidence.