How to move Java application files and configuration to a new host

When you move a Java application to a new host, the main goal is to copy not only the application files, but also the settings that make it run correctly: Tomcat configuration, JVM options, database connection details, environment variables, scheduled tasks, and any uploaded content your app depends on. If your Java hosting account uses a control panel such as Plesk with a managed My App Server setup, the migration is usually straightforward as long as you move the deployable artifact and the app-specific configuration in a controlled order.

This guide explains how to move Java application files and configuration to a new host, with practical steps for WAR-based deployments, standalone Tomcat setups, and private JVM hosting environments. It also covers common migration mistakes, checks to run after the move, and what to adjust when you are switching between Java versions or Tomcat instances.

What should be moved when migrating a Java application?

A complete Java application migration is more than copying a single WAR file. In most cases, you should review and move the following components:

Application package - WAR, JAR, exploded webapp directory, or custom application files.
Configuration files - application.properties, application.yml, XML config, .env files, or custom profile files.
Tomcat settings - context definitions, host aliases, JDBC resources, connector settings, memory options, and SSL-related configuration.
Database schema and data - MySQL/MariaDB, PostgreSQL, or other database exports and imports.
Uploaded files and runtime storage - user uploads, generated documents, caches, and persistent storage directories.
Scheduled jobs and background tasks - cron jobs, shell scripts, or application-side schedulers.
Certificates and secrets - only if your setup stores them in application-managed files and not in the hosting platform.
Log and diagnostic settings - custom log locations, rotation rules, and error-reporting paths.

If your application runs through My App Server in Plesk, some of these items are handled at service level, while others remain inside your project files. The exact split depends on whether you use a standard WAR deployment, a custom Tomcat instance, or a manually installed Java runtime.

Before you start: inventory the current application

Before copying anything, identify how the application is currently deployed. This prevents missing hidden dependencies and helps you reproduce the same runtime on the new host.

Check the application type

Confirm whether your app is:

a WAR deployed to Tomcat
a Spring Boot JAR running as a service
an exploded application directory
a JSP/Servlet project with external resources
a custom Java application started with a shell script or service wrapper

This matters because a WAR file is usually easier to move than a custom service with multiple external paths and startup scripts.

Document runtime dependencies

Write down the current:

Java version
Tomcat version
JVM options such as heap size, garbage collection flags, and encoding settings
context path
database host, database name, username, and driver version
file paths used for uploads, caches, and exports
SMTP settings, API keys, and external service endpoints

If the new host uses a different Java version or a different Tomcat instance, this inventory will tell you what must be adjusted after deployment.

Back up files and configuration from the old host

Always take a full backup before migration. Even if the application is small, configuration differences can break the deployment in subtle ways.

Export the application files

Copy the whole application tree, not only the deployable artifact. For Tomcat-based apps, this often includes:

the WAR file
the exploded webapp folder, if used
custom config directories outside the web root
upload folders
static assets generated at runtime
custom scripts used to start or maintain the app

If the app uses external storage, make sure the folder permissions and ownership are noted. A path that works on the old server may not be writable on the new one until permissions are corrected.

Save all relevant configuration files

Common files to keep are:

application.properties or application.yml
context.xml
server.xml changes, if any
web.xml
logback or log4j files
datasource definitions
service scripts and environment files

If your hosting platform provides a managed Tomcat through My App Server, some server-level files may be controlled by the platform rather than edited directly. In that case, note which settings are defined in the Plesk interface and which are stored in the application package.

Export the database

If the app uses a database, export it in a format suitable for your database engine. For example, use a logical dump for MySQL, MariaDB, or PostgreSQL. Include both schema and data unless you are moving only the application code and connecting to an already existing database.

Remember to check:

character encoding
collation
auto-increment values
stored procedures, triggers, and views
database user privileges

Prepare the new host for Java deployment

Before transferring the application, make sure the destination hosting account is ready. In a managed Java hosting setup, this usually means enabling the Java service, selecting the required Java version, and confirming that the Tomcat instance or private JVM is available.

Choose the correct Java version

Your application may depend on a specific Java runtime. Some older apps require Java 8, while newer ones may need Java 11, Java 17, or another supported release. If you are moving between hosts, verify compatibility before copying the application package.

In a Plesk-based Java hosting environment, the Java version is often selected during service setup or from the hosting control panel. When using My App Server, you can typically install a ready-made Tomcat/Java stack or configure a custom one, depending on the app requirements.

Confirm the Tomcat or JVM service

Make sure the service is available and can be controlled from the panel. If the application relies on a private JVM, confirm that the service can be started, stopped, and restarted cleanly. Test that the service is running before deploying the app.

If you are migrating from a shared host to a managed Java hosting account, it is a good idea to keep the first deployment simple: one app, one service, one context path, and one database connection.

Create the required folders

Prepare directories for:

application deployment
logs
uploads
temporary files
database dumps, if you need a staging area during import

Check write permissions on all directories that the app must access. A common source of migration failure is a missing writable folder for uploads or temp files.

Move the Java application files

Once the host is prepared, transfer the application package and related files. The exact method depends on how the app is built, but the objective is the same: preserve the file structure and make paths valid on the new server.

For WAR-based applications

If the application is deployed as a WAR, copy the WAR file to the new Tomcat deployment location or upload it through the control panel if your hosting platform supports that workflow. Some managed setups also allow deployment through the My App Server interface.

After upload, verify whether the WAR is auto-expanded or whether you need to restart the service for deployment. If you use a custom context name, confirm that the context path matches the old environment.

For exploded applications

If your app is deployed as an exploded directory, copy the full directory structure, not just the compiled classes. Keep the following together:

WEB-INF
static resources
JSP files
custom libraries
resource bundles

Exploded deployments are more sensitive to missing files, so verify file counts and directory structure after transfer.

For Spring Boot or standalone Java apps

If the application runs as a standalone JAR, move:

the JAR file
startup scripts
environment files
service definitions, if used
external config files

In managed hosting, the JAR may be started through a service wrapper or a custom JVM setup. Check whether the new host supports the same startup model before moving production traffic.

Move configuration carefully

Configuration is usually the part that breaks first after a migration. File paths, database names, and environment-specific URLs often differ from one host to another.

Update file paths

Replace old absolute paths with the new ones. Examples include:

upload directories
backup locations
temp folders
log paths
keystore and truststore paths

If possible, use configurable environment variables rather than hard-coded absolute paths. This reduces the amount of work needed during future migrations.

Review database connection settings

Change the database host, database name, username, password, and port if needed. Some hosting platforms provide a local database service, while others expect an external managed database. Make sure the JDBC driver version is compatible with your database and Java runtime.

Also confirm whether the application uses a connection pool. If it does, you may need to adjust pool size, timeout values, and validation queries for the new environment.

Check environment variables and JVM options

Many Java apps read settings from environment variables or JVM parameters. Common examples include:

-Xms and -Xmx
timezone settings
default encoding
profile selection
proxy settings
feature flags

When using a private JVM or Tomcat service in a hosting control panel, these options may be configured at service level. Recreate them carefully, especially if the old host used custom memory settings.

Review Tomcat-specific configuration

If your app depends on Tomcat settings, check these items:

context path
virtual host configuration
connector ports
JNDI resources
session persistence settings
maximum POST size
upload size limits

In a managed Tomcat environment, some of these settings may be exposed in the panel, while others remain fixed by the platform. If you used custom edits on the old server, replicate only the settings that are supported on the new host.

Import the database and verify schema consistency

After file transfer, import the database dump into the new database service. Then check that the schema and data match the old environment.

Import order matters

In most cases, the correct order is:

create the database
create the database user
assign privileges
import schema and data
run application startup checks

If the app creates tables at first startup, confirm whether it should run schema migrations automatically or whether you need to apply them manually.

Test database encoding and collation

Mismatched character encoding can cause broken text, failed logins, or corrupted multilingual content. This is especially important if the app stores user-generated content, Unicode strings, or localized data.

Make sure the database and application are both using the same expected encoding, typically UTF-8.

Deploy on the new Tomcat or My App Server instance

After the files and configuration are in place, deploy the application to the new Java service. If your hosting account uses My App Server, this typically means assigning the application to the Java service, confirming the selected Java version, and starting the instance from the control panel.

Start with one clean deployment

If possible, remove old partial deployments before testing the new one. This avoids stale class files, leftover JSP compilation artifacts, or obsolete libraries causing confusing behaviour.

A clean deployment usually means:

removing previous expanded app folders
clearing temporary deployment files
uploading the current WAR or app directory
restarting the Tomcat or JVM service

Check application logs immediately

After startup, review the logs first. They usually reveal the first problem faster than the browser does. Look for:

missing config files
classpath errors
database connection failures
permission issues
unsupported Java version warnings
port binding conflicts

If the host supports service control in the panel, use it to restart the app after fixing any problem. A controlled restart is often better than repeated manual file changes.

Common migration problems and how to fix them

Application starts but shows a 500 error

This often means the application deployed successfully, but a configuration file, database connection, or library is missing. Check the server logs and confirm that all external resources are reachable.

Files upload in the old host but not on the new one

Usually the folder is not writable or the path is wrong. Confirm ownership, permissions, and the upload path in the application settings.

Tomcat starts but the app is not available

Check the context path, deployment folder, and whether the app was expanded correctly. Also confirm that the expected port or virtual host is configured in the new environment.

Character encoding looks broken

Set the application and database to the same UTF-8 encoding, and verify JVM locale settings if needed. Hidden encoding mismatches often appear after moving between hosts.

Scheduled tasks no longer run

Recreate cron jobs or service timers on the new host. Do not assume they are part of the application package unless you explicitly migrated them.

Migration checklist

Use this quick checklist before switching traffic to the new host:

application files uploaded
configuration files updated for the new environment
database exported, imported, and tested
Java version confirmed
Tomcat or JVM service running
permissions verified on writable folders
logs checked for startup errors
uploads and static assets accessible
email, API, and third-party integrations tested
old host kept online until the new setup is validated

Best practices for future Java hosting migrations

Some preparation makes the next move much easier. Keep application-specific settings outside the codebase where possible, and use environment-based configuration instead of hard-coded host values. Store deployment notes, database credentials, and runtime requirements in an internal migration document.

If your hosting setup uses a managed Java service with Plesk and My App Server, keep a clear record of which settings are managed through the panel and which are part of the application itself. That separation saves time when you update Java versions, change Tomcat instances, or move to a different hosting account later.

For small and medium Java applications, this approach gives you the best balance of control and simplicity: a private JVM or Tomcat service, a known Java version, and a predictable deploy process for WAR, JSP, and servlet-based applications.

FAQ

Do I need to move only the WAR file?

Not usually. A WAR file is the main deployable artifact, but most real applications also need config files, database data, uploaded files, and runtime settings.

Can I reuse the same configuration on the new host?

Only if the environment is identical. In practice, you often need to update file paths, database credentials, Java version settings, and Tomcat-related values.

What if my app uses a private JVM in managed hosting?

Then you should move the application package and recreate the JVM settings in the control panel. Check memory limits, service control options, and any custom startup parameters.

How do I know if the Java version is compatible?

Review the application documentation or build settings. If the app was compiled for a specific Java release, make sure the target host supports that version before deployment.

Should I migrate the database before or after the files?

Usually files first, then database import, then final configuration checks. However, the exact order can vary if the application requires database objects to exist before first startup.

What should I check after migration?

Check the logs, login flow, database access, file uploads, scheduled tasks, email sending, and any external API integrations. These are the most common failure points after a move.

Conclusion

Moving Java application files and configuration to a new host is usually a controlled process: identify the application type, back up files and database data, prepare the new Java runtime, deploy the app, and verify every external dependency. In a managed Java hosting environment with Plesk and My App Server, the process is often easier because you can control the Tomcat or JVM service from the panel and select the right Java version without rebuilding the whole stack from scratch.

The key is to treat the migration as a complete environment move, not just a file copy. When you transfer the deployable artifact together with its configuration, paths, and data, the new host is much more likely to behave like the old one from the first start.

How to move Java application files and configuration to a new host