If you are moving a Java application to a new host, the safest approach is to treat the migration as three separate tasks: move the application files, move the configuration, and verify the runtime that will execute the app. In a hosting and Plesk environment, that usually means checking your WAR or exploded application folder, Tomcat settings, environment variables, database connection details, and any Apache or proxy rules that sit in front of the app.
For Java hosting on a shared hosting account with a private JVM or Tomcat instance, the goal is usually to recreate the same application behaviour on the new platform rather than to copy every file blindly. That is especially important when the application was built with absolute paths, external config files, or database credentials stored outside the project directory. A clean migration reduces downtime and helps you avoid startup errors after deploy.
What should be moved to the new host
Before you begin, identify the parts of the application that actually belong in the migration. In most Java and Tomcat hosting setups, these are the items you will need to transfer or recreate:
- Application build output such as a WAR file, JAR file, or compiled classes and web resources.
- Static content including uploaded files, images, documents, and user-generated assets.
- Configuration files such as
application.properties,application.yml, XML config, or custom environment files. - Tomcat configuration such as context settings, datasource definitions, JVM options, and server port values.
- Database schema and data if the application stores content in MySQL, MariaDB, PostgreSQL, or another database.
- SSL, proxy, and Apache-related rules if the application depends on a hostname, reverse proxy, or custom rewrite setup.
Do not assume that the source code itself needs to be copied to production. In many cases, the new host only needs the packaged application, runtime config, and external resources. If your app is deployed from a CI pipeline, you may only need to transfer the final artefacts and connection settings.
Check the target Java hosting setup first
On the new host, confirm how Java applications are managed. In a managed hosting environment with Plesk and My App Server, you may have the option to install a ready-made Tomcat version or upload and configure a custom app server. That matters because the version of Java, Tomcat, and the service layout must match the expectations of your application.
Review the following before copying anything:
- Which Java version is available and supported.
- Which Tomcat version or private JVM instance will run the app.
- Whether the application will be deployed from a WAR file or from an unpacked directory.
- Where logs are stored and how service control works in the control panel.
- Whether your app needs a separate database, cache, or storage volume.
If your application runs on a specific Java release, confirm that the target host can use a compatible version. Even small version differences can affect libraries, TLS behaviour, date handling, or startup parameters. When possible, match the major Java version used on the old host before you upgrade the application stack.
Back up the source host before migration
Always create a full backup before making changes. Even when the move seems simple, a single missing config file or wrong path can break startup. A proper backup gives you a rollback option if the first deploy fails.
Back up these items from the old host:
- The deployed application directory or WAR file.
- Any external config files outside the web app folder.
- Database dumps or export files.
- Upload directories and user files.
- Tomcat context files, server config, and custom JVM options.
- Apache or proxy rules that route traffic to the app.
It is a good idea to keep the backup structure organised. For example, store application files, config, and database exports in separate folders so that you can restore only what is needed during testing.
Move the Java application files
In most hosting migrations, application files are transferred first. The exact method depends on how the app was packaged originally.
If your app is deployed as a WAR file
A WAR file is the simplest format to move. Copy the WAR to the target Tomcat deployment location or upload it through the control panel if your hosting platform supports it. After upload, deploy the application and verify that Tomcat expands it correctly.
When using a managed hosting panel, check whether the service expects a specific application name. The context path often follows the WAR filename, so a file named app.war may be available at /app unless the platform allows custom context mapping.
If your app is unpacked into a directory
If the application is deployed as an exploded folder, copy the full directory structure, including:
WEB-INF- static assets
- uploaded files
- custom libraries placed in the web app
Be careful not to miss hidden or nested folders. Some frameworks store compiled templates, temporary files, or resource bundles in directories that are easy to overlook. If the old environment contains generated files that the app expects at startup, move them as well.
If you use external storage for uploads
Many Java applications keep uploaded files outside the deployed app so they survive redeploys. If that is the case, replicate the same directory structure on the new host and update the config to point to the new path. Do not hardcode the old filesystem path unless the new host uses the same layout.
In a Plesk-based Java hosting setup, external storage is often best placed in a dedicated data directory rather than inside the Tomcat deployment tree. That keeps files stable when the application is redeployed.
Migrate configuration carefully
Configuration is where most Java migration issues happen. An application may run perfectly on the source host and fail on the new host because of one changed path, missing variable, or old database URL.
Review application properties
Check all config files used by the app, including:
- database connection settings
- SMTP settings
- file storage paths
- base URLs and domain names
- API keys and secrets
- logging paths
- timezone or locale settings
Replace source-host-specific values with the new environment values. If you are moving to a new domain, update any absolute URLs stored in config files or database records. This includes callback URLs, redirect URLs, and links generated by the application.
Move Tomcat-specific settings
Some Java apps rely on Tomcat context files or server settings. Depending on your setup, this may include:
context.xmlor per-app context definitions- JNDI datasource configuration
- JVM heap settings
- system properties passed at startup
- custom environment variables
If your app uses a datasource, make sure the database resource is recreated on the new host and that the resource name matches what the application expects. A missing JNDI entry is a common cause of startup failure after migration.
Adjust environment variables and startup parameters
Some applications need JAVA_HOME, CATALINA_BASE, memory flags, or custom -D properties. If the new hosting platform manages Tomcat through a control panel, enter those values in the service settings rather than editing low-level system files directly.
Typical values that may need review include:
- heap size flags such as
-Xmsand-Xmx - garbage collection options
- timezone settings
- encoding settings
- application-specific feature toggles
Keep the settings as close as possible to the old host during the first test run. After the application starts successfully, you can fine-tune memory usage and performance.
Move the database and update connection details
If the application depends on a database, you should migrate the schema and data separately from the Java files. Do not skip this step, even if the database appears small. Missing reference data can break login flows, permissions, content rendering, or background jobs.
Export the database from the old host
Use a database dump or export tool to capture the full schema and data. Make sure the export includes stored procedures, triggers, and character set information if your app uses them. For MySQL or MariaDB, a standard mysqldump export is usually enough for most hosting migrations.
Import it on the new host
Create a database and user on the new host, then import the dump. Update the application’s datasource or connection string with the new database name, username, password, and host value if needed.
After import, verify these points:
- table count matches the source
- encoding is correct
- the app user has the required permissions
- any sequence values or auto-increment counters are valid
Check connection pooling and datasource names
If the app uses connection pooling through Tomcat or a framework datasource, the database URL and resource name must match exactly. Even if the database itself is fine, a wrong pool name or incorrect JDBC driver can prevent the application from starting.
In a managed hosting environment, make sure the JDBC driver version is compatible with both the database server and the Java version installed in the app server.
Update paths, domains, and file permissions
When files are moved to a new host, path differences often cause hidden failures. Java applications can be sensitive to path changes because they may reference config files, upload directories, or log folders directly.
Replace old filesystem paths
Search your configuration for old absolute paths such as /var/www/oldsite or any custom directory from the source host. Replace them with the new path structure used by the hosting account.
Pay special attention to:
- log file paths
- upload directories
- temporary file locations
- report export folders
- mail queue or attachment paths
Set correct permissions
The Tomcat process must be able to read application files and write to any directories used for logs or uploads. If permissions are too strict, you may see 403 errors, failed uploads, or startup exceptions.
As a rule, application code should be readable, while only specific data directories should be writable. Avoid making the whole app tree writable unless the software explicitly requires it.
Review domain and proxy settings
If the application is now served under a new domain or subdomain, update any domain-based checks, CORS rules, cookie domains, and redirect URLs. If Apache sits in front of Tomcat, confirm that proxy routes, rewrite rules, and HTTP-to-HTTPS redirects still point to the correct back-end service.
When the app is behind Apache or a reverse proxy, confirm that forwarded headers are handled correctly. Otherwise, the application may generate the wrong links, report the wrong scheme, or create redirect loops.
Deploy and test on the new host
After the files and configuration are in place, start the application and test it in a controlled way. The first deployment should focus on basic function rather than full feature testing.
Start with a minimal smoke test
Check the following first:
- Tomcat service starts without errors
- the application loads at the expected context path
- database connections work
- login and session handling function correctly
- static assets load
- file uploads work if required
If the app fails to start, review the Tomcat logs before changing multiple settings at once. Common startup issues include missing environment variables, incompatible Java versions, bad JNDI configuration, and incorrect paths.
Check logs and error messages
Logs are often the fastest way to find migration mistakes. Look for stack traces that mention:
- missing classes or JAR files
- database authentication errors
- permission denied messages
- invalid keystore or SSL settings
- unresolved placeholders in property files
If you are using My App Server or another Plesk-managed Java service, use the service control tools and log viewer in the control panel to inspect startup output. That is usually easier than working directly on the filesystem, especially in a shared hosting environment.
Common issues during Java hosting migration
Application starts on the old host but not on the new one
This usually points to a missing dependency, wrong Java version, or a config file that still references the old environment. Compare the runtime settings between both hosts and verify the exact Tomcat and Java versions.
Database connects locally but not through the app
Check the JDBC URL, username, password, and driver class. Also confirm that the database user has permission from the new host and that the app is pointing to the correct database endpoint.
Uploads or generated files disappear after redeploy
This often happens when files are stored inside the web application folder instead of a persistent data directory. Move those files to stable storage and update the application to use that location.
Application redirects to the old domain
Search for hardcoded URLs in config, templates, and database content. Update cookie settings, absolute links, and reverse proxy headers if needed.
Tomcat service starts but the app returns 404
Check the context path, deployment name, and whether the WAR was deployed to the correct service instance. In control panel-managed hosting, it is easy to upload the file to the wrong app server or choose the wrong service profile.
Practical migration checklist
Use this checklist to reduce the chance of missing a step:
- Confirm the Java and Tomcat version on the new host.
- Back up application files, config, uploads, and database data.
- Copy the WAR file or deployed application directory.
- Move external config files and update paths.
- Recreate database users and import the database.
- Update connection strings, secrets, and domains.
- Set permissions for writable folders.
- Deploy the app and check startup logs.
- Test login, database access, uploads, and static assets.
- Remove old references to source-host paths and domains.
How this works in a Plesk-managed Java hosting environment
If your hosting platform uses Plesk with a Java extension such as My App Server, the migration process is usually more straightforward because the application runtime can be managed from the control panel. You can install or select a Tomcat version, control the service, and keep the application inside a private JVM area instead of sharing the same runtime with unrelated apps.
This setup is useful for small and medium Java applications, including JSP sites, servlet applications, and WAR deployments. It also helps when you need a separate Java version or custom startup parameters without managing a full enterprise application server stack.
When moving to this kind of environment, the main task is not only copying files but also recreating the application’s runtime profile in the control panel. That includes the service state, deployment location, environment values, and any custom app server settings the application needs.
FAQ
Should I copy the whole source code repository to the new host?
Usually no. In most hosting migrations, you only need the build artefact, config files, uploaded data, and database. Copy the full repository only if you plan to build the app on the target host.
Do I need the same Java version on the new host?
It is strongly recommended for the first migration. Once the app is stable, you can test newer versions if the code and libraries support them.
Can I move a Tomcat application by copying the WAR file only?
Sometimes yes, but only if the application has no external config, storage, or database changes. Most real-world apps also need updated properties, database settings, and permissions.
Where should I store uploaded files after migration?
Use a persistent directory outside the deploy folder when possible. That prevents uploads from disappearing after redeploys or service updates.
What should I check first if the app fails after migration?
Check the logs, then confirm Java version, database connection details, paths, and permissions. Those are the most common causes of startup problems.
Can Apache affect a migrated Java app?
Yes. If Apache proxies traffic to Tomcat or rewrites URLs, incorrect rules can cause redirects, 404 errors, or broken HTTPS handling.
Conclusion
Moving Java application files and configuration to a new host is usually straightforward when you separate the process into files, runtime settings, and database data. The safest migration keeps the original Java and Tomcat behaviour as close as possible at first, then adjusts paths, permissions, and performance settings after the app is running.
In a managed hosting environment with Plesk and a private Java service, the key advantage is that you can recreate the app server setup in a controlled way: choose a compatible Java version, deploy the WAR or application directory, restore the database, and verify the service through the control panel. That approach gives you a clean move with fewer surprises and a faster return to normal operation.