After moving a Tomcat project to a new hosting account or to a different location inside your control panel, the application usually needs two things before it works correctly again: updated configuration and updated database access. In a managed hosting environment with Plesk and a Tomcat service such as My App Server, this is a common step after migration, redeploy, or account restructuring.
If your application was using a different context path, an old filesystem path, a previous database hostname, or a database user from the source server, it may start with errors such as connection failures, missing files, or a blank page. The good news is that most Tomcat applications can be brought back online quickly by checking the deployment location, correcting the application configuration, and updating database credentials in the right place.
What usually changes after a Tomcat migration
When a Tomcat project is moved, several values often change at the same time. Even if the application code stays the same, the environment around it is rarely identical.
- Application path may change if the WAR file or exploded folder is deployed under a new name.
- Server paths may change if the app is now under a different account directory or document root.
- Database hostname may change if the database is on a new host or a new internal service name is used.
- Database username and password almost always need to be reviewed after migration.
- JDBC driver location may differ if the new Tomcat installation uses another Java version or classpath setup.
- Environment-specific settings such as mail server, file upload directories, API endpoints, and license keys may also need updates.
In a hosting control panel environment, these changes are usually handled in the application files, Tomcat configuration files, and database settings inside your app. For a Java hosting service like My App Server, you can manage the Tomcat instance, Java version, and deployment through Plesk, which makes this process more predictable.
Check where the project is deployed in Tomcat
Before changing configuration, confirm that the application is deployed where Tomcat expects it. A migration can leave the project under a new folder name, which affects URLs, context paths, and file references.
Verify the application folder and context path
Check whether your app is deployed as:
- a WAR file such as
myapp.war - an exploded directory such as
myapp/ - a custom context path defined in Tomcat or in the control panel
If your application expects to run at /app but it is now deployed as /myapp, internal links, redirects, and resource paths may break. In Plesk-based Tomcat hosting, the deploy name and the configured application URL should match your intended context as closely as possible.
Confirm the deployment location
Check the application files in the current account structure. Depending on how the migration was done, you may need to look in the app folder, the Tomcat webapps directory, or a custom deployment directory managed by the control panel.
Useful items to compare with the old environment:
- WAR filename
- Context name
- Resource folder paths
- Upload directory location
- Log file location
If the application uses absolute file paths inside properties files, XML configuration, or Java code, those paths must be updated to the new hosting account path.
Update application configuration files
Most Tomcat applications store external settings outside the compiled code. After migration, these values should be reviewed and updated before you restart the service or retest the app.
Common configuration files to review
Depending on the application framework, configuration may be stored in:
application.propertiesapplication.ymlorapplication.yamlcontext.xmlweb.xml- custom
.propertiesfiles - database configuration XML files
- framework-specific config folders
Look for settings that refer to the old server or old account paths. Typical examples include:
- database URL
- database username
- database password
- filesystem upload path
- temporary directory path
- SMTP host
- application base URL
- external API endpoint
Replace old filesystem paths
If your project previously used paths such as /home/olduser/appdata/ or a Windows-style development path, those references must be changed to the new hosting path. In shared hosting and managed Tomcat hosting, each account has its own directory structure, so hardcoded paths from another server will not work.
Good practice is to use relative paths where possible, or define a single configurable base directory. For example, instead of storing many hardcoded upload destinations, keep one property like app.upload.dir and update it after migration.
Check application base URL settings
Some applications generate absolute links, emails, redirects, or API callbacks based on a configured base URL. If the domain, subdomain, or context path changed during migration, update that value immediately.
Examples of values to review:
app.base.urlsite.urlserver.publicUrlspring.mvc.servlet.pathor similar framework settings
If the app sends password reset links or confirmation emails, an incorrect base URL can cause users to reach the old address or a broken path.
Update database access after migration
The database is one of the most common reasons a moved Tomcat project fails to start correctly. Even if the database contents were migrated successfully, the application still needs the right connection details.
Find the active database connection settings
In many Java web applications, the database connection is configured in one of these places:
- a properties file used by the app
- JNDI datasource configuration in
context.xml - Spring datasource configuration
- Hibernate configuration files
- environment variables or startup scripts
Review the current values for:
- JDBC URL
- database host
- database port
- database name
- username
- password
If your hosting provider or control panel created a new database user for the migrated account, the old credentials will no longer work. Update the application to use the new user and password.
Update the JDBC URL correctly
A JDBC URL usually contains the database type, host, port, and database name. After migration, the host may change even if the database name stays the same.
Examples of typical patterns:
- MySQL or MariaDB:
jdbc:mysql://hostname:3306/database_name - PostgreSQL:
jdbc:postgresql://hostname:5432/database_name
Make sure the URL matches the actual database service provided in your hosting account. If you are using a managed Java hosting setup with My App Server, the database is usually managed separately from the Tomcat service, so both sides must be checked after the move.
Confirm database privileges
Even if the username and password are correct, the user must have permission to access the required database and tables. In a hosting control panel, verify that:
- the database exists in the target account
- the database user is assigned to the database
- the user has the correct privileges
- the application is connecting to the expected database instance
If you copied the database but created a different user during migration, make sure the new user has the same level of access as the old one.
Update JNDI datasource settings in Tomcat
If your application uses JNDI instead of embedding the database connection directly in the app, you will need to review the Tomcat datasource definition as well as the application reference to it.
Check the Tomcat resource definition
Look for datasource entries in the Tomcat context configuration. These may define:
- resource name
- driver class name
- connection URL
- username
- password
- pool size and validation options
If the hosting environment changed, update the resource values to match the new database location and credentials.
Check the application lookup name
The app must reference the same JNDI name defined in Tomcat. A migration can expose mismatches if the resource name is different on the new server.
For example, if the application expects java:comp/env/jdbc/MyDB, the Tomcat configuration must provide the same datasource name.
Review Tomcat and Java-specific settings
After moving a Tomcat project, database access is not the only thing that may need adjustment. The runtime itself can affect how the application behaves.
Check the Java version
Some applications require a specific Java version. If the new hosting setup runs a different JVM, the app may compile and deploy but still fail at runtime.
Review:
- source compatibility
- library compatibility
- deprecated APIs
- container startup parameters
One benefit of a private JVM setup in managed Java hosting is that you can select the required Java version more easily, which helps when moving older or framework-specific Tomcat applications.
Check the connector and port settings
If the app uses an internal port, reverse proxy setting, or custom connector, verify that the new Tomcat service is listening on the expected configuration. This is especially important when the application is behind Apache or when a control panel routes traffic to a Tomcat backend.
Also review:
- HTTP port configuration
- HTTPS handling
- proxy headers
- session cookie settings
Confirm file permissions
A moved application can fail because the new account does not have the same read/write permissions as the old one. Check that Tomcat can access:
- configuration files
- upload folders
- cache directories
- log directories
- temporary files
If the application writes files at runtime, the target directory must be writable by the Tomcat process used by your hosting service.
Practical migration checklist
Use this checklist when you update a moved Tomcat application in your hosting account.
- Confirm the application is deployed in the expected Tomcat context.
- Review all configuration files for old paths, URLs, and credentials.
- Update database host, port, name, username, and password.
- Verify the database user has permissions on the correct database.
- Check JNDI datasource settings if the app uses Tomcat-managed connections.
- Update the base URL and any callback or mail settings.
- Review Java version compatibility and Tomcat-specific settings.
- Check file and folder permissions for uploads, logs, and cache files.
- Restart the Tomcat service from the control panel if needed.
- Test the application login, forms, database queries, and file uploads.
How to test that the new settings work
After updating config and database access, do not rely only on the homepage opening. Test the parts of the application that use external resources.
Recommended tests
- Open the main URL and check that the correct context loads.
- Log in with a real user account.
- Run a page that reads from the database.
- Submit a form that writes to the database.
- Upload a file if the app supports uploads.
- Check email sending if the app uses SMTP.
- Review the Tomcat logs for warnings and connection errors.
If something fails, the logs usually show whether the problem is database-related, permission-related, or a bad path in the configuration.
Common errors after moving a Tomcat project
Database connection refused
This usually means the JDBC URL, hostname, port, or firewall-related host setting is incorrect. It can also happen when the database service name changed after migration.
Access denied for user
The username or password is wrong, or the user does not have permission on the new database. Recheck the assigned privileges in the control panel.
File not found or path not found
This often means the app is still looking at the old filesystem location. Search the configuration for hardcoded paths and replace them with the current account path.
Application starts but pages are blank
This can indicate a missing resource, a failed database query, a Java version mismatch, or a broken application context path. Review the Tomcat logs and application logs carefully.
Uploads or cached files fail
The target folder may not exist in the new environment, or the Tomcat user may not have write access. Create the folder and set appropriate permissions.
Best practices for future Tomcat moves
To make the next migration easier, it helps to prepare the application for environment changes from the start.
- Keep all environment-specific settings outside the compiled code.
- Use separate config files for dev, test, and production values.
- Avoid hardcoded file paths.
- Store database credentials in one central place.
- Use relative paths where possible.
- Document the required Java version and Tomcat settings.
- Keep a note of the application context path and datasource name.
In a hosted Tomcat setup, especially one managed through Plesk and My App Server, this approach makes redeployment and migration much simpler. You can move the project between accounts or update the service with less downtime and fewer surprises.
FAQ
Do I need to change the database settings every time I move a Tomcat project?
Usually yes, at least the database host, username, password, or privileges need to be checked. Even if the database contents were moved, the application often points to the old connection details.
Can I keep the same Tomcat configuration after migration?
Only if the new environment is identical, which is uncommon. Paths, context names, Java version, and datasource settings should always be reviewed after a move.
Where should I update database credentials in a Java web app?
It depends on the application. Common places are properties files, Spring configuration, JNDI datasource definitions in Tomcat, or framework-specific config files.
What should I check first if the app does not start after moving?
Start with the logs, then check the database connection, file paths, and application context path. These are the most common causes of startup failures after migration.
Does Tomcat hosting in Plesk support separate Java versions?
In a managed Java hosting setup such as My App Server, you can typically choose from available Java/Tomcat versions or configure a custom app server where supported. This is useful when the migrated app depends on a specific runtime.
Why does the app work but not load data from the database?
This often means the app deployed successfully, but the database settings are wrong, the user lacks permissions, or the JDBC driver is missing or incompatible.
Conclusion
When a Tomcat project is moved, the deployment itself is only part of the job. To get the application working again, update the configuration files, confirm the context path, and replace the old database access details with the values used in the new hosting environment. In a Plesk-based Tomcat hosting setup, this process is usually straightforward if you check the app location, the database connection, and the Tomcat service settings in a structured order.
By reviewing file paths, JDBC settings, JNDI resources, permissions, and Java compatibility, you can restore the application quickly and avoid the most common post-migration problems. If the app was built to use external configuration cleanly, future moves will be much easier as well.