If you are moving a Tomcat-based website or web application to a new hosting account, the safest approach is to separate the migration into three parts: application files, Tomcat configuration, and any database used by the app. On a managed hosting platform with Plesk and a Java hosting extension such as My App Server, this usually means copying your deployable artifacts, recreating the runtime settings, and then testing the service before you switch DNS or change the live endpoint.
This guide explains how to move Tomcat application files and configuration to a new host in the UK, with practical steps for WAR deployment, JSP/Servlet applications, private JVM settings, and common database connection updates. It is written for hosting customers who manage their own Tomcat instance inside a hosting account and want a clean migration with minimal downtime.
What you need before you start
Before copying anything, collect the details of the current environment. A Tomcat migration is much easier when you know exactly which application version is running, where its files are stored, and how it connects to the database.
- The current Tomcat version and Java version.
- Whether the app runs as a WAR file, an exploded webapp directory, or a custom application layout.
- The application context path, for example
/appor/myapp. - Any modified Tomcat files such as
server.xml,context.xml,web.xml, or customsetenv.sh/ startup scripts. - Environment variables, JVM options, and memory settings.
- Database type, hostname, database name, user, and password.
- Upload paths, log locations, file storage directories, and permission requirements.
- Any scheduled tasks, background jobs, or external integrations used by the app.
If your hosting plan uses My App Server in Plesk, check which Tomcat or Java runtime is installed and whether you are using one of the ready-made versions or a custom runtime package. This matters because the target host should match the application’s Java requirements as closely as possible.
Understand what should be moved
For most Tomcat applications, migration is not just about copying one folder. A complete move usually includes:
- The application build output, usually a WAR file or application directory.
- Custom configuration files outside the WAR, if the application uses them.
- Tomcat runtime settings such as JVM options, ports, and context settings.
- Database schema and data, if the application stores data in MySQL, MariaDB, PostgreSQL, or another database.
- User-uploaded files, generated reports, cache files, or attachments.
- SSL or proxy-related settings if the app depends on a specific host name or scheme.
In managed hosting, it is common for Tomcat to run as a private service within the hosting account. That is useful because you can keep the application isolated from other websites, choose a supported Java version, and control service settings from the control panel instead of editing the server directly.
Step 1: Put the application into a stable state
If the application is live, reduce the chance of file changes during the copy.
- Pause admin activity if possible.
- Stop background import or sync jobs.
- Disable temporary uploads or maintenance tasks during the final copy.
- Note the current application version and deployment date.
If you cannot stop the application completely, at least make sure you know which files may still change, such as uploaded attachments or generated content. These often live outside the main WAR file and are easy to forget.
Step 2: Back up the source Tomcat application
Create a full backup before making any changes. This should include both files and configuration.
Back up the deployable package
Copy the WAR file or the unpacked application directory from the current host. If the application was deployed from a CI pipeline, retrieve the exact release artifact rather than rebuilding from source unless that is part of your normal release process.
Back up configuration files
Depending on how the app is set up, configuration can be stored in several places:
- Inside the application itself, for example under
WEB-INF/classes. - In a separate external config directory.
- In Tomcat context descriptors.
- In environment variables or startup parameters.
Common Tomcat files to review include server.xml, context.xml, catalina.properties, and any application-specific property files. If the app uses a custom startup script, copy that too.
Back up database data
If the application stores data in a database, export the schema and data. The exact method depends on the database engine, but the key point is to keep the backup consistent with the application version you are moving.
Back up uploaded and generated files
Many Tomcat apps store files outside the WAR, such as:
- User uploads.
- Image assets.
- Exported reports.
- Log archives.
- Cached documents or temporary processing files.
These directories are often the first thing that gets missed during a migration, so verify their paths carefully.
Step 3: Prepare the new host in Plesk or the control panel
On the destination hosting account, make sure the Java runtime and Tomcat service are ready before copying files. With a Plesk-based Java hosting setup, this usually means enabling or creating the Tomcat application instance through the hosting extension.
- Confirm that the correct Java version is available.
- Select the Tomcat version that matches the source application.
- Create or verify the application path and context.
- Check that the service is running under the correct hosting user.
- Review limits such as memory, file size, and process restrictions.
If the source app depends on an older Java release, test that version first. If the app was written for Java 8 and you deploy it on a newer runtime, differences in libraries, security policies, or deprecated APIs may cause startup errors.
Step 4: Move the application files
Once the new host is ready, upload the application package. The right method depends on how the app was originally deployed.
If you have a WAR file
The simplest migration is to upload the WAR file to the new Tomcat deployment area and let Tomcat unpack it. Make sure the file name matches the desired context path if your setup uses automatic deployment naming.
For example, a file named myapp.war often deploys to /myapp. If you want a different context, configure it explicitly rather than relying on the file name alone.
If you have an exploded application directory
Copy the entire directory structure, not just the visible web pages. A valid Tomcat webapp may include:
WEB-INF/classesWEB-INF/lib- JSP files
- Static assets
- Custom property files
Keep the directory permissions consistent with the hosting account’s file ownership model. In a shared hosting environment with a private JVM, files should usually be owned by the hosting user rather than by root or another system account.
If the app uses external directories
Some applications read configuration or data from paths outside the webroot. Recreate those folders on the new host and update absolute paths if needed. Where possible, prefer relative or environment-based paths to reduce future migration work.
Step 5: Recreate Tomcat configuration
Most migration issues come from configuration differences rather than from the application itself. Review the runtime settings one by one.
JVM options and memory settings
Copy the memory and system property settings from the source server, but check whether they still make sense for the new environment. Common options include:
-Xmsand-Xmxmemory limits.- Encoding settings such as
-Dfile.encoding=UTF-8. - Application-specific system properties.
- Timezone settings if the app depends on local time.
On a hosting platform with My App Server, these settings are usually managed through the control panel or the service configuration screen. That is safer than editing low-level files manually because it keeps the service configuration consistent.
Ports and connector settings
If the source server used non-default ports, custom HTTP connectors, or AJP, review them carefully. In many hosted environments, external access is handled through the platform’s web server layer, so you may not need to expose the same connector setup as on the old host.
Context path and application location
Verify how the application is mapped. Some apps work best when deployed at the root path, while others need a fixed subpath. If the source application relied on a specific context, recreate that context on the new host so links, redirects, and session handling continue to work.
Custom environment variables
If the app reads values from environment variables, set them again in the new hosting environment. This can include API keys, endpoint URLs, filesystem paths, or feature flags.
Step 6: Update database settings
After the files are copied, the next common task is changing database connection details. This is especially important if the new host uses a different database server or credential set.
- Update the database host name.
- Replace the database name if it changed.
- Set the new username and password.
- Check the JDBC URL format.
- Verify the correct driver class and driver JAR.
For example, a connection string may need to change from a local or internal address to the managed database service provided with the new hosting account. If your application stores these settings in a property file, update them before the first startup so Tomcat does not fail during initialisation.
After the update, test the connection from the application itself if possible. A successful database login does not always guarantee the application is fully working, so check at least one read and one write operation.
Step 7: Move uploaded content and data directories
Many applications work during deployment but fail later because they cannot find user files. To avoid this, migrate any persistent storage separately from the app binary.
- Copy upload folders.
- Restore report archives or document repositories.
- Move any files the application expects to read at runtime.
- Check that path names match the new host structure.
If the application generates files under a temporary directory, confirm whether those files are disposable or must be preserved. It is often better to recreate the directory structure on the new host and let the application repopulate non-critical caches after launch.
Step 8: Test the Tomcat service before going live
Do not switch production traffic until the application starts cleanly and basic functionality works on the new host. A good migration test includes:
- Tomcat starts without errors.
- The app deploys without compilation or classpath errors.
- Login or homepage access works.
- Database queries succeed.
- Uploads, downloads, and form submission work.
- Logs show no repeated exceptions.
Check both the application logs and the Tomcat logs. If you are using a private JVM service in a managed control panel, review the service status and the log output from the service management area. This is often the fastest way to spot missing files, wrong permissions, or incompatible Java settings.
Common migration problems and how to fix them
Class not found or NoClassDefFoundError
This usually means a missing JAR or an incomplete deployment. Verify that all libraries from WEB-INF/lib were copied and that the application is using the same dependency set as before.
Permission denied
Check file ownership and directory permissions. In hosting environments, the Tomcat service often runs under the account user, so files must be readable and, where needed, writable by that user.
Application starts but pages are broken
This can happen when the app depends on an absolute path, external config file, or old host name. Search the configuration for hardcoded paths and update them.
Database connection errors
Review the JDBC URL, driver version, and password. If the database server changed, confirm that remote access rules or host permissions are correct.
Wrong Java version
Some older apps will not start on newer Java releases, while some newer apps require a more recent runtime. Match the Java version to the application’s documented support first, then adjust only if you have tested compatibility.
Session or login problems after migration
If the app uses sessions, cookies, or encryption keys stored in config, make sure the same values are present on the new host. A changed context path or domain name can also affect session cookies.
Best practices for Tomcat hosting migrations
To keep future migrations easier, use a repeatable structure for application files and configuration.
- Keep app config outside the WAR when practical.
- Document all JVM options and environment variables.
- Store database settings in one clearly named file.
- Avoid hardcoded absolute paths.
- Use UTF-8 consistently for file encoding and database character sets.
- Keep deployment artifacts versioned and labelled.
- Test on a staging host before switching live traffic.
On a hosting platform with My App Server, these habits make it easier to move between hosting accounts, recreate services, and choose the right Tomcat or Java version without reworking the entire application.
Example migration checklist
- Confirm source Tomcat and Java versions.
- Back up WAR, config, database, and uploads.
- Prepare the target account and Java service.
- Upload the application files.
- Restore or recreate configuration.
- Update database connection settings.
- Copy persistent content directories.
- Start Tomcat and review logs.
- Test login, pages, forms, and database actions.
- Switch DNS or routing only after verification.
FAQ
Do I need to move the entire Tomcat installation?
Usually no. In hosted Java environments, you normally move the application, its config, and its data, not the full Tomcat installation. The target host provides the Tomcat runtime or private JVM service, and you deploy your app into it.
Can I move a WAR file directly to the new host?
Yes, if the app is packaged as a WAR and does not rely on special external files that were stored elsewhere. Even then, always review database settings, context paths, and any upload directories.
What if the old server used a different Java version?
Try to match the source version first. If that is not possible, test carefully on the new runtime because some Java applications are sensitive to version changes.
How do I know which config files to copy?
Check the deployment notes, startup scripts, and application properties. If the app has been running for a long time, inspect the runtime environment on the source host and list every non-default setting.
Should I migrate logs as well?
Logs are not usually required for the application to run, but they can be useful for troubleshooting. If you need audit history or error analysis, keep an archive of the old logs separately.
Can I use this process for JSP and servlet applications?
Yes. JSP, servlet, and WAR-based applications follow the same general migration pattern: copy the deployable files, recreate the runtime config, and update any external resources.
Conclusion
Moving Tomcat application files and configuration to a new host is straightforward when you treat it as a structured migration rather than a simple file copy. Start with a backup, move the WAR or webapp directory, recreate the Tomcat and JVM settings, update database details, and test the service before making the new host live. In a managed hosting environment with Plesk and My App Server, this process is usually easier because you can control Tomcat, Java version, and service settings from one place while keeping the application isolated inside the hosting account.
For best results, keep the configuration documented and make sure all persistent files, external paths, and database connections are checked before you cut over. That reduces downtime and avoids the most common migration issues.