When you move a Java application to a new host, the code often stays the same, but the surrounding configuration does not. Database URLs, file paths, Java version settings, Tomcat connector values, mail settings, and environment-specific secrets usually need to be checked and updated before the application will run correctly.
If your Java hosting account uses Plesk with My App Server, you can manage a private JVM or Apache Tomcat instance directly from the control panel and keep the application isolated within your hosting account. That makes migrations simpler, but it also means you should review both the application files and the server-side configuration after the move. A clean configuration update reduces downtime, avoids startup errors, and prevents your app from still pointing to the old host.
What usually changes after a Java app migration
After moving a Java application to a new server or hosting platform, the most common issues come from values that were hardcoded for the old environment. These values are often stored in .properties, .xml, .yml, .json, .env, or Tomcat-specific files such as server.xml and context configuration files.
Typical settings that need attention include:
- Database host, port, name, username, and password
- JDBC connection strings and driver class names
- Absolute file paths for uploads, logs, backups, and temp files
- SMTP server details for email sending
- API endpoints for third-party services
- Java memory options and JVM arguments
- Tomcat ports, connector settings, and application context paths
- Environment variables used by the application at runtime
In a managed hosting environment, the goal is not only to make the app start, but to make it start with the correct values for the new account, domain, and runtime configuration.
Start with a full inventory of config files
Before changing anything, identify where the application stores its configuration. This is the fastest way to avoid missing a hidden file that still references the old host.
Common config file locations
WEB-INF/classes/for Java web application propertiesWEB-INF/web.xmlfor deployment descriptorsapplication.propertiesorapplication.ymlfor Spring-based appscontext.xmlor Tomcat context descriptorsserver.xmlfor custom Tomcat server settings.envfiles for environment valuesconfig/,settings/, or app-specific folders- External config files mounted or placed outside the WAR package
If you use My App Server in Plesk, check both the application deployment files and the service configuration available in the control panel. Some values may be managed through the service settings, while others are part of the app package itself.
Search for old host references
Look for the previous server name, IP address, database hostname, domain, or any old absolute path. A simple text search across the app package often reveals leftover values quickly.
- Search for the old domain name
- Search for the old database hostname or IP address
- Search for
localhostif the app was using local services before - Search for path prefixes such as
/var/www/,/home/olduser/, or Windows paths - Search for hardcoded ports, especially if the new host uses different service bindings
Do not assume only one file needs changing. A Java app may read values from several layers: application properties, system properties, environment variables, and Tomcat context parameters.
Update database settings first
Database connectivity is one of the most common failure points after migration. Even if the database was migrated correctly, the application may still be pointing to the old connection string or credentials.
Check the JDBC URL
Make sure the JDBC URL contains the correct host, database name, and port for the new environment. A URL that worked on the previous server may fail if it still references the old database server or an internal network address that is no longer reachable.
Example patterns to review:
jdbc:mysql://new-host:3306/appdbjdbc:postgresql://new-host:5432/appdbjdbc:sqlserver://new-host:1433;databaseName=appdb
Confirm username and password
When moving to a new host, database users are often recreated or imported with different permissions. Verify that the app uses the correct credentials and that the user can connect from the hosting account or application service.
- Update the database username if it changed
- Update the password in all relevant config files
- Check for special characters that may need escaping
- Confirm the user has the required schema permissions
Test the database connection outside the app
Before restarting the application, test the database connection separately if possible. This helps distinguish between a database problem and an application startup problem. In a Plesk-based Java hosting setup, use the available tools or logs to confirm whether the service can reach the database successfully.
Review file paths and storage locations
Java applications often rely on file paths for uploads, cache directories, log storage, export files, and temporary data. After a move to a new host, absolute paths are a common source of errors.
Replace old absolute paths
Paths from the old server usually do not work on the new one. Update any hardcoded directories to match the new hosting account structure. This is especially important if the app writes files outside the WAR package.
- Upload directories
- Image and document storage paths
- Log file locations
- Temporary working folders
- Backup or export destinations
If your hosting platform uses a private JVM or Tomcat instance managed by My App Server, keep file paths within directories that are available to your account and supported by the service. Avoid relying on paths that existed only on the previous server.
Prefer configurable directories
Where possible, store paths in external config files or environment values instead of hardcoding them in Java classes. This makes future migrations easier and reduces the chance of needing code changes for a simple host move.
Check environment variables and system properties
Many Java applications read runtime values from environment variables or JVM system properties. These values can define the active profile, database credentials, API keys, storage paths, or app mode.
Common values to verify
JAVA_HOMECATALINA_HOMEandCATALINA_BASESPRING_PROFILES_ACTIVEAPP_ENVor similar environment flags-DJVM options such as-Dfile.encoding=UTF-8- Custom variables used by scripts or frameworks
If you are using My App Server, check the service control and service usage settings in Plesk so the Java runtime starts with the expected values. A private JVM or Tomcat service can behave differently if the environment is missing an important variable that was present on the old host.
Match runtime options to the new server
When the app moves to a different host, the available memory, file system layout, and Java version may change. Review JVM options such as:
- Heap size settings
- Garbage collection flags
- Timezone settings
- Locale settings
- Encoding options
Keep runtime settings realistic for shared hosting or a private JVM environment. Overly aggressive memory settings can cause startup failure or instability.
Update Tomcat-specific configuration
If your Java app runs on Apache Tomcat, the migration is not complete until the container configuration is also validated. This is especially relevant when the host provides a managed Tomcat service through a control panel.
Review connector and port settings
Confirm that HTTP, HTTPS, shutdown, and AJP-related values are correct for the new service layout. In many managed hosting setups, some ports are controlled by the platform, so manual changes should be made carefully.
- HTTP connector port
- HTTPS connector port
- Redirect and secure flags
- Proxy settings if the app sits behind Apache
Check context path and deployment mapping
A moved WAR file may deploy under a different context path on the new host. Verify that the application URL matches the deployment configuration and that any links, redirects, or internal routing rules still work.
Validate datasource definitions
Tomcat applications sometimes use JNDI datasource definitions in context files or server-level config. If the database connection was previously defined in Tomcat, update the resource definition to point to the new database host and credentials.
Adjust application URLs and external service endpoints
Moved applications often fail because they still call the old site address or a test endpoint from the previous environment.
Update base URLs
Review any values that define the public base URL of the app. This can affect links, redirects, login flows, email templates, OAuth callbacks, and API responses.
- Application base URL
- Callback URLs for payment gateways or identity providers
- Webhook endpoints
- Redirect URLs used in authentication flows
Check mail and API settings
If your app sends mail or connects to external APIs, confirm the hostnames, ports, and credentials. Some services allow access only from approved IPs, so the new host may need to be added to an allowlist.
- SMTP host and port
- TLS/SSL requirements
- API base URLs
- Authentication tokens and keys
For security, rotate sensitive secrets if they were stored in the old environment in plain text or if the previous host is no longer trusted.
Use a safe update process
Changing config files after a migration should be controlled and reversible. A small mistake in one setting can prevent the application from starting, so use a methodical process.
Recommended update steps
- Create a backup of the app files and current configuration.
- List every file that contains environment-specific values.
- Change one group of related values at a time.
- Save files using the correct encoding, usually UTF-8.
- Restart or redeploy the Java service after each major change.
- Check the logs immediately for errors.
- Test database access, login, file upload, and key application paths.
Use version control when possible
If the application files are tracked in Git or another version control system, commit configuration changes separately from code changes. This makes it easier to compare the old host settings with the new ones and to roll back quickly if needed.
Keep secrets out of the WAR when possible
For security and maintainability, avoid storing passwords and tokens directly in application code. Use external config files, environment variables, or platform-managed service settings where supported by the hosting environment.
Where to look in Plesk and My App Server
In an ITA Java hosting account, My App Server is designed to make Java application management easier from Plesk. After moving an app to a new host, use the control panel to verify that the runtime service is configured correctly and that the app is deployed to the intended Java instance.
Useful checks in the control panel
- Confirm the selected Java or Tomcat version
- Check the application deployment status
- Review service control options
- Inspect limits that may affect memory or process behavior
- Verify custom app server settings if you use a manually uploaded version
If your app requires a specific Tomcat release or a custom JVM setup, confirm that the version installed on the new host matches your application requirements. A migration can expose differences between a default server image and the version the app was previously using.
Common mistakes to avoid
Most migration problems come from a few predictable mistakes. Avoiding them will save time during the first startup test.
- Leaving the old database hostname in a properties file
- Forgetting to change file paths that point to the previous server
- Using the wrong Java version for the application
- Overlooking Tomcat context configuration
- Changing config files but not restarting the Java service
- Editing the wrong copy of a file because the app has duplicate configs
- Ignoring log files after restart
- Storing secrets in plain text without reviewing security impact
If the app starts but behaves incorrectly, assume a configuration mismatch before assuming a code bug.
Troubleshooting after config updates
If the app does not start after you update the config files, use the logs to narrow down the issue quickly.
Check the application and Tomcat logs
Look for connection errors, missing file errors, permission errors, and class loading failures. These messages usually point to the exact value that needs attention.
Verify permissions
Even correct paths can fail if the Java process cannot read or write them. Ensure the app user has access to the required directories, logs, and uploaded files.
Confirm the service is running the updated version
Sometimes the configuration file was edited in one location, but the active service is still using another copy. Double-check the live deployment path and restart the correct Tomcat or private JVM service from the control panel.
Test with a minimal configuration change
If the problem is hard to isolate, temporarily simplify the config to the smallest working setup. For example, use a known-good database connection and a basic log path, then add the remaining settings back one by one.
Example checklist for a migrated Java app
- Update JDBC URL to the new database host
- Set the correct database credentials
- Replace old absolute file paths
- Review environment variables and JVM options
- Check Tomcat context and connector settings
- Confirm the Java version selected in Plesk
- Restart the My App Server service
- Test login, upload, and core application pages
- Review logs for warnings and errors
FAQ
Which config files should I update first after moving a Java app?
Start with the files that control database access and runtime values, because those are the most common reasons an app fails after migration. Then review file paths, environment variables, Tomcat settings, and external service endpoints.
Do I need to change my Java code when moving to a new host?
Usually no. In most cases, the code stays unchanged and only environment-specific settings need to be updated. Code changes are only needed if the app contains hardcoded paths or hostnames that cannot be externalized.
Why does the app still try to connect to the old database?
This usually means the JDBC URL, credentials, or JNDI datasource definition still references the previous environment. Search all config files and Tomcat resource definitions for the old host value.
Should I edit server.xml directly?
Only if your hosting setup requires it and you know the change is safe for the managed service. In many Plesk-based environments, some Tomcat settings are better managed through the control panel or service configuration instead of direct edits.
What if my app uses a private JVM with My App Server?
Then you should review both the application config and the service settings in Plesk. Make sure the selected Java version, memory options, and environment values match what the app expects.
How do I know if a path problem is causing the issue?
Check the logs for file-not-found, permission denied, or cannot create directory errors. If the app worked on the old server but fails when writing uploads or logs, path changes are a likely cause.
Conclusion
Updating config files after moving a Java app to a new host is mostly about replacing environment-specific values with settings that match the new server, control panel, and service layout. Focus on database details, file paths, runtime variables, and Tomcat configuration first. Then restart the Java service, review the logs, and test the application’s key functions.
In a managed Java hosting environment with Plesk and My App Server, this process is usually straightforward because you can control the private JVM or Apache Tomcat instance from the hosting panel. A careful config review after migration helps the app run correctly on the new host and reduces the chance of hidden references to the old environment.