If you are planning to move a Tomcat project to a new host, the safest approach is to collect everything the application depends on before you start the migration. For a Java web app, missing one small detail can lead to a failed startup, broken sessions, database errors, or class loading problems after deploy. A good preparation checklist also saves time when you are moving the project into a managed hosting environment with Plesk, Apache, and a private JVM or Tomcat instance.
Whether you are moving a WAR-based application, a JSP site, or a servlet project, the goal is the same: identify the runtime version, application files, environment settings, external dependencies, and operational requirements before you switch hosts. If you use a hosting platform with Java hosting support such as a Tomcat service managed from Plesk, this information helps you choose the correct Java version, set up the service properly, and reduce downtime during the move.
What you should collect before the migration
Before you copy files or change DNS, make sure you have a complete picture of the current application. For Tomcat hosting, the most useful items usually fall into these groups:
- Application source or deployment package
- Tomcat and Java version details
- Configuration files and environment variables
- Database connection information
- External services, APIs, and file storage paths
- Security certificates and trust settings
- Scheduled jobs, logs, and monitoring requirements
- Memory, port, and resource usage details
If you collect these items in advance, the move becomes a controlled change instead of a troubleshooting exercise.
1. Identify the exact application type
Start by documenting what you are moving. A Tomcat project can look simple from the outside, but the deployment method matters.
Collect these details
- Is the application packaged as a WAR file?
- Is it a plain JSP/Servlet application?
- Does it include a custom build process with Maven, Gradle, or Ant?
- Does it require a specific context path?
- Does it run as one app or multiple related webapps?
This helps you understand how the app should be deployed on the new host. In a hosting environment with a private JVM or a Tomcat service controlled through Plesk, knowing the app type also helps determine whether you can use a ready-made Java/Tomcat version or whether you need to upload and configure a custom one.
2. Record the current Java and Tomcat versions
Version compatibility is one of the most common reasons for migration problems. Before moving the project, note the exact Java runtime and Tomcat version currently used in production or staging.
Document the following
- Java version, for example Java 8, 11, 17, or another specific build
- Tomcat version, such as Apache Tomcat 8.5, 9, or 10
- Any special JVM flags used at startup
- Whether the application depends on deprecated APIs
- Whether the project uses javax.* or jakarta.* namespaces
This is especially important if you are moving to a platform that offers multiple Java/Tomcat versions for installation. Choosing a compatible version can prevent class loading errors and startup failures. If the app was built for an older Tomcat release, test carefully before upgrading to a newer major version.
3. Gather all deployment files and build artifacts
Make sure you have the exact deployable package that works today. If the source repository is the only thing you have, confirm that you can rebuild the project in a reproducible way.
What to collect
- Current WAR file or exploded application directory
- Source code repository link and branch name
- Build files: pom.xml, build.gradle, build.xml, or similar
- External libraries bundled in WEB-INF/lib
- Any custom jars copied manually to the server
- Static assets, templates, and uploaded files stored outside the package
Do not assume that the current deployment can be recreated from the repository alone. In many Tomcat projects, a few manual files were added over time and are not tracked in version control. Collect those files before the old host is changed or decommissioned.
4. Export the full Tomcat configuration
Tomcat configuration is often spread across several files. To migrate safely, collect every setting that affects how the application runs.
Key files and settings to save
- server.xml
- context.xml
- web.xml if it was customized globally
- setenv.sh or setenv.bat
- catalina.properties if modified
- logging configuration files
- Custom manager or connector settings
Also note the ports in use, SSL connector settings, host definitions, and any custom realms or valves. If your application depends on a non-default context root or connector, you should recreate that on the new host before the application goes live.
5. Collect all environment variables and JVM options
Many Tomcat applications behave differently depending on runtime variables. Some settings live in shell scripts, service files, or control panel fields rather than inside the app itself.
Look for these items
- JAVA_HOME
- CATALINA_HOME and CATALINA_BASE
- JVM heap settings such as -Xms and -Xmx
- GC flags or memory tuning options
- Active profile names such as dev, test, or prod
- System properties passed with -D options
- Locale, timezone, and file encoding settings
If you are moving to managed hosting with a private JVM, these settings may need to be entered in the service control interface or startup configuration. Collecting them in advance reduces the chance that the app starts with default values and behaves differently after migration.
6. Document database connections and schema dependencies
For many Tomcat projects, the application is only one part of the migration. The database and its credentials are just as important.
What to collect
- Database type and version
- Host, port, database name, username, and password rotation process
- JDBC driver name and version
- Connection pool settings
- Schema name and ownership details
- Migration scripts, stored procedures, or seed data
Also check whether the app uses JNDI data sources, direct JDBC connections, or an ORM such as Hibernate. If the application expects a resource defined in Tomcat, that resource must be recreated on the new host. If the database itself is moving too, plan the order of operations carefully so the app is not pointing to an empty or unavailable backend.
7. List all external services and integrations
Modern Java web apps often depend on services outside the application server. Missing one integration detail can cause login failures, broken payment flows, or missing notifications.
Common dependencies to collect
- SMTP server settings
- Payment gateways
- Authentication providers and SSO endpoints
- REST or SOAP APIs
- Object storage or file transfer services
- Third-party license servers or webhook endpoints
Write down each endpoint, credential type, and any IP allowlisting requirements. If the new host changes outbound IP addresses, external services may need their access rules updated before the application can communicate again.
8. Find file system paths and writable directories
Tomcat applications often need read and write access to specific folders. These paths may be hardcoded, configured in properties files, or defined through environment variables.
Check for paths such as
- Upload directories
- Temporary file locations
- Report export paths
- Image or document storage folders
- Log file directories
- Configuration folders outside the WAR
Collect both the path and the expected permissions. On a new host, the application may start successfully but fail later when it tries to write a file. This is a common issue during Java hosting migrations, especially when the app was originally installed on a server with custom filesystem rules.
9. Save SSL/TLS and certificate details
If the site uses HTTPS, gather the certificate information before the move. This includes both the public certificate and any supporting chain or trust material.
Collect the following
- Certificate expiry date
- Private key location
- Intermediate certificate chain
- Keystore type, such as JKS or PKCS12
- Keystore password handling process
- Any client certificate or mutual TLS requirements
If the application uses its own keystore, verify whether the new host should keep the same file or whether the certificate will be reinstalled in the control panel or service configuration. In a Plesk-based environment, SSL handling may be split between the web server and the Tomcat service, so plan both sides of the setup.
10. Check users, permissions, and service accounts
Some Tomcat applications rely on a specific OS user or service identity. Even in shared hosting or managed setups, the application may still need defined ownership and permissions.
Document these items
- Operating system user under which Tomcat runs
- Group ownership and file permissions
- Any sudo or service-level requirements
- Whether scheduled tasks run under the same user
- Access rules for logs and upload folders
Correct ownership matters because the app may need to create files, rotate logs, or reload configuration at runtime. If permissions are too restrictive, the application might start but fail under load or after a restart.
11. Collect logs and error history
Logs are one of the most useful migration tools. They show what the application expects and what breaks when a dependency changes.
Save recent logs from the source host
- Tomcat catalina logs
- Application logs
- Access logs
- Database or connector error logs
- Any startup stack traces
Look for recurring warnings, missing file errors, deprecated API messages, and connection failures. These clues often reveal hidden dependencies that should be recreated on the new host. If the app is already unstable on the old server, solve those issues before migration rather than carrying them forward.
12. Review scheduled jobs and background tasks
Many Java applications use scheduled tasks for cleanup, email, imports, sync jobs, or report generation. These jobs are easy to forget during a move.
Collect information about
- cron jobs or system schedulers
- Quartz jobs or in-app schedulers
- batch scripts and shell commands
- timing, frequency, and execution windows
- dependencies on specific paths or credentials
If the job depends on a running Tomcat instance, make sure the new host supports the same execution pattern. If it runs as a separate process, document how it is started, monitored, and stopped.
13. Prepare a rollback plan and validation checklist
Migration planning is not only about what to move. It is also about how to verify the result and how to go back if something fails.
Before the cutover, prepare
- A snapshot or backup of the old application state
- Database backup and restore method
- DNS switch plan and propagation expectations
- Health check URL or test endpoint
- Expected login and transaction test cases
- Rollback trigger conditions
A clear validation checklist is especially useful in hosting migrations with a control panel. You can test the Tomcat service, confirm the application starts, check log output, and verify that static assets, forms, and database calls work before updating public traffic.
Recommended migration checklist
If you want a simple working order, use this checklist before moving the project:
- Confirm the current Java and Tomcat versions.
- Export the deployment package and all custom libraries.
- Copy Tomcat configuration files and JVM options.
- Document database and external service dependencies.
- Identify writable paths and permission requirements.
- Save SSL certificate and keystore details.
- Review logs for hidden runtime dependencies.
- Record scheduled jobs and background tasks.
- Prepare a test plan and rollback plan.
- Verify the new host supports the required runtime setup.
How this helps in a managed Tomcat hosting environment
When you move a project to a managed hosting platform with Java support, the collected information makes setup much faster. A service such as My App Server in Plesk-style hosting can provide a practical way to run a private JVM and manage Apache Tomcat from the control panel. In that scenario, the migration data helps you choose the right Java version, deploy the WAR file, recreate service settings, and match the old runtime as closely as possible.
This is particularly useful for small and medium Java applications that need straightforward deploy and service control, rather than a complex enterprise application server setup. You can focus on the essentials: compatibility, deployment, resource settings, and a clean cutover.
Common mistakes to avoid
- Moving only the WAR file and forgetting external configuration.
- Assuming the new Tomcat version will behave exactly the same.
- Missing a custom JDBC driver or JNDI resource.
- Overlooking file permissions for uploads or temp folders.
- Ignoring scheduled jobs that run outside the web app.
- Forgetting certificate chains or keystore passwords.
- Switching DNS before the app is tested on the new host.
The safest migrations are the ones where the application is documented well enough that the new environment can mirror the old one intentionally.
FAQ
Do I need the source code to move a Tomcat project?
Not always. If you have a working WAR file and all required configuration and libraries, you may be able to deploy without the source. However, source code is still useful for rebuilding the application and verifying dependencies.
Should I keep the same Java version on the new host?
Yes, if possible. Matching the current Java version reduces compatibility risk. If you plan to upgrade, test the application first in a staging environment and check for framework or library changes.
What is the most commonly missed item in a Tomcat migration?
External configuration is often missed: database resources, environment variables, file paths, and manual libraries. These are frequently stored outside the main application package.
Can I move a Tomcat app to a host with a control panel like Plesk?
Yes, if the hosting platform supports Java hosting and Tomcat service management. In that case, you will usually configure the app, Java runtime, and service settings through the panel rather than directly on the server.
How do I test the app before changing DNS?
Use a temporary URL, hosts file override, staging domain, or direct service test if your hosting setup allows it. Confirm that login, forms, file uploads, database calls, and static assets work correctly before the cutover.
What if my app uses a custom Tomcat version?
Document the exact version and dependency requirements. If the new host supports custom app server setup, you may be able to install or upload a matching version manually. Always test compatibility before production use.
Conclusion
Before moving a Tomcat project to a new host, collect the runtime version, deployment package, configuration files, environment variables, database details, external integrations, file paths, certificates, and logs. That information gives you a complete migration map and helps prevent the most common problems after cutover.
For hosting environments that support Java, private JVMs, and Tomcat management through a control panel, this preparation is even more valuable. It lets you recreate the application accurately, validate it step by step, and move it with far less risk. A careful checklist today is the fastest way to a stable launch on the new host tomorrow.