Before you move a Tomcat project to a new host, collect the application details, runtime settings, and access information that determine whether the migration will be smooth or full of surprises. For Java hosting on a managed platform, the safest approach is to treat the move as a small deployment project: first document what the app needs, then confirm what the new hosting environment supports, and only after that copy files and switch traffic.
This is especially important when the application runs on Apache Tomcat, uses JSP or servlets, or depends on a private JVM managed through a control panel such as Plesk. A Tomcat site can look simple from the outside, but the real migration scope often includes Java version compatibility, memory settings, context paths, database connections, scheduled tasks, uploaded files, and any custom server configuration.
What to collect before the migration
Start by building a complete inventory of the current setup. The goal is to understand not only what the app is, but also how it runs in production.
1. Application build and deployment details
Collect the core deployment package and note how the application is delivered:
- WAR file, EAR file, exploded directory, or custom build output
- Source repository location, if you maintain the project in Git or another VCS
- Build tool and version, such as Maven, Gradle, or Ant
- Build profile used for production
- Deployment steps and any post-deploy script actions
If the project is deployed as a WAR, keep the exact file that is currently in production. If the application is built from source, make sure the build is reproducible before the move. A migration is not the right time to discover that the deployed artifact cannot be recreated.
2. Tomcat version and Java version
Record the exact Apache Tomcat version and Java runtime version used on the old host. These two items are among the most common causes of migration issues.
- Tomcat major and minor version
- JDK or JRE version in use
- Whether the app depends on a specific vendor build, such as Oracle, OpenJDK, or another distribution
- Any Java options passed at startup
Even if the application works on an older JDK, you should verify compatibility with the target environment. Some older frameworks or libraries behave differently on newer Java releases. When using a managed Java hosting service with a private JVM, confirm which versions are available and whether a custom version can be uploaded and configured.
3. Tomcat configuration files
Collect the configuration files that control the runtime behavior of Tomcat:
- server.xml
- context.xml
- web.xml, if custom changes were made
- tomcat-users.xml, if management access is needed
- setenv.sh, setenv.bat, or equivalent startup script
- logging configuration files, such as logging.properties
Also note any changes made outside the default installation. In many cases, the issue is not the application itself but a custom connector, port, session timeout, or JVM flag defined in the Tomcat configuration.
4. Environment variables and JVM options
Collect all environment variables and Java parameters used by the app. These often contain settings that are easy to forget but critical during startup.
- JAVA_HOME and any custom runtime path
- CATALINA_HOME and CATALINA_BASE, if applicable
- Memory settings such as -Xms and -Xmx
- GC-related options
- System properties passed with -D
- Locale, encoding, or timezone settings
For hosted Tomcat environments, memory limits and JVM options are often controlled from the panel rather than directly in shell scripts. Make sure you know which values are essential so they can be recreated in the new control panel setup.
5. Application paths and URL structure
Write down how the application is exposed to users:
- Context path, such as /app, /shop, or the root context
- Virtual host name, if the app uses a custom domain
- Redirect rules and rewrite logic
- Static asset locations
- Admin or internal URLs that should remain protected
This information helps you preserve links, bookmarks, and integrations after the move. If the application depends on a specific context path, changing it during migration can break login flows, callback URLs, and API clients.
Data you must not forget
A Tomcat migration is rarely just about application files. Many apps depend on data stored outside the WAR package.
1. Database connections
Gather all database-related details for every environment used by the application:
- Database type, such as MySQL, MariaDB, PostgreSQL, or Microsoft SQL Server
- Database host, name, and port
- JDBC driver version
- Datasource definitions in Tomcat or the application
- Username and authentication method
- Connection pool settings
Check whether database credentials are stored in the application, in Tomcat resources, or in an external configuration file. If the new host provides a different datasource naming pattern or a different JDBC driver version, test this before cutover.
2. Uploaded files and persistent content
Identify where the app stores user uploads, generated documents, cached images, and any other persistent content.
- Upload directories
- Media folders
- Report output paths
- Temporary files that must be preserved
- Archive or export directories
Do not assume these files are inside the application package. In many Java web apps, uploads live outside the WAR and must be copied separately. If possible, determine whether the application writes to shared paths, absolute paths, or the user’s home directory.
3. Scheduled tasks and background jobs
Collect all jobs that run outside the normal web request flow:
- Cron jobs or scheduled shell scripts
- Internal schedulers such as Quartz
- Batch import/export jobs
- Email queues and notification tasks
- File cleanup jobs
If the application sends reports, syncs data, or performs periodic cleanup, document the schedule and the command used to run it. A hosting migration often fails quietly when the web app works but the background job no longer runs.
4. Email and notification settings
Collect SMTP and messaging settings used by the application:
- SMTP host, port, username, and password handling
- Sender addresses and reply-to addresses
- SSL/TLS requirements
- Mail templates or notification rules
- SMS or third-party alert integrations, if used
After migration, mail delivery issues are common because a new host may use different outbound mail rules or require a different authentication method. Note down every address and relay dependency before making the move.
Security and access information to gather
Migration planning should also include access control and security-related settings. These are easy to overlook, but they often cause application outages after the move.
1. TLS certificates and domain validation
Collect the certificate-related information for all domains and subdomains used by the application:
- Certificate type and issuing authority
- Domains and SAN entries covered by the certificate
- Expiry date
- Whether the certificate is installed at the server, proxy, or load balancer level
- Any intermediate certificate chain files
If the app uses HTTPS redirects, HSTS, or secure cookies, confirm that these will be re-enabled on the new host before switching traffic.
2. Authentication and external integrations
Make a list of systems the application connects to or authenticates against:
- LDAP or Active Directory
- OAuth or SSO providers
- Payment gateways
- CRM, ERP, or API integrations
- Webhooks and callback URLs
These integrations may require IP allowlists, updated redirect URLs, or new credentials. If the application exposes public APIs, collect the current endpoint list so you can test them on the new host.
3. Admin access and operational accounts
Document all operational access needed for the migration:
- Tomcat or panel login credentials
- SSH access, if used
- File transfer credentials
- Database admin access
- Any service-specific admin accounts
For a managed hosting setup with Plesk and My App Server, the service may be controlled from the panel instead of directly from the shell. In that case, collect the account permissions needed to install, start, stop, and update the Tomcat instance, and make sure the access is available before the cutover window.
Performance and resource settings to record
Good migration planning also means understanding the resource profile of the current app. This helps you choose a realistic hosting setup and avoid premature performance issues.
1. Memory and CPU usage patterns
Note the observed resource usage during normal traffic and during peak load:
- Typical and peak RAM usage
- CPU spikes during report generation, imports, or heavy requests
- Thread count and worker behavior
- Garbage collection pressure, if known
This is useful when you move to a Tomcat hosting platform with defined limits. If you know the app regularly needs more memory during batch processing, you can plan the JVM settings accordingly instead of discovering the limit after the move.
2. Connection and thread pool settings
Record any custom pool values used by the app or Tomcat:
- Max database connections
- Request thread pool size
- Session timeout values
- Asynchronous job concurrency
These settings help you match the new environment closely enough for a meaningful test. Do not copy production values blindly if the new hosting account has different limits; instead, document them and then adapt them to the target plan.
How to prepare the migration package
Once you have gathered the information, organize it into a migration pack. This makes the handover easier whether you are moving the application yourself or asking support to help.
Recommended migration checklist
- Current Tomcat version and Java version
- WAR file or build output
- Source repository and build instructions
- All Tomcat configuration files
- JVM options and environment variables
- Database connection details and JDBC driver information
- Upload folders and persistent data paths
- Cron jobs and scheduled tasks
- SMTP and notification settings
- TLS certificate and domain details
- Integration endpoints and callback URLs
- Admin access and operational accounts
- Performance notes and resource usage
It is also useful to note what should not be copied. For example, temporary files, local caches, and old log archives are usually not needed on the new host. Keeping the package clean reduces the chance of carrying over an old configuration problem.
Planning for a Tomcat migration on managed hosting
If the new host uses a managed Java hosting setup with a control panel, check how Tomcat is installed and controlled there. On a platform with a dedicated Java extension such as My App Server, you can usually install or manage a private Tomcat instance from the panel, choose a supported Java version, and control the service without building everything manually from scratch.
Before migration, confirm the following:
- Which Tomcat versions are available by default
- Whether a custom Tomcat version can be uploaded and configured
- How the service is started, stopped, and restarted
- Where logs are stored
- How JVM options are set
- What file paths are available for deployment and persistent storage
This is particularly helpful for small and medium Java applications, JSP sites, servlet-based apps, and applications that need a separate JVM without a complex enterprise stack. If your project depends on a simple private runtime with straightforward deployment, a managed Tomcat environment can reduce operational overhead while still leaving you enough control for the application to run properly.
Common mistakes when collecting migration data
Many migration problems come from missing details rather than from the move itself. Watch out for these common mistakes:
- Copying the WAR but forgetting external uploads or database seeds
- Not recording the exact Java version
- Missing a custom JVM option that the app needs at startup
- Ignoring scheduled jobs and background processing
- Overlooking hardcoded URLs in configuration files
- Forgetting to document TLS certificate and redirect behavior
- Assuming the new host will use the same directory layout
A short discovery phase can prevent hours of troubleshooting later. If the app has grown over time, ask the original developer or administrator to review the inventory so that hidden dependencies are not missed.
Practical migration workflow
A simple workflow makes the collection process manageable:
- Identify the application, its domain, and its current runtime environment.
- Export the Tomcat and Java version details.
- Collect configuration files, environment variables, and startup options.
- List databases, file paths, uploads, and scheduled tasks.
- Document certificates, authentication flows, and integrations.
- Check the new hosting platform for supported versions and limits.
- Prepare a test deployment before the final cutover.
If the new host offers a Plesk-based Java environment, test the deployment in a staging location first. This allows you to validate WAR deployment, service control, logging, and data paths before users are switched over.
FAQ
What is the most important thing to collect before moving a Tomcat app?
The most important items are the Tomcat version, Java version, application package, configuration files, and all external dependencies such as database access and file storage paths. Without these, the app may deploy but fail to start or behave differently after the move.
Do I need the source code if I already have the WAR file?
The WAR file is often enough for deployment, but the source code is still valuable for troubleshooting, rebuilding, and verifying configuration. If possible, collect both the package and the source repository details.
Should I copy the entire Tomcat installation?
Not always. In a managed hosting environment, it is usually better to recreate the required settings in the new service rather than copying a full old installation. What you must preserve are the configuration values, runtime options, and any custom files that the app depends on.
How do I know if the new host supports my Java version?
Check the hosting platform’s supported Java versions and available Tomcat options before migration. If the app needs a specific version, confirm whether it can be selected directly or uploaded as a custom runtime.
What if my app uses a database stored on another server?
Collect the database endpoint, credentials, JDBC driver version, and any firewall or IP allowlist requirements. Then test connectivity from the new host before going live.
What should I collect for a JSP-only site?
For a JSP site, collect the same core items: Java version, Tomcat version, deployment structure, context path, configuration files, static assets, and any backend integrations. JSP sites still depend on the Java runtime and web server settings.
Final checks before cutover
Before you switch traffic, confirm that you have:
- A complete copy of the deployment artifact
- Matching or compatible Java and Tomcat versions
- Recreated JVM settings and environment variables
- Database connectivity tested on the new host
- Uploads and persistent data copied
- Cron jobs and background tasks restored
- TLS certificates installed and verified
- Application URLs checked after deployment
- Logs monitored during the first startup
A Tomcat migration is much easier when the discovery work is done properly. By collecting the deployment package, runtime settings, data paths, and integration details in advance, you reduce downtime and avoid the usual post-move surprises. For hosted Java environments, especially those managed through Plesk and a private Tomcat service, this preparation also makes it easier to recreate the application in a clean, supportable way.