Moving a database-backed Java application is usually straightforward if you treat the code, configuration, database, and runtime as separate parts of the migration. For a typical Tomcat-based application, the safest approach is to export the database, move the application files, update the JDBC settings, and then verify that the app starts cleanly under the new Java runtime. If you are using a hosting control panel such as Plesk with a Java hosting extension like My App Server, you can usually complete most of the work from the panel and only use SSH or file manager for the parts that need manual adjustment.
This guide explains how to migrate a database-backed Java application in a practical way for UK hosting customers who are moving from another provider or from an older server setup. It focuses on common Java web applications running on Apache Tomcat, JSP, servlets, or a private JVM, with special attention to database connections, build output, and configuration files.
What you need before you start
Before you move anything, make sure you know how the application is structured. A database-backed Java app usually includes:
- Application build output such as a WAR file, exploded webapp directory, or compiled classes.
- Configuration files for database access, mail, external APIs, or environment-specific settings.
- The database itself, often MySQL, MariaDB, PostgreSQL, or another JDBC-supported engine.
- Uploads, attachments, generated documents, or other runtime files stored outside the database.
- Tomcat or JVM settings such as memory allocation, Java version, or context configuration.
If your hosting account includes My App Server, you can use it to install or manage a private Tomcat instance, choose a Java version, and control the service from Plesk. That is especially useful when your application depends on a specific Java release or needs a clean runtime environment during migration.
Identify what must move and what can stay behind
One of the most common migration mistakes is copying only the web application and forgetting the data layer. A complete migration usually includes both application state and runtime dependencies.
Typical items to move
- WAR file or source build output if the application is deployed as a packaged web archive.
- Exploded application directory if the app runs from an unpacked Tomcat webapp structure.
- Database dump exported from the old server or managed database service.
- Configuration files such as properties, XML, YAML, or .env-style files.
- Uploaded files and media stored on disk rather than in the database.
- SSL or endpoint references if the app talks to internal services or payment gateways.
Typical items you do not need to move as-is
- Old JVM binaries, if your new hosting account provides a supported Java version.
- Server-specific log files, unless you need them for troubleshooting.
- Temporary files created by Tomcat, build tools, or the application cache.
On a managed hosting platform, the goal is usually to recreate the runtime cleanly rather than clone the full old server. That helps avoid hidden dependencies and stale configuration.
Export the database from the old server
The database is often the most sensitive part of the migration. If the schema, collation, or character encoding changes during transfer, the application may still start but behave incorrectly.
Recommended export approach
Use the most reliable export method available for your database engine. For MySQL or MariaDB, a logical dump is usually the simplest option. For PostgreSQL, use a custom-format or plain SQL export depending on the restore method you plan to use.
- Make sure the database is in a consistent state before export.
- Stop scheduled jobs or background writers if they could change data during the dump.
- Use UTF-8 or the character set already used by the application.
- Check that stored procedures, views, and triggers are included if the app depends on them.
If the application is active while you export it, consider a short maintenance window to prevent data loss. For small and medium Java applications, this is usually enough to avoid inconsistencies.
What to check in the database dump
- Table names and column types match the application expectations.
- Auto-increment values or sequences are preserved.
- Collation and character set are correct for UK user data, email content, and special characters.
- Any database-specific SQL features used by the app are supported on the new hosting stack.
Create the target database and user
Before importing data, create a fresh database on the new hosting account. In a Plesk-based environment, this is usually done from the panel, where you can also assign a dedicated database user and password.
Use a separate database user for the application instead of a shared administrative account. That is better for security and makes troubleshooting easier.
Best practice for database credentials
- Use a strong random password.
- Grant only the permissions the application requires.
- Keep a record of the database name, username, host, and port.
- Use the same database engine and major version where possible.
If the application has hardcoded connection details, plan to update those after import. Many Java applications store database settings in a properties file, a Spring config file, or a Tomcat context resource definition.
Import the database into the new hosting account
Once the database exists, import the dump into the new environment. For larger databases, use a method that is stable under the resource limits of shared hosting.
Import tips
- Import into an empty database to avoid duplicate objects.
- Confirm that the character encoding matches the export.
- Watch for syntax differences between database versions.
- Verify that all tables, data, and indexes are present after the restore.
If the database is large, split the import into smaller chunks when needed. That can reduce timeouts and make the migration easier to recover if something fails midway.
Move the application files
The application files usually come in one of three forms: a WAR file, an exploded web application directory, or a project build output from Maven, Gradle, or another build system. What you move depends on how the app is deployed.
If you deploy a WAR file
Upload the WAR file to the application location supported by your hosting setup, then deploy it through Tomcat or the control panel. On a My App Server setup, this is often the simplest method because it keeps the deployment clean and repeatable.
If you deploy an exploded directory
Copy the full webapp folder, including web.xml, JSP files, static assets, classes, and any libraries in WEB-INF/lib. Make sure no build artifacts are left out. A partial copy can lead to runtime class loading errors or missing pages.
If the application is built from source
Rebuild it on the new server if your deployment process requires environment-specific compilation. This is common when the app depends on a specific Java version or expects a certain set of libraries at build time. In that case, confirm that the new Java hosting environment matches the runtime your application was designed for.
Check file permissions
After copying files, verify ownership and permissions. The Tomcat process must be able to read the application files and, if necessary, write to upload directories or cache locations. Avoid overly broad permissions; only writable paths should be writable.
Update database connection settings
After the files are in place, update the application so it points to the new database. This step is where many migrations fail because the old connection string was hardcoded in more than one file.
Where to look for connection details
- application.properties or application.yml
- database.properties
- Spring XML or Java config classes
- Tomcat context.xml or META-INF/context.xml
- external environment files used by the startup script
Check for the following values:
- JDBC URL
- Database username
- Database password
- Database host and port
- Schema name, if used separately
If you are using My App Server, you may be able to manage the service and runtime settings through Plesk while keeping the application-specific config files in the webroot or app directory. That separation helps you update the app without changing the whole server configuration.
Review Java version and Tomcat compatibility
A database-backed Java application can migrate cleanly and still fail if it runs on the wrong Java version. This is especially important when moving between providers or from an older VPS to a managed Java hosting account.
Check compatibility before launch
- Confirm the Java version required by the application.
- Check whether the app uses deprecated APIs removed in newer versions.
- Make sure the Tomcat version supports the app’s Servlet and JSP requirements.
- Verify third-party libraries are compatible with the chosen runtime.
With a private JVM setup, you can often select a Java version that matches the application more closely. That is useful for legacy applications that are not ready for the newest Java release, as long as the version remains supported by your hosting environment.
Move uploads, media, and runtime data
Many Java applications store user uploads, generated PDFs, export files, or image assets outside the database. These files are easy to overlook because the application may still start without them, but features will be incomplete or broken.
Common locations for runtime files
- upload directories under the webapp path
- shared data folders outside the deployment directory
- temporary document storage paths
- custom cache directories
- folders referenced by absolute paths in config files
When moving these files, preserve the directory structure if the application expects exact paths. If the path changes, update the relevant configuration and verify that Tomcat can access the new location.
Adjust environment-specific settings
Migration is a good time to separate settings that should not be embedded in the code. For example, hostnames, database credentials, API keys, and file paths should ideally live in configuration files or environment variables rather than in compiled classes.
Settings that often need review
- SMTP server details for outgoing email
- Base URL and callback URLs
- File storage directories
- Timezone and locale settings
- External API endpoints
- License or integration keys
If the old server used a different timezone, some applications will show date or report mismatches after migration. Set the expected timezone in the app or the JVM settings if needed.
Deploy and start the application
After the database, files, and settings are in place, deploy the application and start the Tomcat service. In a Plesk-managed Java hosting setup, this may involve using the My App Server control to start, stop, or restart the service after deployment.
Deployment checklist
- Application files uploaded successfully.
- Database restored and connection details updated.
- Java version and Tomcat version are correct.
- Required directories exist and are writable.
- All external endpoints and credentials are valid.
After startup, watch the application logs closely. The most useful migration errors are usually visible immediately: missing classes, bad JDBC settings, invalid permissions, unsupported Java features, or schema mismatches.
Test the migrated application
A successful start is not the same as a successful migration. Test the full user journey, especially any feature that reads or writes the database.
Functional test checklist
- Log in with a test account.
- Create, update, and delete a record.
- Upload a file and confirm it can be retrieved.
- Send a test email if the application uses SMTP.
- Run a report or search query that depends on database joins.
- Check pages that use JSTL, custom tags, or servlet filters.
Also check for subtle issues such as broken links, mixed content, incorrect character display, and unexpected redirects. These often appear only after the site is moved to the new hosting account.
Common migration problems and how to fix them
Database connection refused
This usually means the JDBC URL, port, hostname, or firewall-related assumption is wrong. Verify the database host provided by the new environment and confirm the database user exists with the correct password.
Application starts but data is missing
Usually caused by importing the wrong database, pointing to an empty schema, or forgetting to move file-based data such as uploads or documents.
ClassNotFoundException or NoClassDefFoundError
The app is missing a library from WEB-INF/lib or expects a different build output. Recheck the deployment package and compare it with the original application structure.
Unsupported major.minor version or Java compatibility error
The application was compiled for a different Java release than the one currently selected. Adjust the Java version in the hosting control panel if possible, or rebuild the application for the available runtime.
Permission denied on uploads or logs
The Tomcat service cannot write to a directory. Fix ownership and permissions for only the paths that need write access.
Encoding problems with special characters
This often points to a mismatch between database encoding, JDBC settings, and the application’s form or view encoding. Confirm that all layers use the same character set, usually UTF-8.
Migration workflow for a managed hosting control panel
If your hosting account includes a control panel such as Plesk with My App Server, a practical migration workflow is:
- Prepare the new domain or subscription in the panel.
- Create the target database and database user.
- Install or select the required Java/Tomcat version.
- Upload the WAR file or application files.
- Import the database dump.
- Update the connection settings and file paths.
- Start or restart the service.
- Review logs and run functional tests.
This approach keeps the migration organized and makes it easier to roll back specific parts if needed.
FAQ
Can I migrate only the WAR file and not the database?
You can if the application is stateless, but most database-backed Java applications will not work correctly without the database. If the app stores user accounts, orders, content, or settings, migrate the database as well.
Do I need SSH access to migrate a Java application?
Not always. For smaller deployments, you may be able to upload files and manage the database through the control panel. SSH is helpful for larger imports, scripted deployments, or troubleshooting, but it is not always required.
Should I rebuild the app on the new server?
If the source code is available and the build process is simple, rebuilding can be a clean option. If you already have a trusted WAR file, deploying that package is often faster and reduces build differences.
What if the application needs an older Java version?
Check whether your hosting plan lets you choose a compatible Java runtime through the panel. If the application depends on an older version, test carefully to make sure the selected runtime still supports the app without security or compatibility issues.
How do I know if the migration is complete?
When the application starts, connects to the database, serves pages correctly, handles writes, and passes your business-critical tests, the migration is effectively complete. Always confirm with real data and not only with the homepage.
Conclusion
Migrating a database-backed Java application is mostly a matter of moving the right parts in the right order: database, files, configuration, and runtime. In a Plesk-based Java hosting environment with My App Server, you can manage the Tomcat service, select a Java version, and deploy the application in a controlled way without rebuilding the whole server setup. That makes the migration process easier for JSP, servlet, and Tomcat applications that need a private JVM but do not require a complex enterprise platform.
If you follow a structured approach, validate the database connection, and test the app after deployment, you can move the application with minimal downtime and avoid the most common post-migration issues.