When you move a Tomcat application to a new host, the application usually starts, but it may not behave exactly as it did before. The most common reason is that Tomcat apps depend on environment-specific values such as database connection strings, file paths, JVM options, mail settings, and application-specific properties. After a migration, those values often need to be checked and updated so the app can connect, write files, and run correctly in the new hosting environment.
If you are using a managed hosting platform with Plesk and a Java/Tomcat setup such as My App Server, this process is usually straightforward: review the config files, update paths and credentials, confirm the Tomcat service settings, and then test the application in the new account. The key is to change only what is environment-specific and keep the application logic untouched.
What usually changes after moving a Tomcat app
Most Tomcat applications rely on a mix of external configuration and internal application files. After moving to a new host, the following items are the most likely to need updates:
- Database host, database name, username, and password
- JDBC driver location or version
- File system paths for uploads, logs, exports, or temp files
- Java version or JVM arguments
- SMTP settings for email delivery
- API endpoints, web service URLs, or third-party integrations
- Absolute paths in
context.xml,server.xml,web.xml, or custom property files - Environment variables used by the application
In a hosting control panel environment, it is also common to update service-specific settings, such as the Tomcat start parameters, memory limits, or the application root directory defined in Plesk or in the My App Server extension.
Check which config files your application uses
Tomcat apps do not all store configuration in the same place. Before editing anything, identify where the app reads its settings from. Common locations include:
Application property files
These are often named application.properties, config.properties, db.properties, .env, or similar files inside the web app or in a separate configuration directory. They may contain database credentials, service URLs, or feature flags.
Tomcat context configuration
Some apps use a context.xml file to define resources such as a JDBC DataSource, JNDI references, session settings, or path mappings. This is a common place to find host-specific values.
Tomcat server configuration
server.xml may contain connector ports, host definitions, and deployment settings. In managed hosting, this file may be limited or managed by the platform, so check carefully before changing it.
Environment startup files
Depending on how Tomcat is installed, startup scripts or environment files may define JAVA_HOME, CATALINA_HOME, CATALINA_BASE, JAVA_OPTS, or custom variables. In a Plesk-based Java hosting setup, some of these values are set through the service configuration rather than edited directly.
Externalized configuration
Some applications store settings outside the WAR file, for example in /var/www/vhosts/..., a shared data directory, or a custom app server path. This is often safer during migrations because you can update configuration without repackaging the application.
Recommended update process after a host migration
The safest approach is to work in a structured order. This reduces the risk of missing a file path or leaving old credentials behind.
1. Make a backup of the current application and config
Before changing anything, save a copy of:
- the WAR file or exploded web app directory
- all custom config files
- JDBC drivers and libraries
- uploaded assets and data directories
- Tomcat service settings from the control panel
If possible, keep a copy of the old host configuration as a reference. This makes it easier to compare the old and new environments and see which values must be updated.
2. Identify old host-specific values
Search the configuration for values that are tied to the previous host. Typical examples are:
- old database server names or private IPs
- old domain names or subdomains
- absolute file paths from the previous hosting account
- hardcoded URLs in the application settings
- SMTP hostnames from the previous provider
- ports that are no longer correct in the new environment
A quick text search across the config directory often finds most of these values immediately.
3. Update database settings first
For many Tomcat applications, the database connection is the first thing that must be corrected. Update the following if needed:
- database hostname
- port number
- database name
- username and password
- connection pool settings if they were tuned for the old host
If the application uses a JNDI DataSource in Tomcat, update the resource definition in the relevant context file or in the control panel where the resource is managed. If the app uses a direct JDBC URL inside a properties file, update the connection string there.
Example patterns to check for include:
jdbc:mysql://old-host:3306/databasejdbc:postgresql://old-host:5432/databasedb.host=old-hostspring.datasource.url=...
4. Replace file paths with paths valid on the new host
Applications often break after a move because they still refer to an old absolute path. This can affect uploads, report generation, cache files, export directories, and log storage.
Look for paths such as:
/home/olduser/.../var/lib/tomcat...C:\...if the application was previously developed on Windows
Update them to the correct path for the new hosting account. On managed hosting with My App Server, use the application’s current home, data, and log directories as shown in the control panel. Avoid using temporary paths unless the application explicitly expects them.
5. Check Java version compatibility
Even if the app files are correct, the application may behave differently if the Java version changed. Some older Tomcat applications rely on Java 8, while others work better with newer Java releases. In a platform that supports several Java/Tomcat versions, verify that the selected version matches the application’s requirements.
Review the following settings:
- Java runtime version
- Tomcat version
- JVM arguments
- encoding settings such as UTF-8
- memory allocation
If the application uses deprecated libraries or older servlet APIs, a version mismatch may cause startup errors or runtime exceptions.
6. Review JVM options and environment variables
Some apps need custom startup parameters. These can include memory limits, garbage collection flags, active profiles, or file encoding. Common examples are:
-Xmsand-Xmxmemory settings-Dfile.encoding=UTF-8-Dspring.profiles.active=prod-Duser.timezone=Europe/Londonif the app depends on local time handling
In a hosting control panel, these values may be set through the Java application service settings rather than inside the WAR file. If your hosting platform provides a service control section, verify that the Tomcat service starts with the expected parameters.
7. Update mail and external service settings
If the app sends email or connects to external systems, update those values too. This includes SMTP host, port, username, password, and TLS or SSL settings. Also check API base URLs, webhook endpoints, and authentication tokens if they are environment-specific.
Do not assume the old settings will work on the new host. Even when the application is unchanged, external services may require the new server IP, domain, or authentication details to be approved again.
8. Recheck permissions for writable directories
A common post-migration issue is a Tomcat application that starts but cannot write to a folder. Confirm that the application user can write to all required locations, especially:
- upload folders
- cache directories
- log directories
- temp directories
- report or export folders
If the app uses a private JVM or separate Tomcat instance, make sure the service user and ownership match the hosting platform’s expected structure. In Plesk-based Java hosting, it is often best to use the paths and permissions created by the control panel instead of forcing custom ownership rules.
Where to update settings in a Plesk and My App Server environment
In a managed hosting environment, not every setting should be edited directly in the Tomcat installation. Some values are better changed through the control panel so they remain consistent with the service configuration.
Use the control panel for service-level settings
Update service-related values in Plesk or in the My App Server interface when the setting affects the Tomcat instance itself, for example:
- Java version selection
- Tomcat service start and stop control
- memory limits
- application root or deploy location
- custom JVM options supported by the service
Edit application files for app-specific values
Use file-level edits for settings that belong to the application rather than Tomcat, such as:
- database credentials
- application endpoints
- internal feature flags
- email sender settings
- hardcoded file locations inside the app
This separation helps keep the deployment stable and makes future changes easier.
Examples of config changes after a Tomcat move
Database connection example
Before migration, a config file might point to an old database host. After the move, update the database URL and credentials to match the new environment:
- Old host:
db-old.example.com - New host:
db-new.example.com - Database name, username, and password may also change
If the app uses connection pooling, verify the pool size and timeout values as well. A moved app may need slightly different settings if the new host has different resource limits.
Upload directory example
An app that stored uploads in /home/olduser/uploads should be updated to the new account path. If the app supports a configurable upload directory, change it in the properties file. If it is hardcoded in source code, repackage the app after making the change or move that setting into an external config file.
SMTP example
If the mail server changed, update the SMTP host and port. Also confirm whether the application should use STARTTLS or SSL, and make sure the sender address is valid for the new domain.
How to test the application after updating config files
Testing is just as important as editing. A Tomcat application can appear to start correctly while still failing in the background because of a wrong path or missing resource.
Check these points after the update:
- The Tomcat service starts without errors
- The web application loads in the browser
- Login or main pages display correctly
- Database queries return expected data
- File uploads and downloads work
- Email notifications are sent
- Logs do not show file permission errors
- No old hostnames appear in stack traces or application logs
If the application has a health page or admin page, use it to confirm the runtime status. For applications deployed through a hosting panel, also check the service status and restart it if the configuration update requires a reload.
Common mistakes to avoid
After a migration, many issues come from small config mistakes rather than major deployment errors. The most common ones are:
- Editing the wrong copy of a config file
- Leaving an old absolute path in one property value
- Changing Tomcat service files when the app config file was the real problem
- Forgetting to restart the service after saving changes
- Using a Java version that the app does not support
- Applying production values to the wrong environment file
- Missing write permissions on uploads or logs
- Leaving test credentials in place after the move
One practical tip is to compare the old and new config side by side. This makes it easier to spot values that should stay the same and values that must change.
Best practices for safer config editing
If you regularly deploy or migrate Tomcat applications, a few habits can save time and reduce risk:
- Keep environment-specific values outside the WAR where possible
- Use separate files for development, staging, and production settings
- Document which settings are managed in Plesk and which are inside the app
- Prefer relative paths or configurable directories over hardcoded paths
- Store a copy of each working configuration before each migration
- Validate one change at a time when troubleshooting
This approach works especially well for small and medium Java applications running on shared hosting with a private Tomcat or JVM instance.
Troubleshooting if the app does not start
If the application fails after the config update, review the Tomcat logs and the application logs first. The most useful error messages usually mention one of the following:
- unknown host or connection refused for the database
- file not found for a missing directory or resource
- permission denied when writing logs or uploads
- unsupported class version or Java incompatibility
- JNDI resource not found
- invalid property value in the config file
If the logs are unclear, temporarily reduce the problem to the smallest test case: database only, then file write access, then external service access. This helps isolate the exact setting that needs correction.
FAQ
Do I need to edit Tomcat files after every host move?
Not always. If the application uses externalized configuration and the new host has the same Java and database setup, only a few values may need updating. However, it is still important to review all environment-specific settings after each migration.
Should I edit server.xml directly?
Only if the setting truly belongs to Tomcat and your hosting platform allows it. In a managed Plesk environment, many service-level changes are better handled through the control panel or the provided Java hosting interface.
What is the most common config issue after moving a Tomcat app?
The most common issue is a stale database connection string or an old file path. These are the first places to check when an app breaks after migration.
Can I keep the same config files between hosts?
You can keep the same structure, but host-specific values usually need to change. The safest approach is to reuse the same file format and update only the environment-dependent values.
How do I know which Java version to use?
Check the application documentation, the build target, and any error messages from startup logs. If the app was already working on a specific Java release, start with that version if your hosting platform supports it.
What should I do if the app works but cannot upload files?
Check the upload directory path and permissions. Confirm that the new hosting account can write to the directory and that the configured path exists on the new host.
Conclusion
Updating config files after moving a Tomcat app to a new host is mostly about replacing old environment-specific values with the correct settings for the new hosting account. Focus on databases, paths, mail, Java version, JVM options, and writable directories. In a Plesk-based Java hosting environment with My App Server, use the control panel for service-level settings and edit the application config files for app-specific values. With a careful review and a simple test plan, most Tomcat migrations can be completed cleanly and with minimal downtime.