Migrating a database-backed Java application is usually straightforward when you plan the file move, database move, and application configuration together. In a hosting environment such as Plesk with a Java hosting extension like My App Server, the main goal is to move your WAR, JSP, servlet resources, and database data without breaking the connection between Tomcat, the JVM, and your data source.
If your application stores data in MySQL, MariaDB, PostgreSQL, or another database supported by your hosting plan, the migration typically involves five parts: export the database, upload the application files, update connection settings, deploy the app on the target server, and test the application end to end. The exact steps depend on whether your app uses a plain JDBC connection, a connection pool, JPA/Hibernate, or a framework such as Spring.
What needs to be migrated
Before you start, identify every component your Java application depends on. A database-backed application is rarely just one WAR file and one database. In practice, you may need to move:
- the application package, such as a WAR file or exploded web application directory;
- configuration files, including environment properties, XML files, and secrets references;
- database schema and data;
- file uploads, generated documents, or cache directories if your application stores them locally;
- scheduled jobs, background task settings, and mail configuration if they are part of the application runtime;
- Java and Tomcat version settings if the source and destination environments differ.
In a managed hosting control panel, this often means separating what is deployed in Tomcat from what is stored outside the application directory. This is important because a clean migration should not overwrite uploaded user files or runtime-generated content unless you intentionally want to reset them.
Check compatibility before moving anything
The most common migration problems are caused by version differences. Check the following before copying files or importing the database:
- Java version — confirm whether the application was built for Java 8, 11, 17, or another runtime.
- Tomcat version — some applications rely on older servlet or JSP behaviour.
- Database engine and version — verify whether the target hosting plan uses the same database type and compatible version.
- Character set and collation — mismatch can cause broken accents, symbols, or search results.
- File paths and context paths — hardcoded paths may fail after migration.
- External integrations — SMTP, payment gateways, APIs, and SSO endpoints may need new allowlists or credentials.
If you are using My App Server in Plesk, it is usually best to select the Java version and Tomcat version that match your application requirements before importing the database and deploying the WAR. That reduces the number of variables you need to troubleshoot later.
Step 1: Create a backup of the source application
Always create a full backup before the migration. Even a simple database import can fail if the dump is incomplete or the target server uses stricter SQL settings.
Back up the database
Export the full database, including schema and data. If the application uses multiple databases, export each one separately and label the files clearly.
- Use a consistent dump format, such as SQL.
- Include stored procedures, views, triggers, and events if the application uses them.
- Make sure the dump uses the correct character encoding, ideally UTF-8 unless the application requires something else.
- Save the dump in a secure location.
Back up the application files
Archive the application directory, including configuration files and any additional assets outside the WAR file. If the app stores uploaded files, downloaded reports, or image assets on disk, back up those directories separately.
Useful items to preserve include:
- WAR file or exploded deployment directory;
- application.properties, XML config, or .env-style files;
- custom libraries placed in WEB-INF/lib;
- log files if they may help with debugging after migration;
- cron or scheduled task definitions if the application uses them.
Step 2: Prepare the target hosting environment
On the destination account, make sure the environment is ready before you upload anything. In a Plesk-based Java hosting setup, this means confirming the service settings for your app server, database access, and domain configuration.
Set up the Java runtime and Tomcat
If your hosting plan provides My App Server, install or activate the required Java/Tomcat version first. Choose the runtime that your application was built for whenever possible. If you need a custom app server version, make sure it is supported by the hosting account and correctly registered in the control panel.
Check that:
- the application server is running;
- the selected Java version matches the application requirements;
- the domain or subdomain is assigned to the correct Java service;
- the document root or deployment path is set correctly;
- service control is available from the panel so you can restart after deployment.
Create the destination database and user
Create a new database on the target server and assign a database user with the minimum permissions the application needs. For most web applications, this means read and write access to the application database, but not global administrative privileges.
- Use the same database engine if possible.
- Match the database name or record the new name carefully.
- Use a strong password and keep it in a secure place.
- Confirm the database host and port if they differ from the source environment.
Step 3: Import the database
Import the dump into the new database before deploying the application, unless your app requires an empty schema to start. In most cases, importing first helps you verify that the database is valid and accessible.
Import from SQL dump
Use the database tools available in your hosting control panel or a command-line method if your plan supports it. After the import, check for errors such as:
- unsupported SQL syntax;
- missing tables or routines;
- permission errors;
- encoding issues;
- foreign key constraint failures.
If the source and target database versions differ, review the dump for deprecated features. Older applications may rely on SQL syntax or storage engine settings that need adjustment.
Verify the schema
After the import, confirm that the schema is complete. Check the table count, user count, and any key lookup tables the app relies on. If the application uses migration tools such as Flyway or Liquibase, confirm whether the schema should be imported fully or whether the app will create missing changes on first startup.
Step 4: Upload the application files
Now move the application code to the new host. For a Java web application, this usually means uploading the WAR file or the exploded application directory to the location expected by the app server. In a hosted Tomcat environment, deployment is often easier when the application is packaged consistently.
What to upload
- the latest WAR build from your CI or build system;
- configuration files that are not stored in the database;
- static assets and themes if they are bundled separately;
- external JARs or custom modules if they are not already in the deployment package.
What not to overwrite blindly
Avoid replacing directories that may contain runtime data unless you intend to reset them. This is especially important for:
- user-uploaded files;
- generated exports or reports;
- temp directories used by the application;
- log directories;
- cache folders.
If your application stores uploads in a local path, consider moving that content separately and updating the path in the configuration. In managed hosting, it is often better to store persistent data outside the webroot or in a clearly defined application data directory.
Step 5: Update database connection settings
This is the most important application-level change in a database migration. Your Java app must point to the new database host, name, username, and password. These values may be defined in a properties file, XML file, environment variable, or application-specific secret store.
Common configuration locations
- application.properties or application.yml in Spring-based apps;
- JDBC configuration in XML files;
- context.xml or server.xml for Tomcat data sources;
- custom config files under WEB-INF/classes;
- environment variables loaded by the application at startup.
Typical settings to review
- JDBC URL;
- database username and password;
- driver class name;
- connection pool settings;
- schema name or default catalog;
- SSL options for database connections;
- timezone settings if the app stores time-sensitive data.
Example issues to look for:
- the hostname still points to the old server;
- the database name changed during import;
- the app expects localhost but the hosting database is on another host;
- SSL is required on the new server, but the old config does not enable it;
- the application uses hardcoded credentials in a file that was not updated.
Step 6: Adjust paths, permissions, and runtime storage
Database-backed Java applications often depend on writable directories for uploads, temporary files, and logs. After migration, confirm that the application can write to every path it needs.
File permissions
Make sure the account user has permission to read the deployment files and write to runtime directories. In shared hosting, the application should not require system-level privileges. If the app fails to start, permission errors are one of the first things to check.
Absolute and relative paths
Review any file paths in the configuration. A path that worked on the source server may not exist on the new one. Replace fixed local paths with portable application-relative paths where possible. If your app stores data outside the deployment directory, create the target directory before going live.
Temporary and cache locations
Tomcat and Java applications may create temp files during processing. Confirm that the temp directory exists and has sufficient space. If your app writes large uploads or report exports, verify disk usage limits as well.
Step 7: Test the application before switching traffic
Testing should happen before you point the live domain to the new deployment or before you announce the migration complete. The goal is to verify both the web layer and the database layer.
Functional checks
- load the home page and key internal pages;
- log in with a test account;
- create, edit, and delete a record;
- search data and verify results;
- upload a file if the app supports uploads;
- send a test email if the app includes notifications;
- run any admin or batch function the app depends on.
Technical checks
- review Tomcat logs for startup errors;
- check database connectivity errors;
- verify the application reads the expected JDBC URL;
- confirm that static assets load correctly;
- test character encoding with special characters;
- confirm that timestamps are saved in the correct timezone.
In a Plesk environment, service control is useful here because you can restart the Java service after changes and quickly inspect whether the app starts cleanly. If the app fails to deploy, check the app server logs and the deployment output from the control panel.
Step 8: Switch DNS or final production routing
Once the new application is stable, switch traffic to the new host if required. If the migration involves a new domain mapping or subdomain, update DNS or the relevant routing settings only after testing.
Keep the old environment available for a short overlap period if possible. That makes rollback easier if you discover a missing config value or a data mismatch after launch.
Common problems during Java database migration
Application starts but cannot connect to the database
This usually means the JDBC URL, username, or password is wrong, or the database user does not have the correct privileges. Double-check the new database host and credentials. Also verify whether the new database requires SSL or a different port.
Old data is missing after the move
Check whether you imported the full dump and whether the application reads from the correct schema. Sometimes the app creates a new empty schema because the configuration still points to the old database name.
Special characters appear broken
This is often an encoding issue. Confirm UTF-8 is used consistently across the database dump, connection string, and application settings. If needed, review the database collation and table definitions.
The app deploys, but file uploads disappear
Uploaded files may have been stored on the old server in a local directory that was not copied. Move the upload directory and update the path in the application config.
Tomcat starts, but the application returns errors
Check framework dependencies, Java compatibility, and runtime logs. A WAR built for a newer Java version may not run on an older JVM. Missing libraries or incompatible servlet APIs can also cause startup failures.
Best practices for a cleaner migration
- Use the same Java version on the destination whenever possible.
- Keep database credentials outside version-controlled source code if your application supports that.
- Separate runtime data from deployment files.
- Test on a staging subdomain before switching production traffic.
- Document every setting you changed during migration.
- Keep a rollback copy of the old database and application package.
If you manage Java hosting through My App Server in Plesk, these practices are especially helpful because they make future updates easier. A clear split between the WAR, the database, and runtime files reduces the chance of breaking the app during redeployments or version changes.
FAQ
Can I migrate a Java application without changing the code?
Yes, if the source and destination environments are compatible and the app does not rely on hardcoded paths or server-specific settings. In many cases, only the database connection string and file locations need to change.
Should I import the database before or after uploading the WAR?
Usually the safest order is to prepare the target environment, import the database, then upload and configure the application. That way, when the app starts, the data source is already available.
What if my application uses a connection pool?
Review the pool settings carefully after migration. Parameters such as max connections, validation query, and timeout values may behave differently on the new host. Start with conservative values and adjust after testing.
Do I need a dedicated enterprise Java server for this?
Not necessarily. For many small and medium web applications, a hosted Tomcat and private JVM setup is enough. The key is that the environment matches the application requirements and allows you to control Java, deployment, and service restart from the panel.
How do I know if the migration is complete?
The migration is complete when the application loads, data is available, users can perform core actions, uploads work, logs show no critical errors, and the new environment behaves as expected under normal use.
Conclusion
A database-backed Java application migration is mostly a coordination task: move the data, move the deployment package, update the configuration, and verify the runtime. In a hosting control panel environment with Tomcat and a managed Java service, the process is usually simpler because Java version selection, service control, and deployment are available in one place.
When you treat the database, application files, and runtime settings as separate migration steps, troubleshooting becomes much easier. That is the safest approach whether you are moving a WAR-based application, a servlet app, or a JSP site backed by a relational database.