When you move a Tomcat application to a new hosting account, the application files are only part of the job. In many cases, the project also needs updated database settings, connection strings, file paths, environment variables, and Tomcat configuration values before it will run correctly under Plesk or a managed Java hosting setup. If your app was built for one server structure and then deployed into a private JVM or Apache Tomcat service in a new account, small differences in configuration can stop the application from starting or prevent it from connecting to the database.
This guide explains how to update config and database access after moving a Tomcat project, with practical steps for hosting users who deploy WAR files, JSP applications, servlet apps, or custom Java web applications through a control panel. It also covers what to check in the My App Server setup, how to update database credentials safely, and what to review when the application uses absolute paths, context parameters, or external resources.
What usually changes after a Tomcat migration
After moving a Tomcat project to a new hosting environment, the following items often need attention:
- Database host, name, username, and password
- JDBC driver class and connection URL
- Application-specific config files such as
*.properties,*.xml, or*.yml - Tomcat context settings and environment variables
- File upload paths and log paths
- Session, mail, and API endpoint settings
- Java version compatibility
- Filesystem permissions for runtime folders
In a Plesk-based Java hosting environment, the application may run inside its own JVM or Tomcat instance managed through the hosting panel. That means the configuration is often split between application files and service settings. A clean migration usually requires checking both.
Start with a full inventory of the old configuration
Before changing anything, identify every place where the application stores environment-dependent values. In Tomcat projects, configuration can be spread across several layers:
WEB-INF/classesproperties filesWEB-INF/web.xml- External config files outside the WAR package
- Spring or framework-specific config files
- Tomcat context descriptors such as
context.xml - Startup scripts or service definitions
If you are using My App Server, review how the application is deployed and whether the service has its own Java version, startup parameters, or application root. Keeping a copy of the old values makes it much easier to update the new hosting account without missing a hidden dependency.
Look for hard-coded paths
One of the most common migration issues is an absolute path such as /home/olduser/app/uploads or C:\tomcat\logs. On the new hosting account, the path structure will be different. Replace old paths with the correct directory in the new account, or better, convert them to relative paths where possible.
Check for references in:
- upload folders
- image storage locations
- temporary files
- report exports
- backup directories
- log file destinations
Check environment-specific values
Some Tomcat applications use separate configuration for development, staging, and production. Common values that must be updated after migration include:
- database endpoints
- SMTP server details
- API base URLs
- OAuth redirect URLs
- payment gateway callback URLs
- file storage endpoints
If your app has both a local and remote configuration file, make sure the version uploaded to the hosting account is the production-ready one, not a development copy.
Update database access settings
Database access is usually the first thing that breaks after a Tomcat move. The application may still load, but login pages, admin areas, or data-driven screens will fail if the JDBC configuration is outdated.
Step 1: Confirm the database type and driver
Identify which database the app uses, such as MySQL, MariaDB, PostgreSQL, or another JDBC-compatible database. Then verify that the correct driver is available in the new environment. In many Tomcat deployments, the driver JAR must be included with the application or configured in the server environment.
If the application worked before because the old server had a shared driver or custom server-wide setup, do not assume the same arrangement exists in the new hosting account. Upload or reference the driver as required by your My App Server or Tomcat setup.
Step 2: Create or verify the database in the new account
In the hosting control panel, create the database and a dedicated database user for the application. Use a strong password and grant only the permissions the app needs. For typical web applications, the user usually needs permissions to read, write, update, and create tables if the app performs schema changes.
Record the following values carefully:
- database name
- database username
- database password
- database host
- database port
Some hosting platforms use localhost for internal database access, while others require a specific host value. Always use the value provided in the control panel or hosting instructions.
Step 3: Update the JDBC URL
After migration, the JDBC connection string usually needs to be changed. A MySQL or MariaDB URL might look different depending on the host, port, SSL requirements, and database name. PostgreSQL URLs also need the correct host and port.
Typical elements to check in the JDBC URL:
- host name
- port number
- database name
- character encoding
- SSL flags
- timezone parameters
If the old application used a connection string with an internal network address or a server IP, replace it with the new database host value provided for the hosting account.
Step 4: Replace the database credentials in the app config
Most Java applications keep database settings in a properties file, XML file, or framework configuration file. Update the username and password there, and make sure the application is reading the correct file in the new location.
Examples of common configuration locations include:
db.propertiesapplication.propertieshibernate.cfg.xmlpersistence.xmlcontext.xmlspring.datasource.*settings
If the app uses connection pooling, update the pool settings as well. Incorrect pool sizing or stale credentials can cause repeated connection failures even after the main database values are corrected.
Step 5: Test the login and query flow
Once the new database details are in place, test the part of the app that depends on database access. Do not stop at the home page. Check features that perform actual reads and writes, such as:
- user login
- search or listing pages
- form submissions
- admin save actions
- report generation
If the application fails at this stage, review the logs first. A typo in the database host, a wrong password, or a missing JDBC driver is usually easier to spot in the logs than in the browser.
Update Tomcat and application configuration files
After a move, Tomcat itself may be correct, but the application still needs environment-specific tuning. In managed hosting, the Tomcat service or private JVM can have its own settings, while the app keeps its own configuration files. Both layers should be checked.
Review web.xml and context.xml
Some projects store datasource definitions, context parameters, and resource references in web.xml or context.xml. Verify that the JNDI resource name still matches the runtime configuration in the hosting account.
Check for:
- resource names used by the application
- JNDI datasource references
- initial context parameters
- session timeout settings
- error page mappings
If your application relies on a container-managed datasource, make sure the resource is declared in the correct place for the new Tomcat installation or My App Server profile.
Check framework configuration
Frameworks such as Spring, Hibernate, Struts, or JSF often store database and service settings in dedicated files. These files may contain:
- database dialect settings
- entity scanning paths
- transaction manager settings
- mail sender configuration
- static resource mappings
After migration, verify that the framework is still pointing to the right database, the right context path, and the correct runtime environment. A project may deploy successfully but still fail at runtime if a framework config is still tied to the old host.
Update server-side properties files
Many Tomcat projects use a simple properties file for runtime settings. This is often the easiest place to make migration changes. Common examples include:
jdbc.urljdbc.usernamejdbc.passwordapp.baseUrlmail.hostupload.dir
When editing these values, keep formatting unchanged unless the application documentation says otherwise. A missing character or extra space can break parsing in some older applications.
Adjust file permissions and writable directories
Tomcat applications often need write access to specific folders. After a move, those folders may exist but not be writable by the Java process. This is common with uploads, temp files, cache data, and log output.
Review directories used for:
- uploaded documents
- image processing
- session storage
- temporary files
- generated PDFs or exports
- application logs
If the app runs in a private JVM managed through Plesk or My App Server, the ownership and permissions must match the service account used by that runtime. If a folder is not writable, the application may start but fail later when it tries to save files.
Check the Java version and runtime compatibility
Some Tomcat applications run correctly only on a specific Java version. If the app was built for an older JDK and the new hosting account uses a newer one, configuration or dependency issues may appear after deployment. The same applies in reverse.
In the control panel, confirm:
- selected Java version
- Tomcat version or app server version
- JVM arguments if the app needs custom memory settings
- any app-specific startup flags
For smaller and medium Java web applications, choosing the correct Java version is often enough to resolve startup problems without changing the application code. If the project uses deprecated libraries, test it against the available Java versions before going live.
How to update configuration safely in Plesk or My App Server
If your hosting account includes My App Server, configuration changes are usually done in a more structured way than on a manual server. That is helpful because it keeps the application and runtime settings in one place.
Use the panel for service-related changes
For service-level settings, update them through the control panel rather than editing system files directly. Depending on the setup, you may be able to:
- select the Tomcat version
- switch the Java version
- manage start and stop actions
- set application root paths
- define memory or startup parameters
Using the panel reduces the risk of losing changes during redeployments or service restarts.
Use application files for app-specific settings
Keep business logic configuration inside the application where possible. That includes database settings, API keys, and environment values that are specific to the app itself. This separation makes future migrations easier because you only need to update the environment-dependent values.
Redeploy after changes
After editing config files, redeploy the WAR or restart the Tomcat service so the application loads the updated settings. If the app caches configuration at startup, a restart is usually required for changes to take effect.
Common migration mistakes to avoid
- Leaving the old database host in the JDBC URL
- Forgetting to update the database password
- Uploading the wrong config file version
- Missing JDBC driver JARs
- Using absolute paths from the old server
- Not granting write access to upload folders
- Running the app on an incompatible Java version
- Editing the file in the wrong location inside the WAR
- Expecting old JNDI names to work without reconfiguration
A practical migration checklist helps prevent these issues. If one change is missed, the application may appear partly functional, which makes troubleshooting harder later.
Troubleshooting after the move
If the project still does not work after updating config and database access, start with the application and Tomcat logs. In a hosting environment, the logs usually point you toward the failed component quickly.
Database connection errors
Look for messages such as authentication failure, unknown host, connection refused, or driver not found. These usually mean the app cannot reach the database or the credentials are wrong.
File not found or permission denied errors
These errors often indicate an incorrect path or a folder without write access. Recheck every external directory used by the application.
Java class or library errors
If the app fails during startup with class loading or method errors, verify the Java version and any missing dependencies. A project that worked on another server may rely on a library that was available there but not included in the new deployment.
Wrong context path or 404 errors
If the application loads but certain URLs return 404, review the deployed context path and any routing rules in the application or Tomcat configuration.
Best practice for future Tomcat moves
If you expect to move the project again later, make the application easier to migrate now. Use a configuration approach that keeps server-specific values separate from application code. This reduces downtime and makes hosting changes much simpler.
Recommended practices include:
- store runtime values in external properties files
- avoid hard-coded file paths
- document database dependencies
- keep JDBC settings in one place
- use predictable directory names for uploads and logs
- test the app after each deployment change
For Tomcat hosting on a managed platform, this approach works especially well because the application can be deployed cleanly while the runtime is controlled through the panel. That makes updates faster and reduces the chance of configuration drift.
FAQ
Do I need to change the database after moving a Tomcat project?
Usually yes. Even if the database structure is the same, the host, username, password, port, or connection string often changes in the new account. Update the app config to match the new database details.
Where should I update Tomcat database settings?
It depends on the application. Common places are properties files, web.xml, context.xml, Spring config files, or JNDI datasource settings in the hosting panel.
Why does the app start but fail on login after migration?
This often means the database connection is not correct. The home page may be static, but login requires a working database query. Check credentials, JDBC URL, and driver availability.
Can I reuse the old config file unchanged?
Only if the new environment is identical, which is uncommon. In most hosting migrations, at least the database host, file paths, and service settings need to be updated.
What if my Tomcat app uses file uploads?
Make sure the upload directory exists in the new account and that the Tomcat process can write to it. Update any absolute path in the config to the new location.
Do I need to restart Tomcat after config changes?
Yes, in most cases. Tomcat or the private JVM should be restarted after updating configuration files so the application loads the new values.
Conclusion
Updating config and database access after moving a Tomcat project is a normal part of migration, not a sign that the deployment failed. The key is to check both the application layer and the Tomcat runtime layer: database credentials, JDBC URLs, file paths, Java version, writable folders, and any control-panel-managed service settings. In a My App Server or Plesk-based hosting environment, this process is usually straightforward when you update the correct files and restart the service cleanly.
For reliable results, keep application settings separate from server-specific values, verify database access early, and test the parts of the app that actually read and write data. That approach saves time, reduces downtime, and makes future Tomcat migrations much easier.