When you move a Java application, the database should be treated as part of the same deployment, not as a separate afterthought. A Java web app may start normally after upload, but if the database is missing, renamed, or pointed to the wrong host, the application will usually fail at login, show empty pages, or return connection errors.
In a hosting environment with Plesk and a Java hosting extension such as My App Server, the safest approach is to move the application files, recreate or restore the database, update the connection settings, and then test the full application path before switching traffic. This applies whether you are running a WAR file on Apache Tomcat, a JSP-based site, a servlet application, or a small private JVM application hosted on a shared account.
What “move a Java application and database together” means
Moving the application and database together means keeping the code, configuration, and data in sync during migration. For Java applications, this usually includes:
- the application package, such as a WAR file or expanded web application
- the Java version or Tomcat version used by the app
- database schema and data, usually MySQL
- JDBC connection details in properties files, XML config, or environment variables
- any upload folders, cache directories, or runtime files used by the app
If only the application code is moved and the database is left behind, the application may start but not function correctly. If the database is restored but the connection string still points to the old server, the app will continue to fail until the configuration is changed.
Typical migration scenarios for Java hosting
Moving within the same hosting platform
This is the easiest case. For example, you may move a Tomcat app to another subscription or another Plesk domain while staying on the same hosting platform. In this scenario, the database may still be on the same MySQL service, but you will usually need to update:
- database name
- database user
- password
- host value, if the app previously used localhost or a named internal host
- application context path or server port
Moving to a different server
If the app is moved to a different server or environment, the database should be exported from the old server and imported into the new one. You then update the JDBC URL and any credentials in the Java application configuration. This is the most common migration pattern for hosted Java applications.
Moving from one stack to another
Sometimes the application is moved from one Tomcat version to another, or from a manually managed JVM to the My App Server environment in Plesk. In that case, the database may stay the same, but the app may need compatibility checks for Java version, servlet API, JDBC driver version, and connection pool settings.
Before you move: check application and database requirements
Before starting the migration, collect the key technical details. This avoids downtime and reduces the chance of a failed first start.
- Java version required by the application
- Tomcat version or servlet container used
- MySQL version used by the current database
- database size and approximate number of tables
- current JDBC driver name and version
- location of application config files
- whether the app uses one database or several
- special runtime files such as uploads, generated PDFs, or temp files
In a managed hosting panel, it is often useful to confirm the current Java service settings before migration. If you use My App Server, note the active service, its installed Java version, and any custom Tomcat setup. Keeping these values aligned helps prevent startup errors after the move.
Recommended migration order
The safest sequence is: back up first, export the database, move the application, import the database, update connection settings, test, and then switch DNS or traffic.
1. Create full backups
Make a copy of everything before changing anything. Back up:
- the Java application files
- the database dump
- configuration files containing secrets or connection strings
- uploaded content and generated assets
If you use Plesk, you can often create a subscription backup or download a backup archive. For the database, use an SQL dump so that schema and data can be restored cleanly.
2. Export the database from the old environment
For MySQL, export the database as a SQL file. This preserves the structure and content and makes it easier to restore on the new hosting account or server.
Useful export options usually include:
- including routines or triggers if the application uses them
- using UTF-8 encoding if the app stores multilingual content
- locking tables only if needed, to avoid inconsistent data during export
- compressing the dump for large databases
If the application is busy, consider placing it in maintenance mode or freezing writes during the final export. This avoids data drift between the moment of export and the moment of import.
3. Upload the Java application to the new hosting environment
Deploy the application package to the new Java hosting account. In a Tomcat-based setup, this may mean uploading the WAR file through the control panel or deploying it in the application directory used by the service.
With My App Server, you can typically manage the Java service from Plesk, choose the correct runtime, and install or switch Tomcat versions where supported. If your app depends on a specific Java release, match it as closely as possible to the old environment.
4. Create the target database and user
Before importing data, create the database on the new account and assign a dedicated database user. Use a strong password and grant only the permissions the application needs, usually the standard privileges required for application access.
Keep the following details together for the configuration step:
- database name
- database username
- password
- database host
- port, if not default
5. Import the SQL dump
Import the database dump into the new MySQL database. After import, check that the table count, row count, and basic data match expectations. If the application has admin data, user records, or product/catalog entries, verify those first.
Common import issues include:
- character set mismatches
- foreign key errors caused by incomplete dumps
- large file timeouts during import
- missing routines, views, or triggers
Update the Java database connection settings
This is the most important step. A Java application usually stores database connection details in one of these places:
- application.properties or application.yml
- persistence.xml
- spring datasource settings
- JNDI configuration in Tomcat
- custom XML or .properties files
- environment variables used by the JVM or startup script
What to change
Update the JDBC configuration so the app points to the new database. In most cases you will need to change:
- JDBC URL
- database host
- database name
- username
- password
For example, if the old application pointed to a different server, replace that host with the new MySQL host provided by the hosting platform. If the database is hosted locally on the same server, confirm whether the application should use localhost or the internal host name required by the control panel setup.
Tomcat and JNDI users
If the application uses Tomcat datasource configuration, verify the resource definition as well as the app-level lookup name. A mismatch between the JNDI resource name in Tomcat and the lookup name in the application is a common cause of connection failures after migration.
Check:
- context.xml or server.xml resource settings
- JNDI name used by the application
- driver class name
- connection pool limits
- timeout values
Spring-based applications
For Spring Boot or Spring-based applications, review datasource settings and profile-specific configuration files. If the old environment used a local config file and the new one uses environment variables, ensure the values are still loaded correctly at startup.
Keep runtime files and uploads in sync
A Java web application often stores more than database rows. User uploads, generated documents, cached images, and temporary export files may also be required for the site to function properly after migration.
Check whether the app stores files in:
- the web application directory
- a separate uploads folder
- a path outside the application root
- a shared file system directory
If the app expects files in a specific folder, recreate the same path or update the application configuration to the new path. A database migration alone will not restore uploaded images or attachments unless those files are also copied.
How to test the moved application
After the application and database are migrated, test the service before you change DNS or direct real users to the new environment. A careful test can reveal problems early.
Functional checks
- open the home page
- log in with a test account
- create or edit a record
- verify reads and writes to the database
- check pages that use dynamic content
- confirm file upload and download functions
Technical checks
- review Tomcat or JVM logs for startup errors
- check connection pool warnings
- look for SQL exceptions
- verify the active Java version
- confirm that the app listens on the expected port or context path
If you are using My App Server, service control in Plesk can help you start, stop, or restart the application after changes. A restart is often required after updating the database configuration or replacing the WAR file.
Common problems after migration
Database connection refused
This usually means the application is still pointing to the old host, the database service is not reachable, or the database user does not have permission from the new host name or IP context.
Access denied for user
This typically indicates an incorrect username, password, or insufficient privileges. Recheck the credentials in the Java config and confirm the database user exists in the new environment.
Unknown database
The database was not created, was imported under a different name, or the application config still references the old name.
Charset or encoding issues
Text may display incorrectly if the database dump was not imported with the same character set as the source environment. UTF-8 is usually the safest choice for modern Java applications.
App starts but shows blank or partial pages
This can happen when the database schema imported incorrectly, certain tables were missing, or the app is unable to read required reference data. Check the database content and the server logs.
Best practices for Java and MySQL migrations on hosted platforms
- match the Java version as closely as possible
- keep application and database backups before every migration
- use a dedicated database user with limited privileges
- avoid hardcoding credentials in multiple places
- document the old and new JDBC settings
- test the application with a non-production account first
- restart the Tomcat or JVM service after configuration changes
- confirm that file paths, uploads, and temp directories still exist
On a hosted Java platform, small configuration details matter as much as the code itself. A clean migration is usually the result of matching the runtime, restoring the database correctly, and verifying every connection point between the app and MySQL.
When to use the hosting control panel
A control panel such as Plesk is especially helpful when you need to manage both the Java service and the database in one place. You can typically:
- create the MySQL database and user
- upload or deploy the Java application
- manage Java service settings
- switch Tomcat or Java versions where available
- restart the application after configuration changes
- review logs for troubleshooting
This is one of the main practical advantages of using a Java hosting solution with My App Server: the runtime and database configuration stay close together, which makes migrations easier for small and medium applications.
FAQ
Should I move the database before or after the Java app?
Usually export the database first, then deploy the Java app, then import the database, and finally update the connection settings. The exact order can vary, but the important part is to keep the app and data aligned before going live.
Do I need to change the JDBC URL when moving to the same hosting account?
Not always. If the database host, name, and user stay the same, the existing JDBC URL may still work. However, you should still verify it, because changes in Plesk or My App Server setup can affect internal host names or service references.
What if my application uses a different Java version on the new server?
Test the app carefully. Some applications work on newer Java versions, but others depend on older APIs or libraries. If possible, choose the closest supported Java version in the hosting environment before deployment.
Can I move a Tomcat app and MySQL database together in one maintenance window?
Yes, for small and medium applications this is often the best approach. Prepare backups, schedule a short maintenance window, perform the export and import, update config files, test, and then switch traffic.
What should I check if the app connects but data looks wrong?
Check the schema version, imported tables, encoding, and any seed or reference data the app expects. Also confirm that the application is not pointing to an empty test database by mistake.
Conclusion
Moving a Java application and database together is mostly a process of keeping dependencies in sync. The application files, the MySQL data, the Java runtime, and the Tomcat or JVM configuration all need to match after the migration. In a hosting environment with Plesk and My App Server, this becomes manageable because you can control the Java service, deploy the app, create the database, and update settings from one place.
If you plan the migration carefully, export and import the database cleanly, update all connection details, and test before launch, you can move the app with minimal downtime and avoid the most common connection and startup problems.