What to check in database credentials after a Tomcat migration

After a Tomcat migration, database connection problems are often caused by small credential changes rather than by Tomcat itself. If your web application starts but cannot reach MySQL, the first things to verify are the database username, password, host name, port, and the exact database name used in the application configuration. In hosted environments with a control panel such as Plesk, these details may also change when the service is moved, re-created, or connected to a different account.

For Java hosting and Tomcat hosting setups, especially when using a private JVM or a managed Tomcat instance through a hosting control panel, checking database credentials early can save a lot of time. A migration may keep the application files intact, but database access depends on matching the new environment exactly. This article explains what to check, how to validate each setting, and what to review in MySQL connection strings after the move.

What usually changes after a Tomcat migration

When a Tomcat application is migrated, the application package, configuration files, and runtime environment may not all move in the same way. The most common issues appear when the app still points to old database information.

The database username is different in the new hosting account.
The database password was reset during the move.
The database host changed from a local hostname to a fully qualified host name, or vice versa.
The database name was created with a different prefix.
The application is still using an old JDBC URL.
The MySQL user does not have permission to access the database from the new Tomcat runtime.
The connection pool settings still reference a previous schema or server address.

In a managed hosting or Plesk-based environment, this is especially important because database accounts are often tied to a specific subscription or service context. A migration to a new account or service can require updated credentials even when the application itself has not changed.

Check the database username first

The database username is one of the most common points of failure after migration. Even if the database name looks correct, the login will fail if the username does not match the account that exists on the destination hosting service.

Review the following:

Is the application using the correct MySQL username from the new environment?
Does the username include a hosting prefix, such as an account-specific prefix used by the control panel?
Was the user recreated after the migration?
Does the username in the configuration file match the user shown in the hosting panel?

In many shared hosting setups, the MySQL username is not just a simple short name. It may include an account prefix to keep databases isolated between customers. If the app was moved into a different subscription, the original username may no longer work.

Typical places where the username is stored

JDBC configuration file, such as a properties file or XML file used by the application.
Tomcat context configuration, if the datasource is defined there.
Environment variables, if the app reads credentials from startup settings.
Framework configuration, for example Spring or application-specific config files.

Verify the password exactly as stored in the hosting panel

After migration, a password mismatch is one of the most frequent reasons for database connection errors. The password may have been changed during export, re-import, or manual setup. Unlike usernames, password issues are not visible from the application logs alone, so they usually have to be checked directly.

Confirm the following:

The password in the Tomcat app config matches the current MySQL password.
No extra spaces were added when copying the password.
Special characters were preserved correctly in the configuration file.
The password was not encoded, escaped, or transformed incorrectly by the app.

If you are using a properties file, remember that certain characters may need escaping. A password containing \, :, =, or other reserved symbols can behave differently depending on how the application loads it. This is particularly important after manual migration, because credentials may be pasted into a new file and saved with a different encoding.

How to test whether the password is the issue

If the hosting control panel allows it, try temporarily changing the MySQL user password and updating the application configuration with the same new value. Then restart Tomcat and test the app again. If the connection succeeds, the problem was likely the old password or an encoding mismatch.

In a hosted Java environment, it is usually safer to update the app to the correct current password rather than trying to reuse an old one from the source system.

Confirm the database host name and port

The application may still be using the wrong database host after the migration. This happens often when the original Tomcat instance connected to a local MySQL service, while the new environment uses a different host name or a remote database server.

Check:

Is the host set to localhost or 127.0.0.1?
Should the app connect to an internal database host name provided by the hosting platform?
Is the MySQL port correct, usually 3306 unless the service is configured differently?
Was the hostname changed to a fully qualified domain name?

For Tomcat hosting, the JDBC URL must match the exact database endpoint. A common example is a URL formatted for MySQL, but with an outdated host value. If the database service moved, the app may still be trying to contact the old server address.

Example of what to review in a JDBC URL

Look for the host and port portion of the connection string, for example:

jdbc:mysql://hostname:3306/database_name

Make sure:

hostname is correct for the new environment
3306 matches the actual MySQL service port
database_name matches the current schema name exactly

Check the database name and schema permissions

The database name must be correct, and the user must have permission to access it. After migration, the schema may exist, but the user may not be linked to it properly.

Review the following:

The database name in the app config matches the name in the control panel.
The database exists in the target hosting account.
The MySQL user is assigned to that database.
The user has the required privileges, at least SELECT, INSERT, UPDATE, DELETE, and any others your application needs.

In some control panel setups, database names are also prefixed by the account name. If the application uses a hardcoded schema name from the previous server, it will fail even if the database was imported successfully.

It is also worth checking whether the application expects a specific default schema. Some Java apps use separate databases for content, logs, or user data, and one missing reference is enough to break startup or login.

Review Tomcat datasource settings if you use connection pooling

If your application uses a Tomcat datasource, the credentials may be stored in a server-side resource definition rather than inside the application package. This is common in managed Tomcat hosting environments and can be configured through the control panel or through Tomcat context files.

Verify these items:

The datasource username is correct.
The datasource password matches the current MySQL password.
The url points to the correct database host and schema.
The driver class is compatible with the MySQL version in use.
The resource name referenced by the app matches the datasource name in Tomcat.

Sometimes the application looks correct, but Tomcat is using a datasource defined elsewhere. In that case, changing the app properties alone will not fix the connection. You need to update the Tomcat resource definition or the Plesk extension settings used by the service.

Common datasource mistake after migration

A frequent issue is that the app references java:comp/env/jdbc/MyDB, but the resource behind that name still contains the old credentials. If this happens, the application can start normally and only fail when it tries to query the database.

Make sure the MySQL user is allowed to connect from the Tomcat host

Database credentials are not only about the username and password. MySQL also checks where the connection is coming from. After migration, the Tomcat service may run under a different host identity, and the MySQL user may not be permitted to connect from that source.

Check whether the database user is allowed from:

localhost
a specific internal host name
the application server host name
a remote IP address, if the database is hosted separately

If the hosting setup uses local database access inside the same account, this is usually straightforward. But if the app was moved between services, the host-based access rule may need to be recreated. In managed hosting, this is often handled by re-assigning the user to the database in the panel.

Check for hidden formatting issues in configuration files

During migration, configuration files may be edited in a different text editor or transferred with a different line ending format. This can affect database credentials in subtle ways.

Look for:

Accidental spaces before or after the username or password.
Incorrect character encoding, especially if the password contains non-ASCII characters.
Broken quotes in XML, properties, or JSON files.
Escaped characters that are no longer valid after the move.

If the application reads from context.xml, server.xml, a properties file, or a framework config file, make sure the syntax is still valid. A single missing quote can make the application fail to parse the datasource, even when the credential values themselves are correct.

Use logs to separate credential errors from connectivity errors

Tomcat and application logs can help you understand whether the problem is a wrong password, an invalid host, or a network issue. This is useful because all three can look similar from the browser side.

Common signs include:

Access denied messages usually point to a wrong username or password.
Unknown host errors suggest the hostname is wrong.
Connection refused may indicate a port, service, or firewall issue.
Cannot create PoolableConnectionFactory often means the datasource settings need review.

If the logs mention authentication failure, focus on credentials first. If they mention host resolution or timeout, check the JDBC URL and database endpoint before changing the password again.

Practical checklist after a Tomcat migration

Use this checklist to validate database credentials in order:

Confirm the database name exists in the destination hosting account.
Check the MySQL username in the panel and in the app config.
Verify the password exactly, including special characters and encoding.
Review the host name in the JDBC URL.
Confirm the port number used by MySQL.
Make sure the user is assigned to the correct database.
Check that the user has the required privileges.
Review Tomcat datasource settings if the app uses a pool.
Restart Tomcat after any credential change.
Test the connection again and check the logs for the exact error.

Example of a migration-safe review process

A good way to troubleshoot is to compare the old and new settings side by side. If you still have access to the source environment, export the database settings from the application config and compare them with the destination values in the hosting panel.

For example, verify these fields one by one:

Old database user versus new database user
Old password versus current password
Old host name versus new host name
Old database name versus imported database name
Old datasource name versus current Tomcat datasource

This comparison is especially useful in My App Server and similar Tomcat hosting setups where the application runs in a private JVM and the database configuration may be managed separately from the WAR file itself.

When to update the app configuration and when to recreate the database user

If only the password changed, update the configuration and restart Tomcat. If the database user no longer exists or was not migrated correctly, recreate the user in the control panel and assign it to the database again.

Choose the simplest fix that matches the problem:

Wrong password - update the app or datasource configuration.
Wrong username - update the app or recreate the correct user.
Wrong database name - correct the schema reference in the config.
User not linked to database - reassign the user in the hosting panel.
Wrong host or port - fix the JDBC URL.

FAQ

Why does Tomcat start correctly but the app cannot connect to MySQL?

Tomcat can run even if the database credentials are wrong. The application usually fails only when it tries to open a connection. This is why startup success does not prove the MySQL settings are correct.

Should I check the JDBC URL after migration?

Yes. The JDBC URL often contains the most important connection details: host, port, and database name. If any one of these is outdated, the app may fail to connect even when the username and password are correct.

Can the MySQL user exist but still not work?

Yes. The user may exist but not be assigned to the correct database, or it may not have permission from the host where Tomcat is running. In hosted environments, both account association and privileges matter.

What if the password contains special characters?

Special characters can cause problems if they are not escaped properly in properties files, XML, or shell-based configuration. If you suspect this, test with a temporary password that uses simple characters, then update the application configuration and retry.

Do I need to restart Tomcat after changing credentials?

Usually yes. If the datasource or application loads credentials at startup, restart Tomcat so the new settings take effect. In some setups, a service reload may not be enough.

Where should I look in a Plesk-based Tomcat setup?

Check the database section of the hosting panel, then review the Tomcat application configuration or datasource settings used by My App Server. Make sure the values in the panel and the values in the app match exactly.

Conclusion

After a Tomcat migration, database credential issues are usually caused by a mismatch in username, password, database name, host, or permissions. In a managed hosting environment, the fastest way to fix the problem is to compare the application configuration with the current values in the hosting panel, then confirm the Tomcat datasource if one is used. Once the database account, privileges, and JDBC URL all match the destination environment, MySQL connections should work normally again.

For Java hosting platforms that provide private Tomcat management through a control panel, keeping database credentials aligned with the migrated service is one of the most important steps for a smooth move. If the application still fails after the checks above, review the Tomcat logs and the datasource definition to identify the exact connection error.

What to check in database credentials after a Tomcat migration?