If your Tomcat application uses a database, a successful migration is not just about copying the WAR file or moving the webapp directory. You also need to move the database itself, update connection settings, verify Java and Tomcat compatibility, and test the application in the new hosting environment before switching traffic.
When you host a Java application on a managed hosting platform with a private JVM and Apache Tomcat service, the migration process is usually straightforward if you follow the right order: back up the source system, export the database, deploy the application on the new Tomcat instance, restore the data, and then update configuration values through the control panel or application files.
This guide explains how to migrate a database-backed Tomcat application in a practical way, including common file locations, database export and import steps, and the checks you should perform after the move.
What you need to migrate
Before you start, identify every component used by the application. A Tomcat application that depends on a database typically includes more than one part:
- The web application package — usually a WAR file, or an exploded application directory.
- Application configuration — such as JDBC connection details, environment settings, and external service credentials.
- The database — MySQL, MariaDB, PostgreSQL, or another supported engine.
- Database user permissions — the account used by Tomcat to connect to the database.
- Uploads and runtime files — content stored outside the WAR, such as user uploads, attachments, logs, or generated files.
- Java and Tomcat version — the application may require a specific Java release or a specific Tomcat branch.
If you are moving to a hosting platform that offers Java hosting through a Plesk extension such as My App Server, the same general principles apply. You can install or select a Tomcat version, manage the service, and deploy the application under a private JVM, but the database still needs to be migrated carefully and tested separately.
Plan the migration before changing anything
A database-backed application should be migrated in a controlled sequence. If you copy files before the database is ready, or restore the database before confirming the application version, you can create schema mismatches or downtime.
Use this migration order:
- Inventory the application, database, and configuration files.
- Create a full backup of the source application and database.
- Set up the new Tomcat environment and Java version.
- Create the target database and user account.
- Deploy the application files.
- Import the database dump.
- Update connection settings.
- Test the application with staging or temporary URL access.
- Switch DNS or traffic only after validation.
This approach reduces the risk of broken sessions, missing tables, or startup errors in Tomcat.
Back up the source application and database
Always start with a complete backup. Do not rely only on the application files or only on a database export. For database-backed Tomcat apps, both are needed.
Back up the application files
Depending on how the app is deployed, back up one or more of the following:
- The WAR file.
- The exploded application directory inside Tomcat.
- Custom configuration files such as
context.xml,web.xml, or properties files. - Uploaded content stored in external folders.
- Certificates, keystores, or API keys if the application uses them.
If your current hosting provider uses a standard Tomcat layout, check the webapps folder, any custom conf entries, and external data directories. In managed hosting with a control panel, the application may be deployed through the panel interface rather than directly via SSH, so make sure you download both the deployed package and the live configuration.
Back up the database
Export the database in a format that can be restored on the target server. In most cases, SQL dump files are the safest choice.
- For MySQL or MariaDB: use a dump created with
mysqldump. - For PostgreSQL: use
pg_dump. - For other engines: use the native export tool.
Include stored procedures, routines, triggers, and views if your application uses them. Also verify whether the application depends on a specific character set or collation, especially for multilingual data.
Record the current connection settings
Before changing servers, note the existing database connection details:
- Database hostname
- Database name
- Username
- Password
- Port number
- JDBC driver name and version
- Any special connection parameters
This information will help you configure the new Tomcat instance quickly and avoid mistakes during deployment.
Prepare the new hosting environment
On the target hosting platform, create the runtime environment before restoring the application. If you are using a managed Java hosting service with My App Server, this usually means installing the Tomcat version required by the app and selecting the correct Java version in the control panel.
Choose the correct Java and Tomcat version
Compatibility matters. A web application built for an older Tomcat branch may not run correctly on a newer one, and some frameworks require a specific Java release.
- Check the app documentation for Java compatibility.
- Confirm the Tomcat version used in production.
- Match the target environment as closely as possible before making upgrades.
- If the app has not been tested with a newer version, migrate first with the same version, then upgrade later.
In a Plesk-based Java hosting environment, it is often easier to test with a known working Java/Tomcat combination first. After the app is stable, you can plan version changes separately.
Create the database and database user
Before restoring the dump, create the database on the new server and assign a user with the required privileges.
- Create an empty database.
- Create or reuse a database user.
- Grant the needed permissions.
- Check whether the app needs access from localhost or a specific host.
In many hosted environments, the database runs as a separate service, so the hostname may not be localhost. Use the value provided by the hosting control panel or service settings.
Deploy the Tomcat application files
Once the environment is ready, deploy the application package. The exact method depends on how the app was built and how the hosting account is managed.
Deploy a WAR file
If you have a WAR file, upload it to the application deployment area or the Tomcat webapps directory, depending on the hosting setup. On platforms with a managed control panel, the deployment may be performed through the Java app management interface rather than direct file copying.
After deployment, Tomcat usually expands the WAR automatically. If auto-deploy is disabled, use the panel controls or the Tomcat service configuration to trigger deployment.
Deploy an exploded application
If the app is already in exploded form, copy the full directory structure to the target location, including:
WEB-INF- Compiled classes
- Static resources
- JSP files
- Configuration files
Make sure the directory permissions allow the Tomcat process to read the application and write only where needed. Avoid giving unnecessary write access to the whole application tree.
Restore external files and uploads
Many webapps store user-generated content outside the WAR file. Common examples include:
- Profile images
- Document uploads
- Cache files
- Exported reports
- Temporary attachments
Restore these files to the same relative or absolute paths expected by the application. If the path changes on the new server, update the app configuration accordingly.
Import the database on the new server
After the application files are in place, import the database dump into the new database.
Import SQL data carefully
Use the appropriate tool for the database engine. During import, watch for these common issues:
- Character set mismatch
- Collation differences
- Foreign key constraint failures
- Missing routines or triggers
- Permission errors on the target database
If the source database is large, the import may take some time. Do not restart Tomcat repeatedly during import unless the application requires a schema check on startup.
Verify schema and data
After import, confirm that the important tables, rows, and reference data are present. Check record counts if possible. For content-managed applications, verify the tables that store users, sessions, uploads, or published content.
If the application uses an ORM framework such as Hibernate or JPA, make sure the schema version matches the application version. A mismatch can cause startup failures or runtime SQL exceptions.
Update configuration for the new database
After the database is restored, update the application so it connects to the new database service and credentials.
Common places to update
context.xmlor a Tomcat context descriptorapplication.propertiesdb.propertiespersistence.xml- Environment variables used by the start script
- Control panel fields for JDBC settings, if available
Typical JDBC settings to review include:
- JDBC URL
- Driver class name
- Database username
- Database password
- Connection pool settings
- SSL or encryption options
If your hosting platform allows management through Plesk and My App Server, you may be able to update service and application settings from the panel instead of editing every file by hand. That reduces mistakes and makes future maintenance easier.
Check for hardcoded source-host values
Some applications contain hardcoded references to the old environment, such as:
- Old database hostnames
- Absolute filesystem paths
- SMTP settings
- Third-party API endpoints
- Callback URLs
Search the configuration files and source code for these values before finalizing the move. If you miss one, the app may start but fail when it tries to load data or send notifications.
Validate Tomcat startup and database connectivity
Once the app is deployed and configured, restart Tomcat and check the logs. The first startup after migration is the most important diagnostic point.
What to check in the logs
- Successful deployment of the WAR or webapp directory
- JDBC driver loading
- Connection pool initialization
- Schema access and table reads
- Missing class or dependency errors
- Permission or file path errors
If the application fails to start, the logs usually reveal whether the issue is related to Java version, Tomcat version, missing libraries, or incorrect database credentials.
Test key application flows
Do not stop after the homepage loads. Test the functions that depend on the database:
- User login and logout
- Search and listing pages
- Form submissions
- Data creation and editing
- File upload and retrieval
- Payment, reporting, or API features if the app has them
If the app stores session state in the database, verify that sessions survive a restart if that is part of the design.
Update DNS only after validation
When the application works correctly on the new server, you can switch traffic. If the hostname changes, update DNS records only after testing the target system.
Lower the DNS TTL in advance if possible. This helps propagate the new address faster and reduces the chance of users being sent to the old environment after the cutover.
If the migration is part of a move to a new managed hosting account, keep the old service available for a short overlap period in case you need to compare data or fix a configuration problem.
Common migration problems and how to fix them
Tomcat starts, but the app cannot connect to the database
Check the JDBC URL, username, password, port, and host. Also verify that the database user has the correct permissions and that the database service allows connections from the application host.
The app fails with a Java version error
The application may have been compiled for a different Java release. Install the required version in the hosting platform, or rebuild the app with a compatible target if you have access to the source code.
Pages load, but data is missing
This usually means either the database import was incomplete or the app is pointing at a different database. Confirm that the correct database name is set in the configuration file and compare row counts on key tables.
Uploaded files are missing
Restore the external upload directory and confirm the application points to the same path. If the old path is not available on the new server, update the config or environment variable accordingly.
Character encoding looks wrong
Check the database encoding, JDBC connection settings, and application locale settings. Mismatched UTF-8 configuration is a common cause of broken special characters after migration.
Tomcat deployment works locally but not in hosting
Review file permissions, memory limits, service settings, and the Tomcat version available in your hosting control panel. On managed platforms, deployment may also depend on the service being started through the panel rather than a manual script.
Recommended migration checklist
Use this short checklist before you go live:
- Application files backed up
- Database exported and imported successfully
- Database user and permissions configured
- Correct Java version selected
- Correct Tomcat version installed or enabled
- Connection settings updated
- External files restored
- Logs reviewed for startup errors
- Core application flows tested
- DNS switched only after validation
This checklist is especially useful when you move a Tomcat app into a managed hosting account with a private JVM, because the deployment may involve both panel-managed settings and manual application configuration.
FAQ
Can I migrate only the WAR file and keep the same database?
Yes, if the database stays on the same server and the connection settings do not change. However, even in that case, you should confirm that the application version is compatible with the existing schema.
Should I restore the database before or after deploying Tomcat?
Either order can work, but the safest approach is to create the target database first, deploy the application files, and then import the data. After that, update the connection settings and restart Tomcat.
Do I need the same Tomcat version on the new hosting platform?
For the cleanest migration, yes. Use the same Tomcat version first, especially if the application has not been tested on a newer release. You can upgrade later after successful validation.
What if the application uses a connection pool?
Update the pool settings in the same place where the JDBC connection is configured. Check maximum connections, validation queries, and timeout values if the new environment has different performance characteristics.
Can I move a Tomcat app with no downtime?
For simple applications, you can reduce downtime by preparing the target environment in advance, syncing files, and doing a final database delta migration shortly before the switch. Full zero-downtime migration is more complex and usually depends on the app design, so most hosted Tomcat migrations use a short maintenance window instead.
Where should I look if the app works but shows old data?
Check whether it is connecting to the old database, whether cached data needs to be cleared, or whether the app reads from another source such as a remote API or secondary table.
Conclusion
Migrating a database-backed Tomcat application is mainly about order and verification. Copying the WAR file is only one step. To move the application safely, back up the files and database, recreate the runtime environment, restore the data, update the JDBC configuration, and test the application before switching traffic.
If your hosting platform provides Java hosting through a Plesk extension such as My App Server, you can manage the Tomcat service, Java version, and deployment settings from a central control panel. That makes migration easier, but the core tasks remain the same: keep the application files, database, and configuration aligned.
When those pieces match, your Tomcat application should start normally, connect to the restored database, and continue working in the new hosting environment with minimal disruption.