Before you move a Java project to a new host, it helps to gather the right technical and operational details first. A Java application is usually more than just source code: it may depend on a specific Java version, Tomcat settings, environment variables, database access, file permissions, scheduled tasks, and a particular deployment format such as WAR or a custom application layout. If you collect this information in advance, the migration is much safer and the cutover is usually faster.
This is especially important when you are moving to a hosting platform that provides Java hosting through a control panel such as Plesk, where the application may run in its own JVM or on a managed Tomcat service. In that kind of setup, the main goal is to make sure the new environment matches the old one closely enough for the app to run correctly, while also taking advantage of the hosting tools available for deployment and service control.
What you should collect before the migration
Start by building a complete checklist of the application’s requirements and current runtime configuration. The more precise this list is, the easier it is to reproduce the application on the new host and avoid surprises after launch.
Application package and source material
- The current application codebase or source repository location
- The deployed artifact type: WAR, JAR, exploded directory, or custom structure
- Build tool information, such as Maven, Gradle, Ant, or a manual build process
- Any vendor libraries, third-party JARs, or private dependencies not stored in the main repository
- Release notes or deployment notes from previous updates
If the application is deployed as a WAR file, check whether it expects an application server to unpack it automatically or whether it relies on a specific directory structure. If the app uses custom bootstrap scripts, collect those as well, because they often contain important JVM arguments or path settings.
Java runtime details
- The exact Java version in use, including major and minor version if relevant
- Whether the app requires a specific vendor build or just a standard OpenJDK-compatible runtime
- Any JVM options currently in use, such as heap size, garbage collection flags, or timezone settings
- Encoding requirements, for example UTF-8
- Any native libraries or OS-level dependencies required by the JVM
For Java hosting on a managed platform, knowing the exact Java version is essential. A project that works on Java 8 may fail on Java 11 or Java 17 because of removed APIs, changed defaults, or third-party library incompatibility. If the application has been running for years, do not assume it will behave the same on a newer runtime without testing.
Tomcat or servlet container configuration
- Tomcat version currently used
- Connector settings, including HTTP, HTTPS, and any proxy-related configuration
- Context settings and application context path
- JNDI resources and datasource definitions
- Session persistence requirements
- Any changes made to server.xml, context.xml, web.xml, or similar files
If your application is hosted on Apache Tomcat, collect both the application-level configuration and the server-level settings. In many cases the app will not fail because of the code itself, but because a datasource, realm, or connector setting was not copied correctly. When migrating to a hosting platform with a Tomcat-based service, this information is what helps you recreate the same runtime behavior in the new control panel environment.
Environment variables and secrets
- System environment variables used by the app
- Application properties files and override files
- Database credentials and connection strings
- API keys, tokens, SMTP credentials, and other secrets
- Paths to certificates, keystores, or truststores
Make a clear list of what is needed to run the app and where each value is currently defined. Some projects store settings in a properties file, some use environment variables, and others mix both. During migration, this is one of the most common points of failure. A missing secret or an incorrect connection string can make the application appear broken even when the code and Java runtime are correct.
Database and external service dependencies
- Database type and version
- Hostname, port, and schema/database name
- Authentication method
- Connection pool settings
- External APIs, message queues, storage services, or payment gateways
- Any IP allowlists or firewall rules required by third parties
A Java project often depends on services outside the web container. Before moving hosts, confirm which services the application must reach and whether those services are accessible from the new environment. If the app uses a database, collect the schema details, migration scripts, and the location of any scheduled maintenance jobs that affect the data layer.
Check how the current server is configured
Before you change hosting providers, inspect the existing server carefully. Even if your final target is a simpler setup with Plesk and My App Server, the original configuration can reveal hidden dependencies that would otherwise be missed.
Document the deployed file layout
- Where the application files are stored
- Which directories are writable by the application
- Whether uploads or generated files are kept inside or outside the web root
- Any hard-coded paths in the codebase or configuration
File paths matter more often than many teams expect. A Java web application may write temporary files, exports, logs, or user uploads to a location that only exists on the old host. If that path changes on the new server, the app may start but fail later under real use.
Review logs and recent errors
- Application logs
- Tomcat logs
- System logs if available
- Recent startup errors, memory warnings, or stack traces
Logs are one of the most valuable migration tools. They show what the application already struggles with, which dependencies are missing, and what warnings should be watched after the move. If the app has unstable startup behavior on the old host, fix or at least understand that issue before transferring it.
Record security and access settings
- SSL/TLS certificate usage
- Keystore passwords and alias names
- Authentication integration, such as LDAP or SSO
- Role mappings and permission rules
- Any IP-based restrictions or admin access rules
When Java applications use HTTPS or secure backend connections, certificate and keystore details should be part of the migration plan. In hosted environments, this may be managed through the control panel or a separate service configuration. Keep the certificate chain, truststore information, and renewal process in the handover notes.
What to prepare for a Plesk-based Java hosting move
If your new hosting environment uses Plesk with a Java extension such as My App Server, the migration can be more structured than a manual server build. In that model, you should prepare the application so it fits the service model of the platform and can be installed or updated cleanly.
Identify the deployment method
- Will you deploy a WAR file?
- Does the app need a dedicated Tomcat instance or a private JVM?
- Do you need a custom application server configuration?
- Is the application started through the control panel or by a script?
A hosting platform that supports Java through Plesk may offer predefined Java or Tomcat versions for quick installation, with additional versions available for manual setup. Knowing your deployment method helps you choose the right path early. For a typical small or medium Java web application, a managed Tomcat-style setup is often the simplest option.
Gather control panel requirements
- Domain or subdomain to use
- Document root or application root if applicable
- Expected context path
- Port or proxy needs
- Access rights for deployment and service control
In a hosted environment, the application is often accessed through a domain or subdomain that is configured in the control panel. Plan this in advance so DNS, SSL, and deployment can be aligned. If the app must be reachable under a specific path, make sure that path is mapped correctly before the cutover.
Check resource usage
- Average and peak memory use
- CPU load during busy periods
- Disk usage, especially logs and file uploads
- Number of concurrent users or sessions
This is important because a private JVM or shared hosting Java service still has practical limits. If the application consumes too much memory or writes large amounts of data, you should know that before migration. Review current usage patterns and compare them with the resources available on the target hosting account.
Create a migration checklist for the application owner
A practical migration checklist helps separate essential items from optional ones. It also makes internal communication easier if multiple people are involved, such as a developer, a system administrator, and a business owner.
Minimum checklist
- Current production URL and expected new URL
- Java version
- Tomcat version or equivalent container version
- Deployment artifact and build steps
- Database connection details
- Environment variables and application properties
- SSL/TLS and certificate information
- Scheduled jobs and background tasks
- Third-party integrations and credentials
- Rollback plan
Recommended testing materials
- A copy of production configuration with sensitive values masked
- A staging database snapshot or sanitized data set
- Sample user accounts for login testing
- Known-good URLs for key application functions
- Expected response codes or output for critical pages
Testing data is often overlooked, but it is very useful. After a move, you need a fast way to verify that login, form submission, file upload, database reads, and scheduled processes still work as expected.
Plan the cutover in practical steps
Once the data is collected, the actual move becomes much easier. A good migration plan reduces downtime and gives you a clear sequence of actions.
1. Freeze configuration changes
Ask everyone involved not to change production settings during the migration window. If the old host is still receiving edits while you are preparing the new one, the configuration will drift and troubleshooting becomes harder.
2. Export the current runtime configuration
Copy the application properties, Tomcat settings, JVM arguments, cron jobs, and any custom scripts. Store them in a secure handover folder so they can be referenced during setup on the new host.
3. Build the app on the target platform
Install the required Java version and configure the application service on the new host. On a Plesk-based Java hosting platform, this may include selecting a ready-made Java or Tomcat version, or uploading a custom runtime if the project needs it. Then deploy the WAR or application package and verify startup behavior.
4. Recreate dependencies
Set up the database connection, mail settings, file storage paths, certificates, and external service endpoints. Confirm that the app can reach everything it needs from the new environment.
5. Test before switching traffic
Check the login flow, main pages, form submissions, background tasks, and error logs. If possible, test with a temporary hostname or staging subdomain before changing the public DNS record.
6. Perform the DNS and traffic switch
After validation, update DNS or reverse proxy routing according to your migration plan. Keep the old environment available for a short rollback window if possible.
Common Java migration problems to look for
Many move-related issues are predictable. If you collect the right details up front, you can avoid a large percentage of them.
Version mismatch
A library may work on the old Java version but fail on the new one. This is especially common when moving older applications to a newer runtime. Always confirm compatibility before migration.
Missing environment variables
If the application expects values from the shell or from a control panel setting, missing variables can cause startup failure or subtle runtime bugs.
Incorrect file permissions
Java apps frequently need write access for logs, temp files, cache, uploads, or generated reports. Make sure the service account can write to those locations.
Database access blocked
Even when the database credentials are correct, firewall rules, IP restrictions, or a wrong host name can prevent connection. Verify connectivity from the new host before launch.
Certificate or HTTPS issues
Imported certificates, chain files, and truststore entries are easy to miss. If the app makes outbound secure connections, you may also need to import trusted CAs into the Java truststore.
What to ask your developer or previous host for
If you are not the original developer, ask for specific items instead of a general “migration document”. This saves time and lowers the chance of missing something important.
- The exact Java and Tomcat versions used in production
- All deployment artifacts and build instructions
- Application property files and example values
- Datasource definitions and database migration scripts
- Scheduler details for background jobs
- SSL certificate and keystore information
- Custom scripts used at startup or shutdown
- A list of known issues or browser-specific quirks
If the old provider can export a backup or service profile, request that too. Even if you cannot use it directly on the new platform, it can help you reconstruct the application layout faster.
FAQ
Do I need the source code to move a Java application?
Ideally yes, but not always. If you only have a WAR or another deployable artifact, you can still migrate the application, provided you also have the runtime settings, database information, and any external dependencies.
What is the most important thing to collect first?
The Java version, deployment artifact, Tomcat or container configuration, and database connection details are usually the most critical. If those are wrong, the application may not start or may fail immediately after launch.
Can I move an older Tomcat app to a new host without changing code?
Sometimes yes, if the new environment supports the same Java version and compatible Tomcat behavior. However, older apps often depend on legacy settings, so testing is still necessary.
How do I know if my app needs a private JVM?
If the application has special JVM arguments, memory settings, custom libraries, or runtime isolation requirements, a private JVM can be helpful. For smaller Java web apps, a managed Tomcat setup is often enough.
Should I copy logs to the new host?
Copy important recent logs for reference, but do not usually migrate old logs into the new runtime path unless you have a specific auditing or compliance reason. They are more useful for troubleshooting than for production startup.
What if the application uses a custom server setup?
Collect the full server configuration, custom scripts, and any manual changes to the servlet container. A custom setup may still work on the new host, but it needs careful mapping to the target platform’s service model.
Final checks before you start the move
Before you begin the actual migration, confirm that you have a complete set of deployment files, runtime settings, database credentials, SSL material, and service dependencies. For a Java project, those details are just as important as the code itself. If the application is moving to a hosting environment with Plesk and My App Server, the preparation work becomes even more valuable because it lets you use the control panel and Tomcat service management efficiently.
A well-prepared migration is usually easier to test, easier to roll back, and easier to support after launch. Collecting the right information in advance is the best way to make the new host behave like the old one, while keeping the deployment clean and manageable.