How to move JSP application files and configuration to a new host in the UK

When you move a JSP application to a new host, the safest approach is to treat it as four separate tasks: copy the application files, recreate the Tomcat or Java runtime settings, move the database, and verify the web server integration. On a managed hosting platform with Plesk and a Java service such as My App Server, this is usually straightforward if you plan the migration in the right order and keep a copy of the old setup for reference.

This guide explains how to move JSP application files and configuration to a new host in the UK, including common Tomcat paths, deployment formats such as WAR, and the most important checks before you switch DNS or open the site to users. It is written for shared hosting or managed Java hosting accounts where you control your application through Plesk, and where you may be using a private JVM or a dedicated Tomcat instance for one account.

What should be moved during a JSP migration

A JSP application is often more than just .jsp files. In practice, you usually need to move several components together so the application behaves the same on the new host.

Typical files and settings to collect

Application source files: JSP, Java classes, static assets, images, CSS, JavaScript.
Build output: WAR files, compiled classes, and generated resources.
Tomcat configuration: context files, server settings, connectors, JVM options, and environment variables.
Application configuration: database connection strings, mail settings, API keys, file paths, and feature flags.
Database dump: MySQL, MariaDB, PostgreSQL, or another supported database export.
Scheduled tasks or background jobs, if the application uses them.
SSL certificates or hostname-related settings, if your app depends on a specific HTTPS URL.

If you are moving from one hosting provider to another, do not assume that the old Tomcat installation layout will match the new one. Even when the application is identical, file paths, Java version, context naming, and permission handling can differ.

Check the target hosting environment first

Before copying anything, confirm how the new hosting account is set up. In a Plesk-based Java hosting environment, a service such as My App Server may let you install and manage a private Tomcat or private JVM from the control panel. That means your app can run with its own Java version and service settings rather than relying on a shared system-wide Tomcat.

Points to verify in the new account

Which Java versions are available for installation.
Whether your app will run in a private Tomcat instance or under a shared service model.
The document root or application base directory used by the control panel.
Whether WAR upload and automatic deploy are supported.
Any resource limits such as memory, CPU, inodes, or process limits.
Database access details and whether remote connections are allowed.
Domain mapping and SSL setup for the new hostname.

If the new host uses a different Java version, test compatibility early. JSP applications built for older Java releases may need changes if the new environment runs a newer JDK or Tomcat release.

Locate the application files on the old host

The first practical step is to identify where the application lives on the old server. For Tomcat-based JSP hosting, the structure is usually one of the following:

A deployed WAR file in a Tomcat webapps directory.
An exploded application folder with JSP, WEB-INF, and static files.
A project source tree that is built externally and then uploaded as a WAR.
A custom context path mapped through a context configuration file.

Common folders to check

webapps/ for deployed application archives and expanded folders.
WEB-INF/ for classes, libraries, and deployment descriptors.
conf/ for Tomcat-level settings.
logs/ for access and error logs that help you verify the migration.
lib/ for shared JAR dependencies.
Any custom directory referenced in the application context configuration.

If you are not sure which files are required, compare the deployed application directory with your source control repository or build output. It is usually better to migrate the clean build artifact rather than a mixed folder full of temporary files.

Back up the current application before making changes

Do not start the move with a partial copy. Create a complete backup of the live application state so you can roll back if something is missing on the new host.

Recommended backup items

The deployed application directory or WAR file.
Tomcat configuration files that were changed from defaults.
Database export from the production database.
Any uploaded user files or attachments stored outside the application.
Log files for troubleshooting after the move.

It is also useful to write down the current application URL, admin paths, datasource names, and any cron or scheduled task settings. These details often matter later when the application starts but fails to connect to the database or send email.

Move JSP application files to the new host

How you transfer the files depends on how the app is packaged. In many hosting environments, the cleanest route is to deploy a WAR file directly into the Java service or upload it through the control panel. If the application is not packaged as a WAR, you can copy the source or exploded directory and rebuild it on the new host if your setup allows that.

Option 1: Deploy a WAR file

If your application is already built as a WAR, this is usually the simplest migration method:

Stop the application or place the old site in maintenance mode if needed.
Copy the latest WAR file from the old environment or build pipeline.
Upload the WAR to the new host using Plesk, FTP, SFTP, or the deployment function in your Java hosting control panel.
Confirm that the WAR name matches the desired context path if the platform uses file-name-based deployment.
Restart the application service if required.

For example, if the file is named shop.war, the app may deploy under /shop. If you need a different path, rename the archive before upload or use the context settings provided by the hosting platform.

Option 2: Move an exploded application directory

If the app is deployed as an expanded folder, copy the whole directory structure, including:

JSP files
HTML, CSS, JS, and image assets
WEB-INF/web.xml
WEB-INF/classes
WEB-INF/lib

Keep the directory names and file permissions consistent. On managed hosting, ownership and access rights may be set differently after upload, so verify that Tomcat can read the files and write to any directories it needs for uploads or cache files.

Option 3: Rebuild from source on the new host

If your application uses Maven, Gradle, or another build tool, it may be better to upload the source repository and create the WAR in the new environment. This can reduce hidden differences caused by moving compiled files from an older Java version.

This approach is useful when:

You need to change Java or Tomcat versions.
The old deployment contains stale compiled classes.
You want to reproduce the build exactly on the new host.

Recreate Tomcat and JVM configuration

The most common migration errors happen when the files are copied correctly but the runtime settings are not. JSP applications often depend on Java system properties, memory settings, server ports, or context attributes. On a hosting platform with My App Server, these are usually managed through the control panel rather than by editing server files directly.

Configuration items to compare

Java version and vendor.
Tomcat version.
Heap size and GC-related JVM flags.
Server port assignments if the application uses non-default connectors.
Context path and document base.
Datasource definitions and JNDI names.
Environment variables and system properties.
File upload and temp directory paths.

If your old host used custom JVM arguments such as memory tuning or encoding flags, document them before the move. Then apply only the values that are still valid for the new Java version. Some parameters may no longer be needed or may be rejected by a newer runtime.

Common JSP and Tomcat settings to review

-Dfile.encoding=UTF-8 if the app expects UTF-8.
Heap settings such as -Xms and -Xmx.
Session timeout values in web.xml.
Upload directory paths if files are stored on disk.
Proxy or forwarded headers if the app sits behind Apache.

If the new hosting platform runs Apache in front of Tomcat, check whether the application needs to detect HTTPS correctly. Some applications need proxy-related settings so generated links and redirects use the right scheme and host.

Move application-specific configuration carefully

Application configuration usually contains environment-specific values. These are often the main things that must change during a host migration. It is best to separate configuration from code wherever possible so the move is easier and safer.

Examples of configuration that often changes

Database host, database name, username, and password.
Email SMTP server, port, username, and sender address.
Absolute file paths for uploads, exports, or cache directories.
API endpoints for payment gateways or third-party services.
Base URL or canonical hostname.

Check files such as application.properties, .properties, .xml, .yml, or custom environment files. Also inspect any settings stored in the database if your application keeps configuration there.

Good practice for config migration

Keep a separate production config file for each environment.
Avoid hardcoding old hostnames or absolute paths in JSP files.
Use environment variables or control panel settings when possible.
Replace local or provider-specific URLs with the new hostname before launch.

Move the database and update connection settings

Many JSP applications depend on a database, so moving the code without moving the data will only give you a partial migration. Export the database from the old host and import it into the new database service before the switch.

Basic database move process

Create a full export or dump of the source database.
Create a matching database and user on the new hosting account.
Import the dump into the new database.
Update the application configuration with the new connection details.
Test basic read and write operations.

If the application uses JNDI datasource configuration in Tomcat, ensure the new host has the correct datasource name and driver JAR installed. If it uses direct JDBC connections from a properties file, make sure the JDBC driver version is compatible with the target Java version.

Things to check after import

Table collation and character set.
User privileges.
Stored procedures or triggers, if used.
Timestamp and timezone handling.
Any large BLOB or file reference data.

When the source and destination database engines differ, test carefully. Even small differences in SQL dialect, reserved words, or date handling can break a JSP application during runtime.

Adjust file permissions and writable directories

After the files are uploaded, verify that the application can read the deployed classes and write to the folders it needs. This is especially important for file uploads, temporary files, caches, and generated reports.

Common writable areas

Upload directories for user-submitted files.
Temp directories used by the application or Tomcat.
Cache folders.
Export or report output paths.

On a managed hosting platform, permission handling may be controlled by the panel or service wrapper. If the app starts but fails when users upload files or generate reports, permissions are one of the first things to inspect.

Test the application before changing DNS

Always test the new host before directing live traffic to it. This lets you fix path issues, missing JARs, wrong Java settings, or database errors without affecting users.

What to test first

Home page and main JSP pages.
Login and session handling.
Database-driven forms and search.
File upload and download features.
Email notifications.
Admin pages or scheduled tasks.

Check the Tomcat or application logs immediately after each test. Logs usually point to missing classes, failed datasource connections, or path problems much faster than the browser does.

Useful log clues during migration

ClassNotFoundException for missing libraries.
SQLException for bad database credentials or unreachable database service.
Permission denied for files and directories.
Unsupported major version error if Java is too old or too new.
404 errors if the context path changed.

Switch the domain when the new host is ready

After the application works correctly on the new host, update DNS or change the domain routing. If you are using a temporary preview URL, verify that absolute links, redirects, and embedded resources still work once the real domain is active.

At this stage, keep the old host active for a short overlap period if possible. That gives you a fallback in case a background process, cron job, or rarely used admin function still points to the old environment.

Recommended migration checklist

Export the application code or WAR file.
Back up Tomcat settings and JVM options.
Export the database.
Install the required Java version on the new host.
Deploy the WAR or upload the application files.
Recreate datasource and environment settings.
Import the database.
Set permissions for writable directories.
Test key user flows.
Review logs and fix startup errors.
Update DNS only after successful testing.

Common mistakes to avoid

JSP migrations often fail for simple reasons that are easy to miss. Avoid these common issues:

Copying only JSP files and forgetting WEB-INF or library JARs.
Using the old database credentials after the move.
Deploying a WAR built for a different Java version.
Forgetting to recreate custom JVM arguments.
Ignoring file permissions for uploads and temporary files.
Leaving old absolute paths in config files.
Switching DNS before the new app has been fully tested.

If your application worked on the old host but fails on the new one, compare runtime settings first rather than rebuilding the code immediately. In many cases the issue is a missing config value, an incorrect context path, or a database setting that was not copied across.

FAQ

Should I move JSP source files or the compiled WAR?

If you already have a stable build process, moving the WAR is usually the easiest and cleanest option. If you need to change Java versions or Tomcat settings, rebuilding from source on the new host can be safer.

Do I need to move Tomcat configuration as well?

Yes, if your application depends on custom context settings, datasource definitions, JVM options, or other non-default configuration. The files alone are often not enough.

Can I run a private JVM for one JSP application in shared hosting?

In a Java hosting setup built around Plesk and a service such as My App Server, it is often possible to run a private JVM or private Tomcat instance inside the hosting account. This is useful for small and medium JSP applications that need control over Java version and service settings.

Why does my app work on the old host but not on the new one?

Most migration problems come from differences in Java version, Tomcat version, database credentials, paths, or permissions. Check logs first, then compare the old and new environment line by line.

What is the safest way to change the site to the new host?

Test the app on the new host using a temporary URL or hosts file entry, confirm database access and login flows, then update DNS. Keep the old environment available for a short time in case you need to compare settings.

Conclusion

Moving JSP application files and configuration to a new host is usually manageable when you separate the process into files, runtime settings, database, and verification. In a Plesk-based Java hosting environment with My App Server, you can often deploy a private Tomcat or private JVM, choose the required Java version, and manage the service from the control panel, which makes migrations more practical for JSP, servlet, and WAR-based applications.

The key is to preserve the original application behavior while adapting the configuration to the new host. Copy the right files, recreate the Tomcat and database settings, test before DNS changes, and review the logs carefully. That approach reduces downtime and helps your JSP application move to the new hosting account with fewer surprises.

How to move JSP application files and configuration to a new host in the UK