After a Tomcat migration, database access is one of the first things to verify. Even when the application files and Tomcat service start correctly, a small mismatch in the database credentials can break login flows, form submissions, CMS back ends, or API calls. In a hosted Java environment, this usually means checking the username, password, hostname, port, database name, and JDBC connection string inside the application configuration or Tomcat resources.
If your application runs on a managed hosting account with a private JVM or a Tomcat instance controlled from a panel such as Plesk, the migration may also change how the app reaches MySQL. The database itself may not have moved, but the connection details often need to be reviewed because the runtime path, context path, or environment configuration has changed.
What usually changes after a Tomcat migration
When a Tomcat application is migrated, the main application files are often copied across, but database settings may still need to be revalidated. Common changes include:
- the database hostname or server name
- the port used by MySQL or MariaDB
- the database username
- the password stored in the application config
- the JDBC URL format
- the location of the config file in the new Tomcat deployment
- the permissions of the database user on the target database
In many cases, the issue is not a broken database account but a configuration file that still points to the old environment. This is especially common after moving a WAR-based application, changing the context path, or switching between a manually uploaded Tomcat build and a ready-to-install version in a hosting control panel.
Check the database hostname first
The most common failure after a migration is a wrong host value. In the source environment, the application may have connected to localhost, a private database container, or a specific internal host name. After migration, that value may need to change.
What to verify
- Is the application still using localhost?
- Does your hosting provider require a different database host name?
- Is the host name written as an IP address, DNS name, or service name?
- Does the application use a socket-based local connection or a TCP connection?
For hosted applications, the safest approach is to confirm the exact host value from the control panel or hosting documentation rather than assuming the old one still applies. Some Java applications allow the host to be set in a properties file, XML resource, or environment variable. If the database lives on the same account or infrastructure, the host may still be local, but that should be verified explicitly.
Confirm the database username and password
Credentials are often copied during migration, but they are also often stored in more than one place. A Tomcat application may read them from a properties file, a JNDI resource, a Spring configuration file, or a custom XML file inside the deployment directory.
Things to check
- the database username in the config file
- the password value, including any special characters
- whether the password was changed in the control panel but not in the app
- whether the username includes an account prefix or domain prefix
- whether the application uses a separate read-only user or admin user
Special characters in passwords can cause problems if they are not escaped correctly. For example, characters such as &, #, ;, :, and quotes may be interpreted differently depending on the file format. If the credentials were moved from one server to another, verify that the password is stored in the right syntax for the file type you are using.
If you are using a hosting control panel, compare the credentials shown in the database management area with the values inside the Tomcat application config. They must match exactly.
Check the database name and schema
It is easy to move the application but forget that the database name may differ on the new account or service. The JDBC driver may connect successfully, yet the application may still fail because it points to the wrong schema or an empty database.
Verify these details
- the exact database name
- whether the database was imported fully
- whether the app expects a specific schema name
- whether case sensitivity matters for the database name
Some Java applications use separate connection settings for different environments. For example, development, staging, and live systems may each have a different database name. After migration, make sure the active environment is set to the correct one. A successful connection to the wrong database can be more dangerous than a connection failure, because it may lead to missing data, inconsistent records, or test data being shown to users.
Review the JDBC URL carefully
Many database connection issues are caused by an outdated or incomplete JDBC URL. The URL may contain the host, port, database name, and connection options in a single string, so one small mistake can break the whole connection.
Typical items inside a JDBC URL
- database protocol, such as
jdbc:mysql:// - hostname
- port number, commonly 3306
- database or schema name
- parameters such as timezone, SSL, or character encoding
After migration, compare the current JDBC URL with the previous working version. Look for:
- an old host name that no longer exists
- a missing database name after the host and port
- an incorrect port
- parameters that are no longer valid in the new environment
- SSL options that were required before but are not available now, or vice versa
If the application uses a connection pool in Tomcat or a resource definition inside the server configuration, the JDBC URL may be defined outside the application package. In that case, check both the application files and the Tomcat resource configuration.
Check where Tomcat stores the connection settings
Depending on how the app was deployed, database credentials may be stored in different places. A migration can fail simply because the configuration file was copied to the wrong folder, or because the application reads a different file after redeployment.
Common locations to inspect
- application properties files
- XML configuration files
- Tomcat context descriptors
- server.xml or resource definitions
- environment-specific config files
- framework files for Spring, Hibernate, or similar systems
On a managed hosting platform with Plesk-based Java hosting, it is common to manage Tomcat and app settings through an extension or service interface. If you use a private JVM or a custom Tomcat instance, confirm whether the credentials are stored in the application package itself or in a service-level configuration file that is separate from the deployable WAR.
If the application was deployed again after migration, the app may have picked up a default config instead of the intended production config. This can happen if file paths changed or if the service started with a different working directory.
Make sure the database user still has the right permissions
Even with the correct username and password, the connection can fail if the user does not have permission on the selected database. This is a common issue after database import or account changes.
Check the following grants
- permission to connect from the application host
- SELECT, INSERT, UPDATE, and DELETE rights if the app needs them
- CREATE, ALTER, and DROP rights if the application performs schema changes
- access to the correct database or schema only
In hosted environments, the database user may be restricted to specific databases. If the app was moved to a different account or a different database server, a user that worked before may need to be recreated or reattached to the imported database. If you use phpMyAdmin or a panel-based database manager, confirm that the user is assigned correctly and not only listed as existing.
Check for special character and encoding problems
Migration can expose encoding issues that were previously hidden. A database password or JDBC URL may include characters that require escaping, and the application may interpret them differently after moving to a new Tomcat version or a different configuration style.
Common signs of encoding problems
- the password works in the control panel but not in the app
- the JDBC URL appears correct but the app still rejects it
- accented characters or non-ASCII data are stored incorrectly
- connection errors appear only after redeploying the WAR
Also check the database character set and collation if your application stores multilingual content. While this is not a credential problem strictly speaking, migration often brings it to the surface. A connection may work, but page content may display incorrectly if the application expects a different character encoding.
Verify the correct driver is installed and loaded
Sometimes the credentials are correct, but the app still cannot connect because the JDBC driver is missing or outdated. After Tomcat migration, the driver JAR may not have been copied, or the new Tomcat installation may use a different classpath.
What to review
- is the MySQL or MariaDB JDBC driver present
- is the driver version compatible with the current Java version
- is the driver placed in the right Tomcat library directory
- does the application bundle its own driver conflicting with the server one
In Java hosting setups with a separate private JVM, the driver should match both the Java version and the application framework. A missing driver often produces errors that look like credential failures, so do not assume the password is wrong until the driver is confirmed.
Review Tomcat logs for the exact database error
Tomcat logs usually show whether the problem is authentication, network access, driver loading, or a bad connection string. This is the fastest way to narrow down the cause after migration.
Look for messages such as
- Access denied for user
- Unknown database
- Communications link failure
- No suitable driver found
- Cannot create PoolableConnectionFactory
Each error points to a different part of the credential chain. For example, Access denied usually means the username or password is wrong, or the user lacks permission. Unknown database usually means the database name is incorrect or missing. Communications link failure often means the host or port is wrong, or the database service is not reachable from the application.
When using managed hosting with service control from a control panel, the logs may be available through the panel interface, a file manager, or a service log path. Check the time of the error and compare it with the migration and restart times.
Compare old and new configuration side by side
If you still have access to the source environment, compare the working and migrated settings line by line. This is one of the most effective ways to spot a mismatch quickly.
Compare these values
- database host
- port number
- database name
- username
- password
- JDBC URL parameters
- driver class name
- connection pool settings
Even a seemingly minor difference, such as a trailing space in the password or a missing parameter in the JDBC string, can prevent the application from connecting. If your app uses multiple config files, make sure you compare the active file, not just the template.
Check whether the application uses a connection pool
Many Tomcat applications use a connection pool to improve performance. After migration, the pool configuration can mask credential problems or make them appear only under load.
Pool settings to verify
- initial pool size
- max active or max total connections
- validation query
- timeout values
- test-on-borrow or test-while-idle settings
If the pool is configured incorrectly, the app may start but fail once it tries to open database connections. A validation query can help confirm that the credentials work and that the database responds properly. In a Tomcat hosting environment, this is especially useful after a migration because it confirms both the config and the service path.
Practical checklist after migration
Use this checklist to confirm the database credentials after moving a Tomcat application:
- confirm the database host name
- confirm the port number
- confirm the database name or schema
- verify the username and password exactly as stored
- check for special characters that need escaping
- confirm the user has permission on the target database
- review the JDBC URL and all parameters
- confirm the JDBC driver is installed and compatible
- check Tomcat logs for the exact error message
- verify that the app is reading the correct config file
Example migration issue and how to fix it
Suppose a JSP application worked before migration, but after deployment it returns a database login error. The old environment used a local database host, while the new setup requires a different host name defined by the hosting account. The password is correct, but the application still points to the old JDBC URL. In this case, the fix is not to change the database itself, but to update the Tomcat configuration or application properties file to use the correct host and database name, then restart the service and test again.
If the application still fails, check whether the imported database was assigned to the correct user and whether the JDBC driver is present in the new Tomcat instance. If the logs show Access denied, focus on the credentials. If they show Unknown database, focus on the schema name. If they show a driver error, focus on the Java/Tomcat setup rather than the database account.
When to ask for hosting support
If you have checked the credentials, host, port, permissions, and logs but the app still cannot connect, it is reasonable to contact hosting support. Provide the exact Tomcat error message, the database host you are using, the database name, and the time of the failed test. This helps the support team determine whether the issue is in the application config, the Tomcat service, or the database account setup.
In a managed Java hosting environment, support can often confirm whether the application is reading the right config file, whether the database user is linked to the database, and whether the Tomcat service is running with the expected Java version. That usually shortens the troubleshooting time significantly.
FAQ
Do I need to change database credentials after every Tomcat migration?
Not always. If the database host, user, password, and schema remain the same, the credentials may not need to change. However, you should still verify them because the application may now read config from a different path or use a different database endpoint.
Why does Tomcat start but the application still cannot connect to MySQL?
Tomcat and the database connection are separate checks. The service can start successfully even if the database settings are wrong. In that case, review the JDBC URL, credentials, database permissions, and driver installation.
What is the most common credential mistake after migration?
The most common mistake is an outdated database host or JDBC URL. The second most common is a password mismatch caused by copying the wrong config file or failing to escape special characters correctly.
Can the database user be correct but still fail after migration?
Yes. The user may have the right password but lack permission on the new database, or the app may be connecting to the wrong host or schema. A valid username alone is not enough.
Should I check the Tomcat logs or the database first?
Check the Tomcat logs first. They usually show whether the problem is authentication, network access, driver loading, or an invalid database name. That saves time and prevents guesswork.
Does a private JVM or custom Tomcat setup change what I should check?
Yes. In a private JVM or custom Tomcat setup, the config files, driver path, and service settings may be different from the source environment. Make sure the deployed app is reading the correct files and that the Java version matches the JDBC driver requirements.
Conclusion
After a Tomcat migration, database credentials should be checked methodically rather than assumed to be correct. Start with the host, port, username, password, and database name. Then review the JDBC URL, permissions, driver, and Tomcat logs. In a hosted Java environment with Plesk-based service control or a private Tomcat setup, the issue is often a configuration path or resource definition rather than the database itself.
By comparing the old and new settings side by side and confirming the exact error in the logs, you can usually restore database connectivity quickly and avoid unnecessary changes to the application or database structure.