What to check in database credentials after a Java migration

After a Java migration, database connection problems are often caused by small credential changes rather than the application code itself. If your app was moved to a new Java version, a new Tomcat instance, or a private JVM in Plesk, it is worth checking every database-related setting before you start debugging the application layer.

In a hosted Java environment, especially when using a control panel such as Plesk and a service like My App Server, the database login details may need to be reviewed in more than one place. The application may use a properties file, a WAR package, environment variables, or a panel-based service configuration. If any of those values are outdated, the app may fail to connect to MySQL even though the database itself is working correctly.

What usually changes after a Java migration

A Java migration can involve one or more of the following:

a different Java version
a new Tomcat instance or private JVM
a new deployment path or application context
updated connection pooling settings
new file permissions after redeploy
different network access rules between the app and the database

None of these changes directly alter MySQL credentials, but they can expose a previously hidden issue. For example, an old password may still be stored in the application package, or the hostname may now point to the wrong database server. In some cases, the credentials are correct but the Java app is no longer reading the file where they are stored.

Database credentials to verify first

The first step is to confirm that the application is using the correct database connection values. For hosted Java applications, the most important fields are usually the same regardless of framework or Java version.

Username

Check that the database username is correct and that it matches the current account or schema. Hosted environments often use separate database users for separate applications. After a migration, the app may still be pointing to an older username that no longer has permission to access the target database.

Typical issues to look for:

the username was changed during migration
the app is using a development account instead of production
the database user exists, but does not have access to the selected schema
the username was copied with an extra space or hidden character

Password

Verify that the password stored in the application matches the current database password. This is one of the most common causes of connection failure after moving a Java app. If the password was reset in the hosting panel, the application config file must be updated as well.

Remember that the password may be stored in more than one place:

application properties file
Tomcat data source configuration
environment variables
deployment descriptor or XML config
panel-defined service settings

Database name

Make sure the application points to the correct database name. A migrated app may still reference the old database name from a previous hosting environment. This is especially important when multiple databases exist on the same hosting account.

Check for:

old database names in JDBC URLs
schema name mismatch
test database still referenced in production config
typos in the database name after manual edits

Hostname or database server address

In many hosting setups, MySQL is accessed using a hostname such as localhost, 127.0.0.1, or a specific internal database server name. After migration, this value may need to change if the application moved to a different service or if the database is hosted separately from the Java runtime.

Important checks include:

whether the app should use localhost or an actual host name
whether the database is on the same hosting account or remote
whether the host name changed after a platform migration
whether IPv4 and hostname resolution behave differently in the new Java setup

Port

The default MySQL port is usually 3306, but do not assume this is always correct. If the database runs on a non-standard port, the Java app must use the correct value in its JDBC URL or data source settings.

After migration, confirm that:

the port is still available from the new Java runtime
the port value was not lost during redeployment
the hosting firewall or local access rules allow the connection
your JDBC string includes the port if required

Where to check the credentials in a Java hosting setup

In a managed hosting environment with Plesk and My App Server, the database values may be stored in multiple layers. The exact location depends on how the application was packaged and deployed.

Application configuration files

Common locations include application.properties, database.properties, config.xml, hibernate.cfg.xml, Spring configuration files, or custom project-specific files. If the app was deployed as a WAR file, these files may be inside the archive or placed in an external config directory.

Check whether the file is still the one currently used by the running application. A migration can accidentally leave the app reading an outdated copy from a previous path.

Tomcat data source settings

If the application uses a Tomcat-managed data source, review the relevant JNDI configuration. In this case, the database credentials are not necessarily hardcoded in the app itself. They may be defined at the server level, which means a private JVM or separate Tomcat instance may need matching settings after migration.

Review:

data source name
username and password
JDBC URL
driver class
connection pool settings, if used

Environment variables

Some Java apps read database credentials from environment variables instead of a file. This is useful, but it can also make troubleshooting harder after a migration if the variables were not recreated in the new runtime.

Confirm that the values are defined for the active service and not only in an old session or shell profile.

Control panel service configuration

When using My App Server in Plesk, service-level settings may affect how the app reads the database config. If you installed a Tomcat version with one click or configured a custom app server manually, review the service parameters and startup settings as well. A correct database password in the code is not enough if the service is running with different environment data.

Check the JDBC URL carefully

After a Java migration, the JDBC URL is one of the most overlooked causes of database failure. A valid username and password are not enough if the URL points to the wrong database or uses an incompatible format for the driver version.

A typical MySQL JDBC URL may include:

protocol prefix
host name
port
database name
optional parameters such as timezone, SSL, or character encoding

Examples of common issues:

old host name still used after migration
missing database name in the URL
incorrect port
driver-specific parameter no longer supported by the new Java version
SSL parameter added or removed during the migration

If the application started failing after a Java upgrade, compare the old and new JDBC driver requirements. Some older connection strings work in one Java release but fail in another because the MySQL connector behavior changed.

Confirm database privileges, not only login data

Credentials can be technically correct while the application still cannot read or write data. After migration, make sure the database user has the required permissions for the specific schema and tables.

At minimum, verify whether the user can:

connect to the database
read tables
insert and update data
create temporary objects if the application needs them
access stored procedures if they are used

In hosted environments, a user may have been recreated without the same privileges as before. If the database user was reassigned during the migration, the application may authenticate successfully but still fail during normal operation.

Review character encoding and special characters

Database credentials can break when they contain special characters and the application interprets them differently after migration. This is common when passwords are copied into XML files, shell scripts, or JDBC URLs without proper escaping.

Check the following:

special characters in the password are escaped correctly
the config file uses the expected encoding, usually UTF-8
no extra line breaks or spaces were added during edit
the password is not truncated by a parser or panel field limit

If the password includes symbols such as &, <, >, ", or ', verify how the app or XML parser stores them. A password may look correct in a text editor but still fail when the service starts.

Check file permissions after migration

In a hosted Java environment, configuration files may be correct but unreadable by the Tomcat process or private JVM. After a migration, permissions can change because files were uploaded again, ownership changed, or the app was deployed to a new directory.

Make sure the running service can read the config files that contain the database credentials. If the application reads credentials from a file outside the archive, this file must be available to the service account used by My App Server or Tomcat.

Look for:

wrong ownership after upload
restricted read permissions on config files
config file placed outside the deployment path
service account unable to access the directory

Compare the old and new Java runtime behavior

Sometimes the database credentials are fine, but the new Java version changes how the app loads them. That can happen when the application uses a framework, connection pool, or custom initialization code that behaves differently in the migrated environment.

Useful checks include:

Does the app load the same config file as before?
Does the new Java version support the same MySQL connector?
Has the app switched from one pool implementation to another?
Are there startup errors before the database connection is even attempted?

If the application begins to fail immediately after startup, review the server logs first. A credentials issue often appears as an authentication error, while a path or parsing issue may prevent the database settings from loading at all.

Step-by-step checklist after a Java migration

Use the following checklist to verify MySQL credentials and related settings in a hosted Java deployment:

Confirm the active application and Tomcat instance.
Check the current database username and password in the control panel.
Compare them with the values stored in the app config.
Verify the database name and host name.
Confirm the correct MySQL port.
Review the JDBC URL for syntax and parameters.
Check whether credentials are stored in files, JNDI, or environment variables.
Confirm the database user still has the required privileges.
Verify that config files are readable by the Java service.
Restart the service after making changes and review the logs.

Common error messages and what they often mean

After migration, database errors often look similar even when the root cause is different. Here are some common patterns:

Access denied for user

This usually means the username or password is wrong, or the user does not have permission from the current host.

Unknown database

The database name in the config does not match an existing database. Check whether the app still points to the old schema.

Communications link failure

This often points to a host, port, firewall, or service availability issue rather than an incorrect password.

No suitable driver

The Java app may be using an outdated MySQL JDBC driver or an incompatible driver version after migration.

Connection refused

This usually indicates the database host or port is not reachable from the Java runtime.

My App Server and Plesk considerations

When using ITA Java hosting with My App Server, the application may run in its own JVM or Tomcat instance under a hosting account. That gives you practical control over the Java environment, but it also means database settings must align with the active service configuration.

After migration, check whether:

the correct Java version is selected for the service
the intended Tomcat instance is running
the app was redeployed to the right context
the data source definition matches the current runtime
the database credentials were updated in both the panel and the app package

This is especially useful for WAR, JSP, and servlet deployments where a small mismatch in configuration can stop the application from connecting to MySQL.

Troubleshooting flow if the app still cannot connect

If you already checked the credentials and the app still fails, narrow the issue down step by step:

Test the database username and password directly in the hosting panel.
Confirm the database exists and is online.
Review the application logs and Tomcat logs for the exact error.
Check whether the JDBC driver matches the Java version in use.
Restart the service after any config change.
Remove cached or duplicated config files if the app is reading an old copy.

If the application uses connection pooling, also clear the pool after changing credentials. Some pools keep old connections alive until the service is restarted, which can make the problem look inconsistent.

Best practices for future Java migrations

To reduce downtime during the next migration, keep database access settings organised and documented.

Store database credentials in one clearly defined location.
Keep a copy of the JDBC URL and driver version used by the app.
Note whether the app uses direct JDBC, JNDI, or environment variables.
Document the Tomcat or private JVM service name.
After any password change, update the application immediately.
Test the connection after Java upgrades, not only after redeploying code.

In a managed hosting environment, this kind of documentation helps when the service is moved, the Java version is changed, or the application is reinstalled through Plesk.

FAQ

Should I check the database password first after a Java migration?

Yes. It is one of the most common causes of failed database connections after migration. Make sure the password stored in the application matches the current database password in the hosting panel or configuration file.

Can the Java version affect MySQL credentials?

Not directly, but it can affect how credentials are loaded, escaped, or passed to the JDBC driver. A migration to a newer Java version can reveal config parsing issues or driver incompatibilities.

Why does the app connect locally but not after deployment in Tomcat?

This often means the deployed Tomcat instance is reading a different config file, using different environment variables, or running under a service account that cannot access the expected file.

Is the database host the same as the database name?

No. The host is the server address used to reach MySQL, while the database name is the schema the application connects to. Both must be correct.

What if the credentials are correct but the app still fails?

Check database privileges, JDBC URL syntax, driver compatibility, file permissions, and whether the application is loading the correct config file. The logs usually show which part fails first.

Do I need to update Tomcat settings after changing MySQL credentials?

If your app uses Tomcat-managed data sources or stores credentials in server-level configuration, yes. Update the relevant service settings and restart the application.

Conclusion

After a Java migration, database credential issues are usually caused by a mismatch between the active runtime and the values stored in the application or hosting panel. The safest approach is to verify the username, password, database name, host, port, JDBC URL, and permissions together rather than checking only one field.

In a Plesk-based Java hosting environment with My App Server, this also means confirming which Tomcat instance or private JVM is active and where it reads its database settings from. When those pieces match, MySQL connections usually recover quickly after migration.

What to check in database credentials after a Java migration?