Before moving a Java application, it is important to audit more than just the source code and the target hosting account. A safe migration depends on how the application starts, which Java version it needs, how it uses Tomcat or another servlet container, what files and databases it relies on, and whether the new hosting environment can reproduce the same runtime behavior. In a hosting and control panel context, this usually means checking the application package, JVM settings, web server integration, service permissions, scheduled tasks, logs, and any external dependencies before you switch traffic.
What to check before a Java migration
A Java migration audit should answer one simple question: what does the application need to run correctly, and what must be moved or recreated for it to work in the new environment? For a Java hosting setup with Plesk and a service such as My App Server, the goal is to avoid surprises after deployment. That includes servlet container compatibility, Java runtime selection, environment variables, port usage, database connectivity, and filesystem layout.
If you are moving a WAR-based application, a JSP site, or a small servlet app, the audit is usually straightforward. If the application uses custom startup scripts, external libraries, or uploaded content stored outside the web root, the review must be more detailed. The safest approach is to document everything first, then test in a staging account before the final cutover.
Audit the application type and runtime requirements
Identify what kind of Java application you are moving
Start by identifying the exact application model. Not all Java applications are deployed the same way, and this affects the migration plan.
- WAR application — packaged for deployment into Tomcat or a similar servlet container.
- JSP site — may require Tomcat, specific Java libraries, and web.xml settings.
- Servlet application — depends on a servlet container and compatible API levels.
- Standalone Java service — may run as a private JVM with its own startup command.
In an environment like My App Server, this distinction matters because some applications can be installed with a few clicks using a prepared Tomcat version, while others may need a custom app server or manual configuration. Confirm whether the app expects a container-managed deployment or a standalone JVM process.
Check the Java version and framework compatibility
One of the most common migration issues is Java version mismatch. Audit the current runtime and compare it with the versions available in the target hosting platform.
- Current Java version used in production or staging
- Required minimum and maximum Java version for the application
- Framework compatibility, such as Spring, JSF, Struts, Hibernate, or older servlet APIs
- Any deprecated language features or libraries
Do not assume that the latest Java version will automatically work better. Some applications compile and run only on a specific major version, especially if they depend on older application server behavior or legacy libraries. If the hosting platform offers multiple Java versions, choose the one that matches your tested runtime first, then plan an upgrade separately if needed.
Audit Tomcat or servlet container settings
Confirm the container version and deployment method
If your application runs on Apache Tomcat, verify the exact version in use. Version differences can affect servlet specification support, session handling, TLS behavior, and library compatibility.
Check:
- Tomcat version
- Servlet and JSP specification level
- Whether the application is deployed as a WAR, exploded directory, or custom context
- Context path configuration
- Any custom
server.xml,context.xml, orweb.xmlsettings
If the new hosting environment uses a managed Tomcat instance inside Plesk, review how the service is started and controlled. A platform such as My App Server can simplify this by allowing you to manage the Tomcat service, choose a Java version, and deploy the application within the hosting account. Still, the application itself must be compatible with the selected container.
Audit custom connectors, ports, and proxies
Many Java applications rely on specific ports, internal connectors, or reverse proxy behavior. Before moving, document all network-related settings.
- HTTP and HTTPS ports used by the application server
- Any AJP connector usage
- Reverse proxy configuration through Apache
- Redirect rules and canonical hostnames
- WebSocket or long-lived connection requirements
In a shared hosting context, you may not be able to keep the exact same port strategy as on a previous provider. If the application is intended to sit behind Apache in Plesk, confirm how Apache forwards requests to Tomcat and whether the app expects direct access to the application server. This is especially important for login flows, absolute URLs, and callback endpoints.
Audit system dependencies and libraries
Inventory all external JAR files and native dependencies
Before migration, create a complete list of libraries that the application needs at runtime. Missing JAR files are a frequent reason for startup failures after a move.
- Application-specific JARs
- Database drivers
- Logging libraries
- XML or JSON parsing libraries
- Native binaries or JNI dependencies
Check whether libraries are bundled inside the WAR, stored in Tomcat’s shared folders, or installed system-wide on the old server. If a dependency was added manually over time, make sure it is included in the migration package. For custom app servers, this audit should also confirm whether the application needs a private JVM with additional system libraries or startup flags.
Review environment variables and JVM options
Java apps often depend on environment variables or JVM parameters that are easy to overlook. These settings can control encoding, memory usage, TLS behavior, file paths, and feature flags.
JAVA_HOMEor equivalent runtime pathCATALINA_HOMEandCATALINA_BASE, if applicable- Heap settings such as
-Xmsand-Xmx - Garbage collection options
- File encoding settings such as UTF-8
- Timezone settings
- Custom feature flags or profile switches
In managed hosting, these values may be set through the control panel or the My App Server service configuration rather than through shell scripts. Audit both the current values and where they are applied so you can reproduce them accurately on the new platform.
Audit files, uploads, and persistent data
Identify what lives outside the application package
Many Java applications are not self-contained. They store user uploads, generated documents, cached data, or runtime configuration in separate directories. Before migrating, locate every path the app reads from or writes to.
- Uploaded files
- Generated reports or exports
- Image assets or media libraries
- Persistent caches
- Temporary work directories
- Configuration files outside the WAR
Check whether these files are inside the web application directory or in a custom path. If the app uses absolute filesystem paths, those paths may need to be updated for the new hosting account. This is a common issue when moving from a full server environment to a managed hosting platform where folder structure and permissions differ.
Confirm ownership and permissions
File permissions can break an otherwise successful migration. Audit the current ownership model and compare it with the permissions available in the target account.
- Which user owns the application files
- Which directories must be writable
- Whether the app writes logs or cache files
- Whether uploaded content needs restricted access
- Whether symbolic links are used
If the application runs under a private JVM or managed Tomcat service, the service user must be able to read the app files and write to the intended directories. Keep the writeable areas minimal for security and easier troubleshooting.
Audit database connections and data migration needs
Document every database the application uses
Java applications commonly depend on one or more databases. Before migrating, make a full inventory of those connections.
- Database engine type
- Hostname and port
- Database name
- Username and authentication method
- Connection pool settings
- Character set and collation
Also check whether the application uses JNDI data sources, direct JDBC URLs, or framework-managed connection settings. If the target hosting service provides a database through Plesk, verify that the JDBC driver version is compatible with both the database and the Java runtime.
Plan for schema, data, and background jobs
Audit not only the database connection itself but also the data migration scope. Determine whether the app requires:
- Schema only
- Schema plus application data
- Reference tables or lookup data
- Stored procedures or triggers
- Scheduled jobs that update tables
Some Java applications rely on background jobs to populate caches, send notifications, or clean records. If those jobs are tied to the database, confirm how they will run after the move. If the hosting platform does not support the same scheduler design as the old environment, you may need to adjust the job execution strategy.
Audit scheduled tasks, startup scripts, and services
List every task that runs outside the web request flow
Migration planning should include all scheduled or background processes. These are often missed because they do not appear in the web UI.
- Cron jobs
- Batch scripts
- Message consumers
- Email polling tasks
- Indexing or cleanup jobs
- Command-line maintenance scripts
Document how each task is started, what account runs it, which environment variables it needs, and where it writes logs. If these processes are part of a Java hosting setup, consider whether they should run inside the same account as the application or separately as a controlled service.
Review startup and shutdown behavior
Some applications need a clean shutdown sequence to avoid data loss or corrupted state. Audit any startup scripts, shutdown hooks, or service wrappers used on the source server.
- How the app is started
- Whether a custom shell script is used
- Any pre-start or post-start steps
- Graceful shutdown requirements
- How long the application needs to warm up
In My App Server or a similar control panel service, the application may be started and stopped from the hosting interface. Make sure the current operational process is mapped to that model before migrating. If a manual startup sequence is required, test it in the new environment first.
Audit configuration files, secrets, and integrations
Separate application settings from secrets
During a migration, configuration files often get copied without checking which values must change. Review all configuration sources and mark sensitive data separately.
- Database passwords
- API keys
- SMTP credentials
- OAuth client secrets
- Signing keys and certificates
- Webhook tokens
Also identify settings that are environment-specific, such as hostnames, file paths, and callback URLs. These should be reviewed before launch so the application does not keep pointing to the old environment after the move.
Check third-party integrations
Modern Java applications often connect to external services. Audit every integration so you can update allowlists, endpoints, and credentials if needed.
- Payment gateways
- Email service providers
- SMS or push services
- Identity providers
- Analytics or logging platforms
If the new hosting platform has a different outbound IP address or network setup, any IP-restricted integration may need to be updated. This is particularly important for transactional email, payment callbacks, and SSO providers.
Audit logs, monitoring, and rollback options
Make sure you can observe the application after the move
Migration is easier when logging and monitoring are already planned. Before moving, check where logs are written, how often they rotate, and what information they include.
- Application logs
- Tomcat logs
- Apache access and error logs
- Database logs if relevant
- Custom audit or business logs
In a Plesk-based environment, log access through the control panel can be very useful during cutover and troubleshooting. Make sure you know which log files to inspect if the app fails to start, returns a 500 error, or behaves differently after deployment.
Prepare a rollback plan
A good audit also includes a rollback strategy. Before changing DNS or switching traffic, define what you will do if the new deployment fails.
- Keep a full backup of application files and database exports
- Retain the source environment until validation is complete
- Document the original DNS and routing state
- Know how to restore the previous version quickly
- Confirm who will approve the rollback decision
Rollback planning is especially valuable for Java applications with stateful sessions or business-critical data. A controlled return path reduces downtime and helps you migrate with confidence.
Practical migration audit checklist
Use this checklist before you move the application:
- Confirm application type: WAR, JSP, servlet, or standalone JVM
- Record the exact Java version and framework dependencies
- Verify Tomcat or container version compatibility
- List all JAR files and native dependencies
- Export JVM options and environment variables
- Identify all writable directories and uploaded content paths
- Document database connections, schema, and data scope
- Inventory cron jobs, batch scripts, and background tasks
- Review config files, secrets, and third-party integrations
- Check logging locations and rotation settings
- Prepare rollback steps and backup copies
- Test in staging before switching production traffic
If the target platform offers a managed Java hosting option through Plesk, such as My App Server, use the control panel to validate service control, Java version selection, Tomcat deployment, and file permissions early in the process. That gives you a much clearer picture of what will work after the move.
How My App Server can help during planning
For smaller and medium Java deployments, a hosting platform with a dedicated Java service can simplify migration planning. With a solution like My App Server, you can install and manage a private Apache Tomcat instance or a private JVM inside a shared hosting account, which makes it easier to match the application’s runtime requirements without building a separate server stack from scratch.
This is useful when you need:
- A selectable Java version
- Tomcat-based hosting for WAR, JSP, or servlet apps
- Service control from the hosting panel
- Separate JVM behavior for a specific application
- Manual setup for custom app server versions when needed
The key point is still audit first, deploy second. Even if the platform provides ready-to-use Java and Tomcat options, the application must still be reviewed for compatibility, file layout, database access, and external dependencies.
FAQ
What is the most common issue when moving a Java application?
The most common issue is a mismatch between the old and new runtime environment, especially Java version differences, missing libraries, or incompatible Tomcat settings. File permissions and database connection settings are also frequent causes of failure.
Should I audit the application code before migration?
Yes, but only as part of a broader audit. You usually do not need a full code review unless you suspect version-specific behavior, hardcoded paths, or deprecated APIs. For most migrations, runtime dependencies and deployment configuration are more important than application logic.
Do I need to copy Tomcat settings manually?
Not always. If the hosting platform provides managed Tomcat service control, some settings can be configured through the panel. However, you still need to review the old server.xml, context settings, JVM options, and any custom connectors so nothing important is missed.
What should I test before switching production traffic?
Test login, core user flows, file upload or download features, database reads and writes, email sending, background jobs, and any integrations with external systems. Also check startup and shutdown behavior, since some issues appear only during service restart.
Can I move a Java app without moving the database?
Sometimes, yes, if the database remains on the same server or is hosted separately. But you still need to audit connection details, latency, credentials, and driver compatibility. If the database is moving too, plan the schema and data migration carefully.
Conclusion
Before moving a Java application, audit the runtime, Tomcat or servlet container configuration, dependencies, file paths, database connections, scheduled tasks, secrets, logs, and rollback plan. For a hosting platform with Plesk and a Java service such as My App Server, this preparation helps ensure that the new environment can reproduce the application’s behavior with minimal downtime.
A careful audit does not just prevent errors. It also gives you a clear migration map, helps you choose the right Java version and hosting setup, and makes the final cutover much safer.