What to collect before moving a Java project to a new host

Before you move a Java project to a new host, it is worth collecting the right technical details first. A Java application often depends on more than just the source code or a WAR file. You may need the correct Java version, Tomcat settings, environment variables, database access, build artefacts, file permissions, SSL details, scheduled tasks, and any custom configuration that your app expects from the current server.

If you are planning a migration to a hosting platform with control panel access, such as Plesk-based Java hosting with a private JVM or Apache Tomcat instance, good preparation reduces downtime and helps you avoid problems after deployment. This checklist is especially useful when moving a JSP, servlet, or WAR-based application from one provider to another.

What you should collect before the migration

Start by gathering the information that defines how the application runs today. The goal is to recreate the same runtime behaviour on the new host, or to identify what must change before deployment.

1. Application type and packaging

Document what kind of Java application you are migrating:

  • WAR package
  • JAR application
  • JSP site
  • Servlet-based application
  • Spring Boot or standalone JVM app
  • Legacy application running on a specific Tomcat version

Also note whether the project is built as a single deployable archive or requires multiple components. For example, some apps depend on an external frontend, background worker, or separate API service. This matters when choosing a hosting setup and deployment method.

2. Java version and JVM details

One of the most common migration issues is a mismatch in Java version. Collect the exact version used in production or staging, including:

  • Java major version, such as 8, 11, 17, or 21
  • Vendor, if relevant, such as OpenJDK or another distribution
  • Whether the app needs a specific runtime feature or deprecated API
  • Any JVM flags currently in use

If your application uses a private JVM or runs inside a managed Tomcat instance, write down the startup parameters as well. These may include memory settings, garbage collection options, encoding defaults, timezone settings, and system properties.

3. Tomcat or application server version

If the application runs on Apache Tomcat, collect the exact Tomcat version and any custom configuration. This should include:

  • Tomcat major and minor version
  • Custom server.xml changes
  • Connector settings
  • Context configuration
  • Virtual host setup
  • Session persistence settings

When moving to a hosting platform with a Plesk extension for Java, such as My App Server, it is useful to know whether the app can run on one of the available ready-made Java/Tomcat versions or whether a custom app server setup is required.

4. Build and deployment method

Collect the build instructions and deployment process from the current environment:

  • Build tool used: Maven, Gradle, Ant, or manual packaging
  • Exact build command
  • Deployment artefact name and location
  • Whether the app is deployed automatically or manually
  • Any post-build scripts

If the app depends on a CI/CD pipeline, capture the pipeline configuration, branch rules, environment-specific variables, and the order of deployment steps. Even if the new host supports manual upload through the control panel, you still need to know how the current application is assembled.

5. Runtime configuration and environment variables

Many Java applications depend on environment-specific settings. Collect every variable that the application reads at runtime, such as:

  • Database connection strings
  • SMTP settings
  • API keys and secrets
  • Cache or queue endpoints
  • Feature flags
  • Application profile names
  • File upload paths

Check both system environment variables and Java system properties. Some projects also load values from external files such as .properties, .yml, .xml, or .env. Make sure you know where those files are stored and whether they must be recreated on the new host.

Database and storage information to export

6. Database engine, schema, and credentials

For most Java applications, the database is one of the most important migration dependencies. Gather:

  • Database type and version
  • Hostname or connection endpoint
  • Database name and schema names
  • Username and authentication method
  • Character set and collation
  • Stored procedures, triggers, or views

Also confirm whether the app uses a connection pool and what pool settings it expects. If the new hosting account will use a different database server, verify that the JDBC driver version remains compatible.

7. Persistent files and upload directories

Java applications often store files outside the application archive. This can include:

  • User uploads
  • Generated PDFs or reports
  • Image assets
  • Export files
  • Log archives
  • Temporary working files

Find out which paths are used for persistent storage, whether they are absolute or relative, and whether those directories need to be writable on the new host. On a managed hosting platform with a private JVM, storage permissions and path structure should be checked before go-live.

8. Cache, session, and temporary data

Some applications rely on local cache data or session storage that may be lost during migration. Collect information about:

  • Session timeout values
  • Session persistence or clustering requirements
  • Cache provider configuration
  • Temporary directory location
  • Any cleanup jobs for temp files

If the app uses in-memory sessions, expect that active sessions may not survive the move. Plan a maintenance window and warn users if needed.

Server-side requirements to verify before moving

9. Operating system and library dependencies

Even on shared Java hosting, some applications depend on system-level behaviour. Collect any requirements related to:

  • Operating system family or architecture
  • Native libraries
  • Image processing libraries
  • PDF or barcode libraries with system dependencies
  • External binaries called by the application

If the application uses JNI or custom native code, check whether the new host supports it. In many hosted Java environments, it is better to use pure Java alternatives where possible.

10. DNS, domains, and SSL certificates

Before migration, collect the domain-related details that will affect the cutover:

  • Primary domain and any aliases
  • Subdomains in use
  • DNS records that must be updated
  • SSL certificate type and expiry date
  • Certificate chain and private key location

If the current host provides the certificate, make sure you know how to export or reissue it. If the new environment uses a control panel with integrated SSL management, you may be able to install a new certificate during deployment. Still, collect the existing certificate details so you can plan the transition.

11. Email and notification settings

Java apps often send transactional email, alerts, or password reset messages. Gather:

  • SMTP host and port
  • Authentication username
  • Sender address
  • TLS or STARTTLS requirements
  • IP allowlisting needs

Also check whether the application reads mail settings from external configuration or hardcoded environment values. This is important when moving to a new host where outbound mail rules may differ.

Application access and operational details

12. Admin accounts and integration points

Write down any internal or external services connected to the application:

  • Admin panel URLs
  • Third-party APIs
  • Webhook endpoints
  • SSO or OAuth providers
  • Payment gateways
  • Monitoring services

For each integration, note the callback URLs, client IDs, secrets, and any IP restrictions. A migration can break these if the domain, port, or path changes.

13. Scheduled tasks and background jobs

Collect all jobs that run outside the main web request flow:

  • Cron jobs
  • Batch imports
  • Email queues
  • Cleanup jobs
  • Report generation tasks
  • Indexing or synchronisation jobs

Record the timing, command, and execution user for each task. If the new host offers scheduled tasks through a control panel, you will need this information to recreate them accurately.

14. Log files and error reporting

Logs are essential during and after migration. Collect:

  • Log file paths
  • Log retention settings
  • Log rotation method
  • Debug or verbose modes currently enabled
  • Error tracking integrations

It is also helpful to capture the last known healthy logs before migration. They can help you confirm whether the new environment behaves as expected after deployment.

Checklist for a safer Java migration

Use this practical checklist before you change hosts:

  • Export the full source code and the deployed artefact
  • Record the exact Java and Tomcat versions
  • List all environment variables and system properties
  • Back up the database and verify restore steps
  • Copy persistent files and upload directories
  • Save SSL certificate details and DNS records
  • Document scheduled tasks and background jobs
  • Note external integrations and callback URLs
  • Capture any custom server settings, ports, or connector rules
  • Test the application in a staging or temporary environment first

If you are moving to a hosting service with My App Server and Plesk control panel access, this checklist also helps you decide whether the app can run with one of the predefined Java/Tomcat versions or needs custom tuning. Small and medium Java projects usually benefit from having a separate JVM, clear service control, and a predictable deployment path for WAR, JSP, or servlet applications.

What to test before the final switch

15. Functional tests

After deploying to the new host, verify the most important user journeys:

  • Login and registration
  • Form submission
  • File upload and download
  • Database read and write operations
  • Email delivery
  • Background job execution

Do not assume that a successful startup means the app is fully working. Many migration issues only appear when the app connects to a database, loads external files, or sends outbound traffic.

16. Performance and resource checks

Check memory usage, startup time, and response time after deployment. If the application was tuned for a previous server, it may need different JVM heap values, thread settings, or connection pool limits on the new host. If the hosting plan includes fixed resource limits, make sure they are sufficient for the application’s normal workload.

Common mistakes when migrating Java projects

These are the issues that usually cause delays:

  • Moving only the WAR file without copying external configuration
  • Using a different Java version than the app was built for
  • Forgetting database credentials or JDBC driver requirements
  • Missing writable directories for uploads or temporary files
  • Not recreating scheduled tasks
  • Skipping SSL and DNS planning
  • Ignoring hardcoded URLs, ports, or callback paths

The safest approach is to document the current environment first, then rebuild it step by step on the new host. That is much easier than trying to fix everything after the cutover.

FAQ

What is the minimum information I should collect before moving a Java app?

At minimum, collect the Java version, Tomcat or server version, build artefact, database details, environment variables, writable paths, and any scheduled tasks. Without these, migration problems are common.

Do I need the source code if I already have a WAR file?

Yes, if possible. A WAR file is useful for deployment, but source code helps you rebuild the application, review configuration, and troubleshoot version-specific issues. It is especially important if you need to change the Java or Tomcat version.

Can I move a Java project without downtime?

Some projects can be moved with very short downtime, but it depends on database writes, session handling, and external integrations. In many cases, a brief maintenance window is still the safest choice.

Why does the Java version matter so much?

Because Java applications can behave differently across major versions. A project built for Java 8 may fail on Java 17 if it depends on deprecated APIs, old libraries, or JVM options that are no longer supported.

What should I check if the app uses Tomcat?

Check the Tomcat version, connector settings, virtual host configuration, context paths, memory settings, and any custom XML changes. If the app uses a private Tomcat instance in a hosting control panel, confirm that the service can be started, stopped, and configured correctly.

How do I know whether my app is suitable for managed Java hosting?

Managed Java hosting is usually a good fit for small to medium web applications, JSP sites, servlet apps, and WAR deployments that need a private JVM or Tomcat instance. If your project requires complex clustering, custom enterprise orchestration, or heavy high-availability architecture, you should evaluate a different platform.

Conclusion

Before moving a Java project to a new host, the most important task is not the upload itself, but collecting the technical details that define how the application runs. Java version, Tomcat configuration, database access, environment variables, writable paths, SSL, scheduled jobs, and external integrations all affect whether the migration succeeds smoothly.

If your new platform provides Java hosting through a control panel such as Plesk with My App Server, you can often simplify deployment by using a private JVM, a ready-made Tomcat version, or a custom app server setup. That makes preparation even more valuable, because the better you document the current environment, the easier it is to reproduce it on the new host and verify the application after the move.

Use the checklist in this article before every Java migration, and you will reduce the risk of missing dependencies, broken runtime settings, and avoidable downtime.

  • 0 Users Found This Useful
Was this answer helpful?