How to move a Tomcat application and database together

If you host a Java web application on Tomcat and it uses a MySQL database, the safest migration is to move both parts together: the application files and the database schema plus data. That way, you keep the app version, JDBC settings, schema, and credentials aligned and reduce downtime and configuration mistakes.

This guide explains how to move a Tomcat application and its MySQL database in a managed hosting environment, including a Plesk-based setup with a private Tomcat instance or JVM such as My App Server. It is written for small and medium Java applications, including WAR-based apps, JSP/Servlet projects, and custom Tomcat deployments.

What you need before you start

Before moving anything, collect the current application and database details. In most cases, the migration is straightforward when you know where the app stores its configuration and how it connects to MySQL.

Check the application type

WAR deployment — the app is packaged as a .war file and deployed to Tomcat.
Exploded application — files are deployed as a folder rather than a single archive.
Custom configuration — the app may use external config files, environment variables, or context XML.

Collect database information

Database name
Database username
Database password
Host name or IP
Port number, usually 3306 for MySQL
Character set and collation if the app depends on them

Identify where the connection settings are stored

Tomcat applications may store MySQL settings in one of these places:

context.xml
server.xml
application properties files
environment variables
framework-specific config such as Spring, Hibernate, or JDBC configuration files

In a hosted environment, the safest approach is usually to keep database credentials outside the code if the application supports it, and update them through the hosting panel or the app’s config file after the move.

Recommended migration approach

The best practice is to migrate in this order:

Prepare the destination Tomcat environment.
Export the MySQL database from the old environment.
Import the database into the new environment.
Copy the application files or deploy the WAR.
Update database connection settings.
Test the application before switching traffic.

This sequence helps avoid situations where the app starts before the database is ready or points to the wrong schema.

Step 1: Prepare the new Tomcat hosting environment

If you are using a hosting platform with a private Tomcat instance or private JVM, make sure the target service is installed and running before the migration begins. In Plesk-based Java hosting, this usually means checking the My App Server service and confirming that the correct Java version is selected.

Verify the Java and Tomcat version

Your app may depend on a specific Java runtime or Tomcat branch. Confirm that the destination environment supports the version your app expects. If the application was built for an older Java release, test it carefully before upgrading.

Confirm resource limits

Make sure the application fits within the hosting limits for CPU, memory, disk usage, and process behavior. For small and medium apps, a shared Java hosting account with an isolated Tomcat instance is often enough. For heavier workloads, evaluate whether the app needs more memory or a different deployment plan.

Check required directories and permissions

Tomcat apps often need write access for logs, upload folders, temporary files, and cache data. Make sure the target account has the right permissions for these paths, especially if the application stores files outside the WAR package.

Step 2: Export the MySQL database

Export the database from the current host before moving the app. You can use a control panel tool such as phpMyAdmin, a database management interface, or command-line tools if available.

Using a database export tool

When exporting, include:

table structure
data
stored procedures if used
triggers if used
views if used

If your app uses foreign keys, make sure the export preserves the order and constraints correctly. For most migrations, a standard SQL dump is sufficient.

Command-line export example

If command-line access is available, a typical export looks like this:

mysqldump -u database_user -p database_name > database_name.sql

For larger databases, compress the dump to reduce transfer time:

mysqldump -u database_user -p database_name | gzip > database_name.sql.gz

Important checks before export

Use the correct character encoding, usually UTF-8.
Check whether the app stores binary data or large text fields.
Note any scheduled tasks or background jobs that write to the database during export.

Step 3: Create the new MySQL database

On the destination hosting account, create a new MySQL database and user. In managed hosting, this is usually done from the control panel. Use the correct permissions so the app can read and write data without exposing unnecessary rights.

Best practice for database users

Create a dedicated user for the application.
Grant access only to the application’s database.
Avoid reusing old passwords unless you have a controlled reason to do so.
Document the new database name, user, password, and host.

Match the database engine settings

If the original app depends on specific MySQL settings, try to match them on the new host. This may include default character set, collation, strict mode behavior, or time zone handling. Differences here can cause subtle errors after migration, especially in date fields and multilingual content.

Step 4: Import the database on the new host

After creating the database, import the SQL dump into the new MySQL instance. If the dump was compressed, decompress it first or use a tool that can handle compressed imports.

Typical import command

mysql -u database_user -p database_name < database_name.sql

What to verify after import

The import completes without errors.
All tables are present.
Row counts look reasonable.
Special characters display correctly.
The application’s expected schema version matches the database.

If the app uses a migration tool such as Flyway or Liquibase, check whether schema versioning is handled by the app itself or already included in the database dump. Avoid running duplicate schema migrations unless you know the app is designed for it.

Step 5: Move the Tomcat application files

Once the database is ready, move the Tomcat application to the new hosting environment. How you do this depends on the deployment style.

If the app is a WAR file

Upload the .war archive to the Tomcat deployment location or through the hosting panel.
Let the container unpack and deploy it.
Confirm the context path and application name.

If the app is already exploded

Copy the full application directory.
Preserve file structure and writable directories.
Check for hidden config files and resource folders.

If the app uses external config

Be careful not to miss files that are outside the WAR, such as:

database config files
license files
upload directories
custom properties files
SSL or keystore files if the app uses them locally

In a private Tomcat setup, the application may also rely on service-level settings managed in Plesk. Make sure the deployed app matches the configured service path and context.

Step 6: Update the database connection settings

This is the most important part of moving a Tomcat application and database together. The app must point to the new MySQL host, database name, user, and password.

Common places to update

context.xml JNDI resource definitions
application.properties or application.yml
Hibernate configuration files
Spring datasource configuration
environment variables used by the Tomcat service

Example of a typical JDBC URL

jdbc:mysql://localhost:3306/database_name?useUnicode=true&characterEncoding=UTF-8&serverTimezone=UTC

Adjust the host name if the database is not local. In a managed hosting setup, the MySQL host may be internal or remote depending on the account structure.

Check the JDBC driver

Make sure the application has the correct MySQL JDBC driver for your Java version and database server. A mismatch between the driver and the runtime can cause connection failures even if the credentials are correct.

Step 7: Test the application before switching live traffic

Do not point users to the new host until the app works end to end. Test both the web layer and the database layer.

Functional tests to run

Open the home page.
Log in if the app has authentication.
Submit a form that writes to the database.
Read back the saved record.
Check pages that load dynamic content from MySQL.
Verify uploads, search, and admin functions if relevant.

Log files to inspect

Check the Tomcat logs and the application logs for:

connection refused errors
authentication failures
SQL syntax errors
schema mismatch errors
class loading or driver issues

If your hosting panel includes service controls, restart the Tomcat service after configuration changes so the new connection settings are loaded correctly.

Using My App Server in a Plesk-based hosting setup

If you are deploying on a hosting platform with a custom Java extension such as My App Server, the migration process is usually easier to manage because the Tomcat service, Java version, and application deployment are controlled from one place. This is helpful when you want a separate JVM for a single customer account without handling a full enterprise application server stack.

What this gives you in practice

control over the Tomcat service from the panel
selection of a supported Java version
independent application deployment
simpler restart and service checks
better isolation than a shared generic servlet setup

For Tomcat hosting, JSP hosting, and servlet hosting, this approach is practical because it keeps the database configuration and application deployment close to the service management tools you already use. It is not intended as a replacement for complex enterprise cluster management, but it fits common hosted Java applications very well.

Common problems after migration

The app starts, but cannot connect to MySQL

Check the database host, user, password, and database name. Also confirm that the account has permission to connect from the application host. If the database is remote, verify network access and firewall rules.

The app connects, but data looks wrong

This often points to a character set or collation mismatch. Recheck the database export and import settings, and make sure the JDBC URL uses the correct encoding parameters.

Pages load, but forms fail to save

Possible causes include missing write permissions, schema differences, or a driver incompatibility. Review the application logs and confirm that the tables and columns match the expected version.

The app works in one environment but not the other

Tomcat version differences, Java version differences, and config file paths are common causes. Compare the old and new environments carefully, especially the runtime and library versions.

Static files or uploads disappeared

If the app stores user uploads outside the WAR, copy those folders separately. Many Tomcat apps keep uploads in a writable directory that is not included in the application package.

Best practices for a smooth move

Take a full backup of both the database and application files.
Plan a short maintenance window if the app is active.
Keep the original host available until the new setup is verified.
Use a test URL or temporary domain for validation when possible.
Document every change to the JDBC URL, credentials, and file paths.
Restart the Tomcat service after deployment and config changes.
Test with real data, not only a blank database.

FAQ

Can I move only the Tomcat application without the database?

You can, but if the app depends on MySQL, it usually will not function correctly until the database is also moved or reconnected. Moving both together reduces configuration drift and test time.

Do I need to change the JDBC URL after migration?

Usually yes. If the database host, name, or credentials change, update the JDBC URL or datasource settings in the application or Tomcat configuration.

Is it better to use JNDI or a direct JDBC connection?

For hosted Tomcat setups, JNDI is often cleaner because connection settings can be managed outside the application code. However, the best option depends on how the app was built.

What if my app uses multiple databases?

Export and import each database separately, then update every datasource in the app configuration. Test each connection individually before going live.

Can I change the Java version during migration?

Yes, but do it carefully. Java version changes can expose compatibility issues in libraries or the application code. Test first if the app was built for an older runtime.

How do I know whether Tomcat restarted with the new settings?

Check the service status in the control panel and review the logs after restart. A successful restart should reload the app with the updated database configuration.

Summary

Moving a Tomcat application and its MySQL database together is mostly about order and consistency. First prepare the destination Tomcat environment, then export and import the database, move the application files, update the connection settings, and test everything before switching users to the new host.

In a managed hosting platform with Plesk and a private Tomcat instance, the process is especially practical because you can control the Java service, deploy the app, and update database access in one place. For Java web apps that use MySQL, this approach is the most reliable way to migrate with minimal downtime and fewer surprises.

How to move a Tomcat application and database together