How to migrate a database backed Tomcat application in the UK

If your Tomcat application uses a database, the safest migration approach is to move the application code, the database, and the runtime settings as separate parts. In a hosted Java environment such as Plesk with My App Server, this usually means preparing the new Tomcat instance, copying your WAR or application files, exporting and importing the database, and then updating connection details, JNDI resources, and any environment-specific configuration.

For UK hosting customers, the same migration principles apply whether you are moving from another provider, from a local server, or from a different Tomcat setup. The goal is to keep downtime low, avoid broken database connections, and make sure the application starts cleanly on the new platform.

What you need before you migrate

Before you begin, collect the details of the current application and the new hosting environment. A database-backed Tomcat application often depends on more than just a WAR file, so it is worth checking every part carefully.

Check the application components

The WAR file or exploded application directory
Database name, username, password, host, and port
JDBC driver used by the app
Configuration files such as context.xml, server.xml, application.properties, or *.yml
Uploaded files, user content, and any persistent storage outside the database
Scheduled tasks, background jobs, or cron-style processes
Java version and Tomcat version currently in use

Check the target hosting setup

In a managed hosting control panel such as Plesk, the My App Server extension lets you install and manage your own Tomcat instance or private JVM inside your hosting account. That is useful because you can align the Java version with the application requirements and control the service without needing a separate dedicated server setup.

Confirm which Tomcat version is available or which custom version you plan to upload
Confirm the Java version required by the app
Check your disk usage, memory limits, and file size limits
Check whether the application should run as a shared app, a private JVM, or a custom app server
Confirm the database engine supported by your hosting plan

Plan the migration in the right order

For database-backed Tomcat applications, the order matters. In most cases, the safest sequence is:

Prepare the target Tomcat and Java environment
Take a backup of the current application and database
Export the database from the old host
Copy the application files and configuration
Import the database into the new hosting account
Update connection strings, credentials, and server paths
Test the application before switching traffic
Point DNS or routing to the new service after verification

This sequence reduces the risk of starting the app before its data is ready, which is one of the most common causes of errors during Tomcat migration.

Back up everything first

Never migrate a database-backed Java application without a complete backup. A backup should include both the application files and the database dump, plus any additional assets that are not stored inside the database.

Back up the Tomcat application

Download the WAR file or application directory
Copy any custom configuration files
Save static assets, uploaded documents, and media files
Export any custom libraries from WEB-INF/lib
Record all environment-specific settings

Back up the database

Use the correct export tool for your database type. For example, you might use mysqldump for MySQL or MariaDB, or pg_dump for PostgreSQL. Include the full schema and data. If your application relies on stored procedures, triggers, or routines, make sure those are included too.

Also note the database character set and collation. If these change during migration, you may see broken accents, unexpected sorting, or data corruption in text fields.

Prepare the new Tomcat environment in Plesk

If you are using My App Server in Plesk, the preparation step is usually straightforward. The main task is to create or select the Tomcat instance, verify the Java version, and make sure the service is ready to host your application.

Install or select the app server

Depending on your hosting package, you may have a choice of ready-made Java/Tomcat versions or the option to upload and configure a custom version. Choose the version that matches your application as closely as possible. If the app was built against an older Java runtime, test carefully before changing to a newer one.

Set the application root

Make sure the deploy path in the control panel matches your application structure. In many Tomcat deployments, the app runs from a specific context path and writes logs or temporary files to known directories. If the new path differs from the old one, update any hardcoded references in the app configuration.

Check service control and startup behavior

One advantage of a managed Tomcat setup through Plesk is that you can control the service without SSH-only administration. Before importing the application, start the service once and verify that it runs correctly. If the app server fails to start at this stage, fix the runtime first and then move the application.

Export the database from the old host

The database export should preserve structure, table data, indexes, and any app-specific database objects. If your application uses a schema migration tool such as Flyway or Liquibase, note whether the target environment should receive an empty schema or a full data copy.

Recommended export checks

Use a consistent snapshot if the application is live
Pause writes or maintenance tasks during export if possible
Confirm the dump file opens and contains data
Check for encoding issues in the export file
Verify that the correct schema names were included

If the application is heavily used, coordinate the export time carefully. A live database can change during the migration window, and that can lead to mismatched records unless you freeze writes or perform a final incremental sync.

Import the database into the new hosting account

Once the target database is created, import the dump into the new environment. If the new hosting platform uses a different database hostname, port, or user naming format, update those values before you connect the application.

During import, verify the following

The database and user exist on the target account
The user has the correct privileges for the application
The import completes without errors
The row counts look sensible
Required routines, views, triggers, and sequences were restored

After import, run a quick validation query or check the database from the control panel if available. It is easier to fix an import issue before the application is connected to it.

Move the application files and configuration

The application package is more than just the WAR file in many real-world Tomcat deployments. A database-backed app may include custom configuration outside the archive, external file storage, or hardcoded references to the old server name.

Copy the deployable package

Upload the WAR file to the target Tomcat deployment location, or redeploy it through the control panel if that is supported. If you use an exploded directory instead of a WAR, make sure the directory structure is complete and permissions are correct.

Migrate custom configuration files

Common files that need attention include:

context.xml for data sources and resource definitions
server.xml only if your deployment model requires it
web.xml for servlet and filter mappings
application.properties
application.yml or application.yaml
Environment variable files or external secrets references

If the application uses a JDBC resource defined in Tomcat, verify that the resource name and connection settings are identical on the new host. If the app uses a direct JDBC URL inside its own configuration, update the host, database name, username, and password there instead.

Move uploaded files and persistent data

Many applications store uploaded files on disk rather than inside the database. If you miss these folders, the database may import successfully but the application will still appear incomplete. Common examples include document uploads, avatar images, report exports, cached attachments, or application-generated PDFs.

Update database connection details

After the files are in place, the most important technical task is to point the application at the new database. In a Tomcat setup, this is often done through a JNDI resource, a JDBC configuration file, or framework-specific settings.

Typical settings to review

JDBC URL
Database username
Database password
Driver class name
Connection pool settings
Timeouts and validation queries

If you are moving from one host to another, the JDBC URL usually changes even when the database engine stays the same. For example, the hostname or socket address may be different, and the application must be updated accordingly.

Example migration pattern

If the old configuration used a local or provider-specific database endpoint, replace it with the new host’s connection details and then confirm that the app can establish a session. A failed connection often shows up as startup errors, 500 responses, or login failures shortly after deployment.

Check Java and Tomcat compatibility

Database-backed applications often run perfectly on one Java version and fail on another. That is why the Java and Tomcat versions should be checked before cutover, not after.

Compatibility points to verify

Minimum and maximum supported Java version
Tomcat major version expected by the application
Any deprecated libraries or APIs
Servlet and JSP version requirements
Third-party JDBC driver compatibility

If your application was built for an older Java runtime, test it in staging first. A newer runtime can expose warnings or behavior changes that were not visible on the old platform. In a hosted environment, selecting the correct app server version through My App Server is often the simplest way to keep the migration stable.

Test the application before going live

Testing should happen before DNS changes or production traffic moves. A good practice is to run the app on a temporary URL or staging path, confirm database access, and inspect the logs for warnings.

Functional tests to run

Open the home page and log in
Verify database reads and writes
Create, edit, and delete a test record
Upload a file if the app supports uploads
Confirm email or background tasks if relevant
Check admin pages, reports, and search features

Technical checks to run

Review Tomcat logs for exceptions
Confirm that the datasource initializes correctly
Check memory usage and startup time
Verify that the application context path is correct
Make sure file permissions allow read and write access where needed

If you see errors like connection refused, authentication failed, class not found, or out-of-memory messages, fix them before switching users over to the new host.

Switch DNS or routing after validation

Once the application passes testing, you can move production traffic to the new hosting platform. In many migrations, this is done by updating the domain’s DNS records. Depending on your setup, you may also need to adjust reverse proxy, virtual host, or application URL settings.

Before the final switch

Reduce DNS TTL in advance if possible
Take a final backup of any live database changes
Freeze writes briefly if you need exact data consistency
Confirm the new host is still healthy
Check that SSL certificates and hostnames are ready

After the switch, monitor traffic closely. A Tomcat app that appears stable in tests can still reveal edge cases when real users start hitting all features at once.

Common migration problems and how to fix them

Database connection errors

If the application starts but cannot reach the database, recheck the JDBC URL, credentials, and user permissions. Also confirm that the database service is available and that the firewall or network policy allows the connection.

Missing libraries or class errors

Class loading errors usually mean one of the app’s dependencies was not copied, or the new Tomcat setup uses a different Java version. Check the WEB-INF/lib directory and any shared library locations.

Application starts but data looks incomplete

This usually means that files outside the database were not migrated. Review file storage paths, upload folders, image directories, and cache or document locations.

Encoding or character display problems

If text appears corrupted after import, compare the source and target database encodings. Also check Java-side encoding settings and confirm that the application uses the same character set end to end.

Permission issues

If the app cannot write logs, upload files, or create temporary files, check filesystem permissions in the target hosting account. Managed hosting environments often require specific permissions for the application user.

Best practice checklist for Tomcat database migrations

Back up both files and database before changes
Match Java and Tomcat versions as closely as possible
Confirm database name, user, password, and host
Move uploaded files and custom assets, not just the WAR
Test the app on a staging URL before DNS cutover
Review logs after launch
Keep the old environment available until the new one is stable

FAQ

Can I migrate only the WAR file and skip the database?

Not if the application stores important data in the database. You need both the application package and the database backup, otherwise users may see missing records, failed logins, or broken workflows.

Do I need to change my Tomcat version during migration?

Not necessarily. If the current application works on the existing Java and Tomcat combination, keeping the same version range is often the safest option. Change versions only when needed, and test carefully.

What if my app uses JNDI datasource settings?

Recreate the datasource in the new Tomcat environment and make sure the resource name matches what the application expects. Then verify the database user and JDBC driver configuration.

How do I handle file uploads that are not in the database?

Copy the upload directories separately and confirm that the application points to the correct file path on the new host. Do not assume the database dump includes these files.

Can I use a private JVM or custom Tomcat version for this type of app?

Yes, if the application needs a specific Java or Tomcat setup. In a hosting platform with My App Server, you can often choose from ready-made versions or upload a custom app server configuration when required.

What is the safest way to avoid downtime?

Prepare the target environment first, import and test the database in advance, reduce DNS TTL, and keep the old site active until the new one has passed validation. For active applications, a short maintenance window is still the most reliable approach.

Conclusion

Migrating a database-backed Tomcat application is mainly a matter of careful sequencing: prepare the new Java and Tomcat environment, back up the old system, move the database and files, update connection settings, and test before switching users over. In a Plesk-based hosting setup with My App Server, this process is easier because you can manage the application server, Java version, and deployment settings from one place.

If you treat the database, application files, and runtime configuration as separate migration tasks, you reduce the chance of startup errors and data problems. That approach is usually the most practical way to move a Tomcat application safely on a managed hosting platform.

How to migrate a database-backed Tomcat application in the UK