How to update config files after moving a JSP app to a new host in the UK

After moving a JSP application to a new host, the most common cause of failures is not the code itself but the configuration values that still point to the old environment. Database URLs, filesystem paths, mail settings, JVM options, and Tomcat context settings often need to be updated before the app will start cleanly on the new server.

In a UK hosting setup, this is especially important when the application is hosted through a control panel such as Plesk and runs on a private Tomcat instance or private JVM. The app may have worked correctly on the previous host, but small differences in the new hosting account, document root, Java version, or service layout can break it until the config files are adjusted.

What usually needs to change after a JSP migration

When you move a JSP application to a new host, review every file that contains environment-specific values. The exact file names vary from app to app, but the same types of settings appear again and again.

Common config areas to check

Database connection settings such as JDBC URL, username, password, host, port, and schema name.
Tomcat context files such as context.xml or application-specific context definitions.
Application properties files such as .properties, .xml, .yml, or .json files.
File system paths for uploads, logs, exports, temp files, or external resources.
Java and JVM options such as memory values, timezone, encoding, or system properties.
Mail server settings for SMTP host, port, authentication, and encryption.
API endpoints and credentials for third-party services, payment gateways, or SSO providers.
Application URLs such as base URL, callback URL, redirect URI, and internal service links.

If your JSP app uses My App Server in a Plesk environment, these settings may be managed partly inside the application package and partly in the service configuration. The goal is the same: make sure the new host values match the new runtime environment.

Start by identifying where the app stores environment values

Before editing anything, locate the files and places where the app keeps its configuration. In many JSP and Tomcat deployments, configuration is split between several layers.

Typical places to inspect

The application WAR or unpacked application directory.
WEB-INF/web.xml for servlet parameters and application mappings.
WEB-INF/classes for properties files and classpath resources.
Tomcat conf files such as server, context, or service definitions.
Environment variables set by the hosting service.
Custom startup scripts, if your account uses them.

If you are using a managed hosting control panel, check whether the configuration is exposed in the panel or generated by the service. In the My App Server setup, you can usually manage the runtime from the hosting account area and adjust Java/Tomcat settings without accessing system-level tools.

Update database settings first

Database connectivity is one of the most frequent breakpoints after migration. A JSP app may still start, but pages that query the database will fail with connection errors, login issues, or timeouts if the connection details are outdated.

What to update in database config files

JDBC host: point to the database host for the new account.
JDBC port: confirm the correct port, especially if the database is remote or custom.
Database name: match the database created on the new host.
Username and password: use the new credentials.
Driver class: confirm the driver still matches the database type.
Connection pool settings: check timeouts, validation queries, and max connections.

Example values you may need to replace include:

jdbc:mysql://old-host:3306/old_db
jdbc:postgresql://old-host:5432/old_db
spring.datasource.url
db.username and db.password

After updating these values, make sure the database user has the required permissions on the new schema. Even a correct JDBC URL will fail if the account cannot read or write the needed tables.

Check Tomcat and My App Server context configuration

When JSP applications are hosted through Tomcat, the context configuration often controls how the app sees its database, external resources, and deployment path. If you moved the app to a new host, the context definition may also need to be updated.

Settings that commonly change in context files

DocBase or application path.
Resource definitions for datasource entries.
Environment entries for app-specific values.
Realm or authentication settings if the app uses container-managed security.
JNDI names for database or mail resources.

In a My App Server environment, Tomcat may run as a private service under your hosting account. That is helpful because it gives you control over the Java runtime and deployment process, but it also means any old path or service value from the previous host should be reviewed carefully.

Example of a setting to verify

path or docBase points to the correct application directory.
Resource entries reference the right DB connection name.
useNaming and related options match how the application was built.

Update file paths and permissions

Applications often fail after migration because the new server does not have the same directory layout. A path that worked on the old host may be invalid on the new one, or the files may exist but the Java process cannot read or write them.

Paths to review carefully

Upload directories for user files.
Log directories used by the application.
Export or report directories.
Temporary directories for image processing or document generation.
External configuration directories mounted outside the WAR.

When you edit these values, keep them relative where possible. Absolute paths are more likely to break when moving between hosts. If absolute paths are necessary, update them to match the new hosting account structure.

Also confirm permissions. In a shared hosting environment with a private JVM or private Tomcat instance, the service account must be able to read the WAR, create logs, and write to any required folders. If permissions are too restrictive, the app may start but still fail during upload or logging operations.

Review JVM options and startup parameters

Java applications may rely on JVM options set at startup. These values can affect memory usage, encoding, timezone, SSL behavior, and application-specific system properties.

Common JVM values to verify

-Xms and -Xmx memory settings.
-Dfile.encoding for character encoding.
-Duser.timezone if the app depends on UK time or another specific zone.
-Djava.io.tmpdir for temporary file handling.
Custom system properties used by the application.

If the application was moved to a new host with different available resources, you may need to reduce memory settings slightly or align them with the hosting limits. In a managed hosting setup, the service controls available RAM and CPU usage, so the safest approach is to keep JVM settings within the published service limits.

If you are using My App Server, adjust the service settings from the hosting panel rather than hardcoding values in the app whenever possible. That keeps the deployment cleaner and makes later changes easier.

Replace hardcoded URLs and callback endpoints

Many JSP applications contain URLs that work only in the old environment. After migration, these values should be updated so users, APIs, and internal integrations point to the new host.

Examples of values to search for

Site base URL.
Login redirect URLs.
OAuth callback or SSO redirect URIs.
Webhook URLs.
Internal service endpoints.
Absolute links embedded in templates or properties files.

For UK-facing applications, make sure any domain changes, HTTPS paths, and callback URLs are aligned with the live site address used after the move. If the old host used a temporary address for testing, remove it from production config files before going live.

Adjust mail and notification settings

If the application sends emails, update the SMTP settings after migration. A host move often changes the mail server host name, authentication method, or allowed sender addresses.

Mail settings to review

SMTP server host.
SMTP port.
Username and password.
STARTTLS or SSL requirements.
From address and reply-to address.
Connection timeout and read timeout values.

If the app uses the server's local mail service, make sure the new host allows that method. If it uses an external mail provider, confirm the credentials and sender policy still match the provider’s rules.

Use a safe editing process

Config file changes should be made carefully. A small typo can stop the application from deploying, which is why a controlled update process is important.

Recommended update steps

Create a backup of the original config files before editing.
List all environment-specific values that need to change.
Update one file at a time so you can isolate problems quickly.
Validate syntax if the file format requires it, such as XML or JSON.
Restart or reload Tomcat after the changes.
Check logs immediately for startup errors or missing resources.
Test the key application flows such as login, database writes, and file uploads.

If the app is deployed through a Plesk-managed Java hosting service, restart the private service from the control panel after saving the changes. This ensures the new values are loaded by the runtime.

How to search for old host values quickly

Large applications can store config values in more than one place, so manual checking is often not enough. Search the full application package for references to the old host name, old domain, old database name, or old file path.

Search terms worth checking

Old domain name.
Old server name.
Old database host.
Old database name.
Old filesystem path.
Previous email host.
Legacy API endpoint.

If your hosting plan gives access to file management in the control panel, you can inspect the application files directly there. For more complex apps, download a copy, search locally, and then upload only the changed files.

Check configuration outside the WAR file

Not every JSP application keeps its settings inside the deployed WAR. Some applications load external config files from a separate directory so that values can be changed without rebuilding the application.

External locations may include

Custom properties files outside the web root.
Tomcat environment definitions.
Service-specific config folders under the hosting account.
Files referenced through system properties.

This approach is useful in a hosting environment, but it also means that moving the app to a new host may require copying both the application package and the external config directory. If the application starts but behaves as though settings are missing, check whether it is still looking at the old external path.

Test after every config change

After updating config files, do not assume the move is complete. Test the areas most likely to fail when environment values are wrong.

Suggested test checklist

Application starts without deployment errors.
Home page loads correctly over HTTPS if enabled.
Login works and sessions remain stable.
Database reads and writes succeed.
File uploads are stored in the right directory.
Email notifications are sent successfully.
Reports, exports, and downloads use valid paths.
Background jobs or scheduled tasks run as expected.

For JSP hosting on a private Tomcat instance, the logs are your best source of truth. Review the application log, Tomcat log, and any service log shown in the control panel. Errors like missing properties, invalid datasource names, and permission denied messages usually point directly to the config item that needs attention.

Example migration checklist for a JSP app

Use the following checklist as a practical reference when moving a JSP application to a new host:

Back up the application and all config files.
Copy the WAR or application directory to the new hosting account.
Update database connection details.
Check JNDI names and Tomcat context settings.
Replace old domain and callback URLs.
Review file paths for logs, uploads, and temp folders.
Adjust SMTP settings if the mail service changed.
Confirm Java version compatibility.
Set JVM options appropriate for the new service limits.
Restart Tomcat or the My App Server service.
Test the application and monitor the logs.

Common problems and what they usually mean

Database connection refused

The JDBC URL, port, host, or credentials are wrong, or the database user does not have access from the new host.

Application starts but pages show errors

Core config values may still be pointing to the old environment, or an external resource is missing.

File not found or permission denied

The path changed during migration, or the Tomcat service cannot write to the target folder.

Mail sending fails

SMTP host, port, or authentication settings need to be updated for the new environment.

JSP pages render incorrectly

Encoding, locale, or timezone settings may need to be aligned with the application’s expectations.

FAQ

Do I need to edit every config file after moving a JSP app?

Not always. Focus on files that contain environment-specific values such as database hosts, paths, URLs, mail settings, and JVM options. Some apps only need a few small changes, while others keep settings in several files.

Should config values be stored inside the WAR file?

It depends on the application design. For simple deployments, some settings are bundled in the WAR. For easier maintenance, many hosting setups keep sensitive or environment-specific values outside the WAR so they can be changed without rebuilding the app.

What should I check first if the app does not start after migration?

Start with the application log and Tomcat log. Then verify the database settings, file paths, and any external config references. A startup failure is often caused by a missing property, invalid XML, or a path that no longer exists.

Can I change Java version after moving the app?

Yes, if your hosting platform and application support it. In a My App Server setup, the Java version can often be selected or adjusted from the hosting panel. Always test the app after switching versions, because some older JSP applications depend on a specific release.

What if my old host used a different Tomcat layout?

Then review the context configuration carefully. Paths, service names, and JNDI resources may not match the new Tomcat layout. Keep the app’s settings aligned with the structure used by the new hosting service.

Is it safe to edit config files directly in production?

It is safer to back up the files first and make changes during a maintenance window. If possible, test the same changes in a staging copy before applying them to the live site.

Conclusion

Updating config files after moving a JSP app to a new host is usually the difference between a smooth migration and a broken deployment. The main goal is to replace every old environment value with the correct settings for the new hosting account: database access, Tomcat context data, file paths, mail settings, URLs, and JVM options.

In a UK JSP hosting environment with Plesk and My App Server, this process is straightforward when you work methodically. Back up the files, identify all environment-specific values, update them one by one, restart the service, and check the logs. With a careful approach, most JSP and servlet applications can be moved successfully with only a limited set of configuration changes.

How to update config files after moving a JSP app to a new host in the UK