After a Java migration, database access is one of the first areas to verify. Even if the application compiles and the Tomcat service starts normally, a small mismatch in MySQL credentials, hostname, or permissions can stop the app from connecting to the database. In a managed hosting environment with Plesk and a private JVM, it is common for the Java code, servlet container, and database service to work independently but still fail at the connection layer if the credential set was copied incompletely or updated in the wrong place.
If you have moved a Java application to a new hosting account, changed the Tomcat setup, or switched to a different My App Server instance, check the database credentials carefully before troubleshooting the application logic. In many cases, the issue is not with Java itself, but with the database user, JDBC URL, or network access from the new runtime.
What should be verified first after a Java migration?
Start with the parts of the database connection that most often change during migration. For hosted Java applications, these usually include the database name, username, password, host, and port. If any of these values were hardcoded in configuration files, environment properties, or deployment descriptors, they may still point to the old environment.
In a Plesk-based setup, also confirm whether the database was created under the same subscription or whether a new database user was assigned during the move. Even if the database content was imported successfully, the application cannot connect unless the Java credentials match the actual MySQL account and its privileges.
Check these items immediately
- Database name matches the target environment.
- Database user is the correct account for that database.
- Password is current and stored correctly in the app config.
- Hostname is correct for the hosting platform.
- Port is the expected MySQL port, usually 3306 unless configured differently.
- Privileges allow the user to read, write, and create the objects your app needs.
- JDBC URL uses the right syntax for the MySQL driver and target host.
Confirm that the Java application is using the right credentials
Java applications often store database access details in properties files, XML files, WAR configuration resources, or framework-specific settings. After migration, these values may still reference the old database server, an old username, or a password that was changed during transfer. If your app runs inside My App Server with a private Tomcat instance, verify the configuration in the deployed application as well as any external files used by the service.
Common places to check include:
- application.properties or similar application configuration files
- web.xml or framework XML configuration
- Spring Boot datasource settings
- JNDI datasource definitions in Tomcat
- Environment variables loaded by the service
- Custom startup scripts used by the Java runtime
When using a managed hosting control panel, make sure the values in the app match what is configured in Plesk. A database user may exist in the panel, but if the application still points to a local test credential or an older migration password, the connection will fail immediately at login.
Verify the MySQL username and password
The most common migration problem is a username and password mismatch. During transfers, it is easy to import the database itself but forget to recreate the same MySQL user, or to reset the password without updating the app. Java applications usually report this as an authentication error, access denied message, or connection refused from the datasource layer.
Check the following:
- The username is exactly correct, including any prefix added by the hosting platform.
- The password has been copied without extra spaces or broken line endings.
- The password was updated in every place where the application stores database settings.
- The MySQL user is assigned to the correct database.
On some hosting platforms, database usernames are prefixed with the subscription or account name. If you created a new user in Plesk after the migration, the actual login may be different from the one used on the old server. Java will not automatically discover the new value, so the configuration must be updated manually.
Check the JDBC connection string
Even when the username and password are valid, the app can still fail if the JDBC URL is wrong. After a Java migration, confirm that the JDBC string points to the correct MySQL host, database name, and port. This is especially important if the original app used localhost and the migrated version now uses a different hostname or service endpoint.
A typical MySQL JDBC URL should clearly identify the target host and database. Make sure the syntax matches the driver version used by your Tomcat or Java runtime. A small format error, such as a missing slash, wrong parameter separator, or old connection option, can break the connection even when the credentials themselves are correct.
Look for common JDBC mistakes
- Using the wrong hostname, such as an old internal server name
- Leaving the database name blank or outdated
- Using an invalid port number
- Forgetting required time zone or SSL parameters if the application expects them
- Hardcoding a local address that no longer applies in the new hosting setup
If your app uses a datasource configured in Tomcat, verify the resource definition in the server configuration rather than only in the application code. In My App Server, the private JVM and Tomcat service should point to the same database endpoint that your application expects.
Confirm database host and remote access requirements
In a hosted Java environment, the MySQL server may be accessed locally or remotely depending on the account structure and control panel configuration. After migration, the database host may not be the same as before. Some applications assume that MySQL is available on localhost, while others require a specific host name or internal service address.
Check whether the migrated application is allowed to connect to the database from its current runtime. If the database server is remote, ensure the hosting account allows the Java process to reach it and that the database user is permitted from the app host. If the application was moved into a private JVM via My App Server, the connection path may differ from the old environment, even if the application files are unchanged.
Host-related items to review
- Is the database server local or remote?
- Has the hostname changed after the migration?
- Is the MySQL service listening on the expected port?
- Does the database user allow connections from the application host?
- Is there any firewall or network rule affecting the connection?
If your application logs show a connection timeout rather than an authentication error, the problem may be host reachability rather than credentials. That is still part of the connection check, and it should be reviewed before changing the application code.
Review database user privileges
A user can have the correct login details and still fail if the permissions are incomplete. After a Java migration, especially one involving imported databases or recreated MySQL users, ensure that the account has the required grants for the application.
Typical Java web applications need permission to:
- SELECT data
- INSERT records
- UPDATE rows
- DELETE records when required by the application
- CREATE and ALTER tables for schema changes or migration routines
Some frameworks also require temporary table access, stored procedure execution, or metadata queries. If your app worked before but now fails after moving to a new hosting account, compare the privileges granted to the database user in the old and new environments.
In a control panel such as Plesk, it is often quicker to inspect the assigned database user directly than to search through application logs first. If the user was recreated during the move, reassign the correct permissions before testing again.
Check for password formatting issues in configuration files
Passwords are often copied into plain-text config files or deployment templates during migration. Even when the password itself is correct, formatting problems can break the connection. This is common when values are copied from notes, shell output, or a control panel screen.
Common formatting problems
- Leading or trailing spaces
- Unescaped special characters in XML or properties files
- Wrong quote type in scripts or environment variables
- Line breaks inserted during copy and paste
- Incorrect character encoding in the config file
If the password contains special characters such as &, <, >, #, or quotation marks, verify how the file parses those characters. Java configuration files, XML descriptors, and shell scripts do not always handle the same password format in the same way.
Validate the database name after import
Database imports may succeed even when the application is pointing to the wrong schema. This can happen if the new hosting account contains several databases, or if the imported database was renamed during the migration. The Java app may connect successfully but then fail because the expected tables are missing.
Check that the configured database name is the one containing the application tables. If the app uses multiple schemas or separate reporting databases, verify each one individually. A mismatch here often appears as missing table errors, even though the login credentials are otherwise correct.
Test the connection from the hosting environment
Whenever possible, test the database connection from the same environment where the Java app runs. This is the best way to separate credential issues from application-level issues. In a managed hosting context, you may not always use command-line tools directly, but you can still confirm connectivity through logs, test scripts, or temporary diagnostics inside the hosting account.
Useful checks include:
- A simple JDBC test from the application runtime
- A database login test using the same username and password
- Reviewing Tomcat logs for authentication or handshake errors
- Checking MySQL error logs, if available, for rejected connections
If the test works outside the application but fails inside Tomcat, the issue may be in the datasource configuration, driver version, or the way the application reads its settings. If the test fails everywhere, focus on credentials, host access, and privileges first.
Look at the Java driver version and compatibility
After a migration, the app may be running on a different Java version or a different Tomcat version under My App Server. That can affect how the MySQL driver behaves. A connection problem is sometimes caused by an outdated JDBC driver or by a driver that does not match the current runtime.
Check whether the application uses a compatible MySQL Connector/J version for the Java runtime and database version. If the driver is too old, you may see authentication errors, SSL negotiation issues, or problems with timezone handling. If the app was migrated from an older host, it may still carry driver files that are no longer suitable for the new setup.
Driver and runtime points to confirm
- Is the JDBC driver included in the deployed application or provided by the container?
- Does the driver support the current Java version?
- Does the driver support the database server version in use?
- Are there duplicate driver JAR files causing conflicts?
Check Tomcat datasource and service configuration
For applications running on a private Tomcat instance, database credentials may be defined in the server configuration rather than inside the application package. If you use My App Server, review the service settings in the control panel and confirm that the correct datasource values are loaded when the service starts.
This is especially important when the app uses JNDI resources. In that case, the application code may refer to a datasource name, while the actual username, password, and JDBC URL live in the Tomcat configuration. After migration, the app can continue to start successfully even if the datasource points to the old database credentials.
Check:
- Tomcat resource definitions
- Context configuration files
- Service startup parameters
- Any custom configuration uploaded for a private JVM
When the service is controlled from the panel, restart it after making changes so the new credentials are loaded cleanly. A stale service instance can keep an old connection pool in memory and hide the effect of your config update.
Troubleshooting based on the error message
The error text often tells you where to look first. After a Java migration, use the message as a guide instead of changing multiple settings at once. This reduces the chance of introducing a second problem while fixing the first.
Common symptoms and what they usually mean
- Access denied for user — username, password, or host permission is wrong.
- Unknown database — database name is wrong or the schema was not imported.
- Communications link failure — host, port, network, or driver problem.
- Connection timed out — remote access issue or service unavailable.
- Table does not exist — correct login, wrong database schema.
Use the error message together with the recent migration changes. For example, if the app was moved to a new My App Server instance and now shows a timeout, focus first on reachability and host settings. If it shows access denied, check the MySQL account and password values in the deployment configuration.
Practical migration checklist
Use the checklist below to verify database credentials after a Java migration in a hosting account:
- Confirm the application is reading the new configuration files.
- Verify the MySQL username, including any platform prefix.
- Re-enter the password carefully in every relevant config location.
- Check the JDBC URL for host, database name, and port.
- Confirm the database exists and contains the imported tables.
- Make sure the MySQL user has the correct privileges.
- Review Tomcat datasource settings if the app uses JNDI.
- Restart the Java service after changes.
- Test the connection again before checking application code.
This sequence helps you isolate whether the issue is in the credential data, the hosting control panel, or the Java application configuration itself.
When to check the hosting panel instead of the code
If the application worked before migration and now fails immediately on login, the hosting panel is often the fastest place to start. In a Plesk-based Java hosting environment, the database user, password, and assigned database are usually managed separately from the application package. If those values changed during the transfer, updating the code alone will not resolve the issue.
This is particularly relevant for hosted Java, Tomcat, JSP, and servlet applications that run inside a private JVM. The application may appear healthy, but if the database layer is misconfigured, pages that depend on SQL access will still fail.
FAQ
Why did the Java app work before migration but not after?
The most common reason is that the database credentials or JDBC settings were tied to the old hosting environment. After migration, the database username, password, host, or database name may have changed.
Should I check the password first or the JDBC URL first?
Start with both, but if the error says access denied, focus on the username and password. If the error says connection timed out or communications link failure, focus on the host, port, and network access.
Can the database exist but the app still fail?
Yes. The database may be present and imported correctly, but the application can still fail if the MySQL user does not have the right privileges or if the app points to the wrong schema.
What if the app uses JNDI in Tomcat?
Then check the Tomcat datasource configuration as well as the application code. The credentials may be defined in the server resource settings rather than in the WAR file.
Do I need to restart the Java service after changing credentials?
Yes. If you change database settings, restart the Tomcat or private JVM service so the application reloads the updated configuration and clears old connection pools.
What if the password contains special characters?
Check how the password is stored in the config file. Special characters may need escaping in XML, properties files, or shell scripts. A password can be correct but still fail if it is parsed incorrectly.
Conclusion
After a Java migration, database credential issues are usually caused by a small mismatch rather than a major fault. The safest approach is to verify the MySQL username, password, database name, host, port, and privileges before changing the Java application itself. In a managed hosting setup with Plesk and My App Server, these checks are especially important because the Java runtime, Tomcat service, and database settings may each be configured in different places.
If you confirm the credentials, test the JDBC URL, review the Tomcat datasource, and restart the service, most post-migration database connection problems can be resolved quickly. This gives you a stable base for the migrated Java application to run normally on its private JVM.