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

If you are moving a Tomcat-based application to a new host, the safest approach is to separate the migration into three parts: your application files, your Tomcat configuration, and any external data such as databases or uploaded content. On a hosting platform that provides Java hosting through a control panel such as Plesk, this usually means copying the deployable web application, re-creating the runtime settings, and confirming that the new environment uses the same Java and Tomcat version or a compatible one.

In a managed hosting environment with My App Server, you can run your own Apache Tomcat instance or private JVM inside your hosting account, which makes migration much more practical than on a shared setup without Java tools. The key is to move the right files, not the whole server installation blindly. A clean migration reduces downtime, prevents permission issues, and helps you avoid configuration mismatches that can break a JSP, servlet, or WAR-based application after the move.

What you need to identify before migration

Before copying anything, confirm how your Tomcat application is built and where each part lives. Tomcat applications are often made of more than just the deployed web folder. Typical items include:

WAR file or an exploded application directory
Application configuration files such as .properties, .xml, .yml, or .env files
Tomcat configuration such as server.xml, context.xml, web.xml, or application-specific context settings
Database connection settings and JDBC driver references
Uploaded files, media, cache, or generated content outside the compiled application
Scheduled tasks, if your application depends on them
Java version and Tomcat version used on the old host

If you are using a hosting control panel like Plesk with a Tomcat or Java service managed through a custom extension, it is important to note whether the application was deployed as a WAR package, as a file-based project, or through a custom app server configuration. That will determine whether you can redeploy from source, reuse the existing WAR, or only move selected runtime files.

Recommended migration strategy

The most reliable method is to treat the source host as the reference point and rebuild the same application structure on the new host. In practice, this means:

Export or copy the application artifact, usually the WAR file or the deployed application directory.
Collect custom configuration files that are not part of the build output.
Document the Tomcat settings that were changed manually.
Prepare the database on the new host and update connection details.
Deploy the application in the new control panel environment.
Test logs, URLs, permissions, and data access before switching traffic.

This approach is safer than copying the entire old Tomcat installation. A full server copy may include machine-specific paths, obsolete libraries, hardcoded usernames, or service settings that do not match the new hosting account. On managed Java hosting, it is better to let the platform provide the runtime and only migrate the application layer and its dependent data.

Step 1: Back up the application files

Start with the deployable application files. For most Tomcat deployments, this is either a single .war file or the expanded web application directory, often found under a webapps location on the source server.

If you have a WAR file

If your application was originally deployed from a WAR, use that as the starting point. A WAR file is usually the cleanest artifact to move because it contains the packaged application in a portable format. If the WAR was generated by your build system, it is usually better to redeploy that exact artifact instead of copying generated folders from the server.

Keep in mind that the WAR file may not contain:

database records
external configuration files placed outside the app package
user uploads stored on disk
Tomcat-specific runtime edits made after deployment

If you have an exploded application

If Tomcat is using an exploded directory, copy the complete application folder, but review its contents carefully. Some files inside may be generated at runtime, such as compiled JSP classes, caches, temporary files, or logs. These should not usually be migrated unless you specifically need them for troubleshooting.

Focus on the folders and files that are part of the application itself, especially:

WEB-INF/classes
WEB-INF/lib
application resource files
static assets
uploaded content stored under the web root or a separate data path

Step 2: Copy custom configuration files

Tomcat applications often rely on configuration files that are not included in the WAR, or are overwritten during deployment. These may control database URLs, email settings, file paths, API keys, or environment-specific values.

Check both the application directory and any external configuration locations used by your old host. Common examples include:

application.properties
config.xml
context.xml
server.xml
logging.properties
JNDI resource definitions

If your application used separate configuration for development, staging, and production, make sure you migrate the correct production profile. Many migration problems happen because a test configuration is copied to the live host, or because the app still points to the old database host after deployment.

On a platform such as Plesk with My App Server, some settings may be controlled through the hosting panel instead of directly editing Tomcat files. In that case, replicate the equivalent setting in the panel rather than editing hidden system files manually. This makes the deployment easier to maintain and reduces the risk of configuration drift.

Step 3: Move database-related changes

For many Tomcat applications, the database is the most critical external dependency. Moving the application files alone is not enough if the app reads or writes structured data from MySQL, MariaDB, PostgreSQL, or another database service.

Plan for the following:

export the database from the old host
create the database on the new host
import the data
update the JDBC connection string
verify the database username and password
check character set and collation settings

If your application uses a JDBC connection pool or JNDI resource, confirm that the resource name and driver class are still correct on the new platform. A missing JDBC driver is a common cause of startup failures after migration.

Also check whether your application stores upload paths or generated files in the database. Some systems keep only metadata in the database while actual files are stored on disk. In that case, both the SQL dump and the physical file storage must be moved together.

Step 4: Match Java and Tomcat versions

Java applications can behave differently depending on the runtime version. Before moving the site, confirm the Java version used by the old host and the version available on the new host. A Tomcat application built for an older Java release may fail if the runtime is too new, and the opposite can also happen if the code expects newer language features or libraries.

With My App Server, you can often choose from several ready-made Java or Tomcat versions, or upload and configure a custom version if needed. This is useful when the application has a strict runtime requirement. Still, the best practice is to avoid depending on a very specific version unless your application truly needs it.

Check these points:

Java major version compatibility
Tomcat major version compatibility
Servlet and JSP API expectations
third-party library compatibility
any deprecated settings in the old server

If you do not know the exact runtime details, review startup logs from the old environment or check the hosting panel where the service was configured.

Step 5: Recreate the deployment on the new host

Once the files and database are ready, deploy the application on the new host. In a control-panel-based Java hosting setup, this usually means using the Tomcat or app server management interface to upload the WAR or point the service to the application directory.

A typical deployment flow looks like this:

Open the Java or Tomcat management section in the control panel.
Create or select the target app server instance.
Set the required Java version.
Upload the WAR file or deploy the application directory.
Set any context path, virtual host, or document root mapping.
Add environment variables or connection settings if required.
Start or restart the service.

If the application depends on a private JVM or a separate Tomcat instance, ensure that the service is assigned correctly and that the account has permission to manage it. This is especially important on shared hosting where the Java runtime is isolated per customer account rather than installed globally.

Step 6: Verify file paths and permissions

After deployment, check file permissions carefully. Many Tomcat applications fail because the runtime cannot read configuration files, write temporary data, or access uploaded content.

Verify these items:

the application can read its config files
the Tomcat process can write to upload and temp directories
log files are writable if the app writes to its own log location
directories referenced in the code exist on the new host
path separators and absolute paths are valid for the server environment

If the old application used Windows-style paths, local drive letters, or system-level directories, those values will usually need to be changed before the app can run correctly on the new host. On Linux-based hosting, relative paths or configurable external paths are usually safer.

Step 7: Review logs immediately after the first start

Logs are the fastest way to find migration issues. Start Tomcat and inspect the application logs, service logs, and any server startup output. Common problems include:

missing class or JAR file
invalid database credentials
wrong context path
port conflict or failed service startup
file permission error
unsupported Java version
broken path to an external configuration file

Pay close attention to the first error in the log chain. Later errors are often caused by the initial failure. If the application starts but pages return 404 or 500 errors, test the deployment path, application context, and servlet mappings.

Step 8: Test functionality before switching DNS

Do not switch live traffic until the application works on the new host. Test the most important flows first:

home page and login page
database reads and writes
file upload and download
form submission
admin functions
email notifications, if used
scheduled or background tasks, if applicable

If you have a staging URL or temporary domain in the hosting platform, use that to validate the site before changing the live hostname. This is especially useful for Java applications that may require multiple restarts while you adjust configuration.

Common files that are usually safe to move

For a Tomcat migration, these are often safe and useful to transfer:

WAR package generated by your build process
application source-controlled configuration files
SQL export of the application database
upload or media folders used by the application
custom JAR libraries if they are not available through dependency management
context-specific settings needed for deployment

Files you should usually not copy directly

Some server-side files are better recreated than copied from the old machine:

temporary JSP compilation folders
runtime cache directories
old log files
machine-specific service definitions
server-wide Tomcat binaries from a different installation layout
files containing old absolute paths that no longer exist

In managed hosting, the runtime is often preinstalled or controlled by the platform. Copying the entire Tomcat distribution may create conflicts with the host-managed service. Use the control panel options instead of overwriting system-managed components.

Example migration checklist

Confirm current Java version and Tomcat version.
Back up WAR, config, database, and upload folders.
Export external settings and note any environment variables.
Create the target app server instance in the hosting panel.
Select a compatible Java runtime.
Upload or deploy the application.
Restore the database.
Update connection strings and paths.
Verify file permissions.
Review logs and fix startup errors.
Test application features.
Update DNS or routing only after validation.

How this works in a hosting control panel environment

When Tomcat is managed through Plesk and a Java extension such as My App Server, migration is usually easier than on a bare server because the control panel gives you a clear place to manage runtime settings. You can create or select the app server, choose an available Java version, deploy the application, and restart the service from the panel.

This model is well suited to Java hosting for small and medium applications that need a private JVM, Tomcat hosting, JSP hosting, or servlet hosting without the complexity of a large enterprise application platform. It is especially useful when you need to move an application from another provider and want a clear path for redeployment and validation.

If your old host used a custom Tomcat setup, do not assume every internal file should be transferred one-to-one. Instead, map the old runtime settings to the new panel-managed service. That usually leads to a cleaner and more stable result.

FAQ

Should I move the whole Tomcat installation?

Usually no. It is better to move the application, configuration, and data, then recreate the runtime on the new host. Copying the full Tomcat installation often brings unnecessary system-specific files with it.

Is a WAR file enough for migration?

Sometimes yes, but not always. A WAR file may not include external configuration, uploaded files, or database data. Check whether your application stores anything outside the package.

What if my application uses a custom Tomcat version?

Choose a compatible version on the new host if possible. If the hosting platform supports custom app servers, you may be able to upload or configure the required version manually. Always test compatibility before going live.

Do I need to move the database separately?

Yes, in most cases. The application files alone do not contain live data. Export the database from the old environment and import it on the new host before testing the application.

Why does the app work locally but fail after migration?

The most common reasons are different Java or Tomcat versions, missing config files, wrong database credentials, or permissions on directories the app needs to read or write.

Can I keep the same domain name after moving?

Yes. Usually you update the DNS or hosting routing after the new site is tested. During the move, you can use a temporary URL or staging domain for verification.

Conclusion

Moving Tomcat application files and configuration to a new host works best when you migrate in layers: application package, custom config, database, and runtime settings. In a managed Java hosting environment with Plesk and My App Server, this becomes a practical process because you can rebuild the Tomcat service, choose a compatible Java version, and deploy the application without handling the entire server stack manually.

For the smoothest migration, avoid copying temporary files and old server internals, test the application on the new host before switching traffic, and use logs to fix any version, path, or permission issues early. That approach gives you a cleaner move and a more stable Tomcat deployment on the new platform.

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