How to move a Tomcat application and database together in the UK

If you need to move a Tomcat application and its database together, the safest approach is to treat the application, the database schema, the data, and the connection settings as one unit. On a managed hosting platform, this usually means exporting the database, packaging the web application, updating the JDBC configuration, and then testing the app in the target environment before you switch traffic.

In a Tomcat hosting setup with Plesk and a private JVM, this migration is usually straightforward for small and medium Java applications that run as WAR-based deployments, JSP applications, or servlet apps. The main goal is to keep the Tomcat side and the database side in sync, so that the moved app can connect cleanly after deployment without broken URLs, credentials, or schema mismatches.

What you need to move

When a Tomcat application depends on a database, there are usually four parts to migrate:

The web application — commonly a WAR file, exploded application directory, or a custom app package.
The database schema and data — typically MySQL or MariaDB tables, users, and stored objects.
The connection configuration — JDBC URL, database user, password, driver class, pool settings, and environment variables.
The runtime settings — Java version, Tomcat version, memory limits, and any app-specific configuration files.

For hosted Java applications, it is important to move both sides in the correct order. If you deploy the application before the database is ready, the app may fail to start or show errors when it tries to connect. If you move the database first but forget the credentials or JDBC path, the application will not be able to use the new database after migration.

Recommended migration order

A practical migration plan for a hosting account is:

Inventory the current application and database dependencies.
Export the database from the source environment.
Create the target database and user.
Import the data into the target database.
Copy or redeploy the Tomcat application.
Update JDBC settings and any environment-specific config values.
Test connectivity and application startup.
Switch DNS or update the live endpoint only after validation.

This order reduces downtime and makes rollback easier if something is wrong.

Check the Tomcat application dependencies first

Before moving anything, identify how the application stores its database settings. In Tomcat-hosted apps, the connection details may be found in one or more of these places:

application.properties or application.yml
context.xml
server.xml
environment variables set in the hosting control panel
JNDI resource definitions
custom configuration files inside the WAR or application directory

Also confirm the database engine version and character set used by the app. If the current system uses MySQL with a specific collation, you should aim to match that in the new environment unless you have a clear reason to change it. Small differences in encoding can cause broken accented characters, unexpected sorting, or failed imports.

If you are using a managed hosting platform with a private JVM and My App Server, also check which Java version and Tomcat version the app was built for. A database migration can fail indirectly if the app itself is not compatible with the runtime after the move.

Export the MySQL database safely

For most hosted applications, the easiest way to move the database is to export it as an SQL dump. You can do this from phpMyAdmin, the hosting control panel, or the command line depending on access level.

What to include in the export

All tables used by the application
Data rows, not just structure
Views, triggers, and routines if the app uses them
Character set and collation information

If you have access to mysqldump, a typical export should preserve structure and data together. If the database is small, you can also use a control panel export tool. For larger databases, command-line export is usually more reliable because it is less likely to time out.

Before importing into the target system, keep a copy of the original dump file. This gives you a fallback if the new environment needs troubleshooting.

Common export mistakes

Exporting only the table structure and forgetting the data
Omitting routines or triggers used by the app
Using a different collation from the source database
Compressing or editing the dump in a way that changes line endings or encoding

Create the target database and user

On the new hosting account or server, create the destination database first. Then create a dedicated database user for the application. In a Tomcat hosting environment, it is best practice to avoid using the database root account in the app configuration.

Use a strong password and grant only the permissions required by the application. For most web apps, this means standard read and write access to the application database, but not global administrative privileges.

Suggested permissions

SELECT
INSERT
UPDATE
DELETE
CREATE and ALTER if the app performs schema updates
INDEX and REFERENCES if required by the schema

If the application is not supposed to change its own schema after deployment, you can limit permissions more tightly. This is often preferable in managed hosting setups.

Import the database into the new environment

After the database and user are ready, import the SQL dump into the new MySQL database. If the dump came from another version or a different encoding, check the import log for warnings.

After import, verify the following:

The number of tables matches the source database
Key tables contain the expected number of rows
Auto-increment values are preserved
Foreign key constraints are valid
No data was truncated during import

If the app depends on a database name embedded in configuration or code, confirm whether the name changed in the new environment. Some applications store the database name in more than one place, so it is worth checking carefully.

Move the Tomcat application files

Once the database is ready, move the application package to the target Tomcat environment. On a Plesk-based hosting platform with My App Server, this may mean deploying a WAR file or uploading the application through the control panel interface. If you are using a custom Tomcat version, make sure the runtime paths and service settings are correct before starting the app.

Typical application files to copy

WAR file or exploded application directory
Configuration files outside the WAR
Uploaded assets, if the app stores files locally
Custom JDBC driver files if they are not bundled in the app
Any environment-specific properties files

Be careful with local file storage. If the application stores user uploads, images, or generated documents on disk, those files may also need to be copied. The database alone is often not enough.

Update the JDBC connection settings

After the database import, the most important step is to update the JDBC connection settings so the app points to the new database host, name, username, and password.

A standard JDBC MySQL connection string usually includes:

Database host
Port number
Database name
User name
Password
Optional parameters such as SSL mode, timezone, or Unicode settings

For example, if the app previously connected to a local database and now needs to use a hosted database service within the same account, update the host value accordingly. If the app uses JNDI, adjust the resource definition in Tomcat rather than hardcoding the values into the application.

Things to verify in the JDBC URL

Correct hostname or service name
Correct port, often 3306 for MySQL
Correct database name
Correct character encoding parameters
SSL requirements if the platform enforces them
Timezone settings if the application is time-sensitive

In hosting environments where the Tomcat service runs in a private JVM, connection failures can also happen if the JDBC driver is missing from the expected classpath. If the driver is bundled with the application, confirm that it is still included after migration. If it is provided separately, verify that the version is compatible with the Java runtime and MySQL server version.

Check Tomcat and My App Server settings

On a hosting platform with My App Server, the application may rely on the selected Java version, Tomcat instance, and service control settings. If the database move is part of a broader application move, confirm these runtime values as well.

Useful checks include:

Selected Java version matches the application requirements
Tomcat version supports the deployed app and libraries
Service is running after deployment
Memory settings are appropriate for the app size
Startup logs do not show classpath or JDBC errors

If your app was developed for a specific Java release, do not assume it will behave identically on a different runtime. Even a database migration can expose compatibility issues if the application was already close to the limits of its Java or Tomcat configuration.

Test the application before going live

Testing is the step that prevents most post-migration issues. Before switching production traffic, verify that the application starts correctly and can connect to the imported database.

Basic test checklist

Application loads without a 500 error
Login works if the app has authentication
Database reads and writes work
Forms submit successfully
Search, filtering, and reporting features return expected results
File uploads or downloads still work if supported by the app
No unexpected encoding problems appear in stored or displayed data

It is also a good idea to review the Tomcat logs and application logs immediately after start-up. Connection pool errors, permission issues, or schema mismatches usually appear there first.

Common problems when moving Tomcat and MySQL together

Database connection fails after deployment

This usually means one of the following is wrong:

Wrong database name
Wrong user or password
Database user lacks permissions
Incorrect host or port in the JDBC URL
Missing JDBC driver

Application starts but data looks incorrect

This often points to character set or collation differences. Check whether the source database used UTF-8 or another encoding, and verify that the target database and connection string match it.

Some pages work but others fail

This can happen when part of the app uses the database and another part depends on local files, external services, or environment variables that were not moved. Review the full application configuration, not just the database settings.

Old data is missing after the import

The dump may have been incomplete, or the import may have stopped early due to an error. Compare row counts between the source and target databases and inspect the import log for failed statements.

Good practice for hosted Java applications

When moving a Tomcat application and database in a managed hosting environment, the most reliable approach is to keep configuration simple and documented. A clear setup makes future migrations easier and reduces downtime.

Store database settings in one known place
Keep a copy of the current JDBC configuration
Use separate users for application access
Export database backups regularly
Document Java, Tomcat, and driver versions
Test a migration on a staging copy first if possible

If your hosting account uses My App Server, it is also useful to record which version of Tomcat is installed, how the service is controlled in Plesk, and whether the app relies on a custom Java runtime. These details reduce the risk of surprises when you move the app again later.

Step-by-step summary

If you need a short operational checklist, use this sequence:

Identify the database name, app package, and connection settings.
Export the database from the source environment.
Create the target database and user.
Import the SQL dump.
Upload or deploy the Tomcat application.
Update the JDBC URL, user, and password.
Check Java, Tomcat, and driver compatibility.
Test login, forms, and database-driven pages.
Review logs for errors.
Only then switch the live site.

FAQ

Can I move the Tomcat app and database separately?

Yes, but it is usually better to treat them as one migration. The app depends on the database schema, data, and credentials, so moving both together reduces the chance of mismatch.

Do I need to change the JDBC connection string after migration?

Usually yes. Even if the app code stays the same, the database host, name, user, or password often changes in the new environment.

What if my app uses JNDI instead of a hardcoded database URL?

Then update the JNDI resource definition in Tomcat or the hosting control panel rather than editing the application code. This is often cleaner for hosted environments.

Should I move stored files as well as the database?

If the application stores uploads, images, documents, or generated files on disk, yes. The database may contain the references, but the actual files may live outside it.

How do I check if the migration worked?

Start the application, browse the main pages, test database reads and writes, and inspect the logs. If the app behaves normally and no connection errors appear, the migration is usually successful.

What is the main risk when moving a Tomcat application with MySQL?

The most common risks are incomplete database export, incorrect JDBC settings, and overlooked app files or environment variables. Character set mismatches are also a frequent issue.

Conclusion

Moving a Tomcat application and database together is mostly about careful sequencing and configuration control. Export the MySQL data, recreate the database and user, deploy the application, update the JDBC details, and test everything before going live. In a Plesk-based hosting setup with My App Server, this approach fits well because you can manage Java, Tomcat, and service settings in one place while keeping the application isolated in its own JVM.

For hosted Java applications, the best results come from matching the runtime, database settings, and application configuration as closely as possible to the original environment. That way, the migration stays predictable, downtime stays low, and the application continues to work after the move.

How to move a Tomcat application and database together in the UK