After moving a Tomcat application to a new host, the application usually starts only when the configuration files, environment values, and file paths match the new server setup. In a managed hosting environment with Plesk and a Java hosting extension such as My App Server, the safest approach is to review each config file, check the Java version, confirm the Tomcat service settings, and update any host-specific values before you restart the application.
Most migration issues are caused by a small number of changes: database credentials, file system paths, JVM options, domain names, environment variables, and external service endpoints. If you update these carefully, a Tomcat WAR, JSP application, or servlet-based app can usually be moved with minimal downtime.
What usually changes after a Tomcat migration
When a Tomcat app runs on a new host, the code may still be the same, but the runtime environment is not. That means any value that depends on the old server must be checked. In practice, this often includes:
- Database host, username, password, and JDBC URL
- SMTP settings for mail sending
- API endpoints and webhook URLs
- Absolute paths to uploads, logs, cache, or temp folders
- Java version and JVM options
- Context path, domain name, and base URL
- Filesystem permissions for application data
- Any Tomcat-specific config such as server.xml, context.xml, or application properties files
In a hosted Java environment, some values may be managed in Plesk or in the My App Server interface, while others remain inside the application package. The key is to separate settings that belong to the hosting platform from settings that belong to the app itself.
Identify which config files your app actually uses
Before editing anything, confirm where your application stores configuration. Many Tomcat apps use a mix of files, and not all of them are in the same place.
Common Tomcat and Java config files
- application.properties or similar Spring-style config files
- web.xml for servlet and deployment settings
- context.xml for resource definitions, JNDI, or context-specific values
- server.xml for Tomcat connector and service-level settings
- .env files or custom environment files used by the app startup scripts
- log4j.properties, logback.xml, or other logging configs
- database config files stored outside the WAR for easier updates
In many deployments, the application WAR contains default settings, but the live values are stored outside the package so they can be changed without rebuilding the app. This is especially useful when you move between hosts or switch to a different Java version.
Check whether the app reads values from environment variables
Some applications do not hardcode config values in files. Instead, they read values from environment variables such as DATABASE_URL, JAVA_OPTS, SPRING_PROFILES_ACTIVE, or custom variables defined by the startup script. If the application worked on the old host but not on the new one, missing environment values are a common reason.
In a Plesk-based Java hosting setup, environment values may be configured through the service or app server settings rather than directly in the WAR. If you are using My App Server, check the service control and the app-specific configuration area before changing the application code.
Back up the old configuration first
Never edit migrated config files without keeping a backup copy. Even a small typo can prevent Tomcat from starting or can break database access. Save the original file versions from both the old host and the new host so you can compare them later if needed.
A practical backup checklist includes:
- Original config files from the old server
- The current files on the new host before editing
- Database export or connection details
- Any custom startup scripts or service definitions
- Notes about old and new Java versions
If your hosting provider gives you file management in Plesk, download the current files before making changes. That makes rollback much easier if the app does not start on the first try.
Compare old and new values line by line
The safest way to update config files after a move is to compare the old and new environments side by side. Focus on values that are likely to be different on a new host.
Database connection settings
Database configuration is usually the first thing to verify. Update the host, port, database name, username, and password if the new hosting account uses different credentials.
Example areas to check:
- JDBC URL
- Connection pool settings
- JNDI resource names
- Timeouts and retry settings
If the old server used localhost but the new host uses a separate database service, the JDBC URL will need to change. If the app is using MySQL, PostgreSQL, or another database, also verify that the correct driver is available and compatible with the Java version in use.
File paths and storage locations
Old absolute paths rarely work unchanged on a new host. Look for references to folders such as:
/home/olduser//var/lib/tomcat//opt/app/- custom upload directories
- cache and temp directories
- log file locations
In shared hosting or managed hosting, you often need to use the account’s own home directory structure. Make sure the app can read and write to the target folder and that the path is stable across restarts.
Hostnames, domains, and base URLs
If your app generates links, redirects, or callback URLs, update all references to the old domain or host name. This is especially important for login flows, payment integrations, SSO, and email links.
Search for old values in:
- application properties
- template files
- frontend environment config
- redirect rules
- OAuth or API callback settings
When possible, use a single base URL variable instead of repeating the same domain in many files. That makes future migrations easier.
Update Tomcat-specific settings safely
Not every migration requires changes in Tomcat itself, but you should still check the service-level settings. In a hosting platform with a separate Tomcat service or private JVM, these values can affect startup and runtime behavior.
Java version and JVM options
After moving the app, verify the Java version selected for the service. Some applications run correctly only on a specific major version of Java. A mismatch can lead to class loading errors, SSL problems, or unsupported syntax.
Review JVM options such as:
- Heap size values like
-Xmsand-Xmx - Garbage collector flags
- Encoding settings such as
-Dfile.encoding=UTF-8 - Timezone settings
- Custom system properties passed with
-D
For hosted Java apps, keep JVM tuning conservative unless you know the application needs special values. A private JVM on a shared hosting account usually benefits from clear, minimal settings rather than complex tuning.
Tomcat connectors and ports
If the app was moved to a new host, connector values may also change. Check whether the service listens on the expected port and whether the app expects HTTP, HTTPS, or an internal reverse proxy setup through Apache.
Common values to review:
- HTTP connector port
- Proxy name and proxy port
- Secure flag settings
- Redirect port values
- Compression or timeout settings
In many managed hosting setups, Apache handles public traffic while Tomcat runs behind it. If this is the case, make sure the app’s config matches the proxy setup and does not hardcode the old host’s port.
Context path and application deployment location
If the application was deployed under a different context path on the new host, update any config values that depend on that path. This matters for internal redirects, static resource links, and API routes.
For example, if an app was previously available at /app and is now deployed at /myapp, URL generation and redirect logic may need to be updated in the config or environment values.
How to edit config files in a managed hosting environment
With Plesk or a similar control panel, you usually have several ways to update configuration safely. The best method depends on whether the file belongs to the application, to Tomcat, or to the hosting service itself.
Use the file manager or SSH with care
If the hosting account supports SSH, a text editor over SSH can be convenient for quick fixes. For larger changes, use file manager tools or download the file, edit it locally, and upload it back. That reduces the chance of encoding issues or accidental formatting changes.
When editing, keep these rules in mind:
- Preserve file encoding, especially for XML and properties files
- Do not add extra spaces inside sensitive values
- Keep XML syntax valid if you edit
web.xmlorcontext.xml - Restart the service only after all values are updated
Prefer environment values for host-specific data
If your application supports it, move host-specific settings out of the WAR and into environment variables or external config files. This reduces future maintenance when you migrate again or change database credentials.
Good candidates for external values include:
- database connection details
- SMTP credentials
- API keys
- feature flags
- base URLs
- upload directories
This approach is especially practical in Java hosting environments where the same Tomcat application may need different values across staging and production.
Update the most common config file types
application.properties and similar files
For Spring Boot and similar apps, check all property files for old host values. Typical changes include database URLs, cache servers, mail settings, and file paths. If the application uses profiles, verify that the correct profile is active on the new host.
web.xml
Look for context parameters, welcome files, and resource references. If the app uses servlet init parameters for configuration, those values may need to be changed after the move.
context.xml
This file often contains datasource definitions or JNDI resources. When the database connection changes, this file may need a new URL, username, password, or driver class.
server.xml
Most application-level settings should not live here, but if your setup uses custom connector or service values, confirm they still match the new host. A wrong connector or proxy value can prevent the application from responding correctly behind Apache.
Logging config files
Make sure log file locations point to writable directories on the new host. If logs were written to a path that no longer exists, the app may still run but you will lose useful error output. For troubleshooting after migration, logging is essential.
Test the application after each change
Do not change everything at once if you can avoid it. Update one group of settings, restart Tomcat or the service, and test the result. That makes it easier to isolate the problem if the app fails.
Suggested testing order
- Verify the service starts successfully
- Check the application log for startup errors
- Open the app in a browser and confirm the main page loads
- Test login, forms, and database-backed pages
- Check uploads, email sending, and scheduled tasks if used
- Confirm external API calls still work
If the application does not start, the first place to look is the Tomcat or application log. Common errors include invalid XML, missing properties, permission problems, and unsupported Java options.
Fix permissions and ownership issues
On a new host, the application may have the correct config values but still fail because it cannot read or write files. This is common when the app needs access to uploads, temp files, or custom logs.
Check that the service user can access:
- the application directory
- temporary folders
- log directories
- upload and cache paths
- any mounted external storage
In a shared hosting account with a private JVM, permissions should be kept narrow and intentional. Give the app access only to the paths it actually needs.
Common mistakes after moving a Tomcat app
- Leaving the old database host in the JDBC URL
- Forgetting to change the base URL or callback domain
- Using a Java version that the app does not support
- Editing the wrong config file while the live values are stored elsewhere
- Breaking XML syntax in
web.xmlorcontext.xml - Using old absolute paths that do not exist on the new server
- Missing permissions on upload or log directories
- Overwriting working config without keeping a backup
A careful review of these points usually solves most migration problems quickly.
Example migration checklist
Use this checklist when updating config files after moving a Tomcat application:
- Confirm the new host uses the expected Java version
- Compare old and new config files
- Update database host, name, user, and password
- Replace old file system paths
- Change domain names, base URLs, and callback addresses
- Review JVM options and environment variables
- Check Tomcat or service-level connector settings
- Verify permissions for logs, uploads, and temp folders
- Restart the service
- Test logs, pages, forms, and external integrations
FAQ
Should I edit the WAR file directly after migration?
Only if the application was built to store config inside the WAR and there is no external config option. In most hosted Tomcat setups, it is better to keep environment-specific values outside the package so they can be changed without rebuilding the app.
What is the first file I should check after moving a Tomcat app?
Start with the file that stores database and environment-specific values, usually application.properties, a custom config file, or a JNDI datasource definition in context.xml. Database and path issues are the most common cause of startup errors after a move.
Do I need to change Tomcat settings or only application settings?
Usually both should be checked. The application config handles database, URLs, and file paths, while Tomcat or the hosting service handles Java version, JVM options, connectors, and service startup behavior.
How do I know if a value belongs in Plesk instead of in the app config?
If the value is service-level or environment-level, such as Java version, memory limits, or service startup settings, it often belongs in Plesk or the hosting control panel. If it is specific to the app, such as a database password or base URL, it usually belongs in the application config.
Why does the app start on the new host but pages still fail?
That often means the core service is working, but one or more config values are still wrong. Check database access, file permissions, API endpoints, and absolute paths first. Also review the logs for warnings or runtime exceptions.
Can I use the same config file for all environments?
You can use a shared template, but the live values should be environment-specific. Development, staging, and production usually need different database hosts, URLs, and credentials.
Conclusion
Updating config files after moving a Tomcat application to a new host is mostly about making the runtime environment match the app’s expectations. Focus on database settings, paths, domains, Java version, JVM options, and service-level values, then test carefully after each change. In a managed hosting setup with Plesk and My App Server, this approach gives you practical control over a private Tomcat or JVM instance without needing a complex enterprise deployment model.
When the config is organized well, future moves are much easier. Externalize host-specific values where possible, keep backups, and verify logs after each restart. That is the most reliable way to keep a Tomcat hosting migration stable and predictable.