Before you move a JSP application to a new host, gather the same technical details you would need for a clean Tomcat deployment, plus the hosting-side information that often gets missed during migration. For a JSP site, the most common migration problems are not the files themselves, but mismatches in Java version, Tomcat configuration, context paths, database access, file permissions, and any assumptions the application makes about the previous server environment.
If you are moving to a managed hosting platform with Plesk and a private JVM or Tomcat service such as My App Server, the safest approach is to collect everything needed for a controlled cutover first. That makes it easier to recreate the application in the new control panel, test it without breaking the live site, and avoid unexpected downtime.
What you should collect before the migration
Start by building a complete inventory of the current application and its dependencies. For JSP and servlet applications, the migration is usually straightforward when the source environment is well documented. Use the list below as a pre-move checklist.
1. Application files and deployment package
Collect the full application source or deployable package, depending on how the site is managed today. In many JSP projects this means:
- the WAR file, if the site is deployed as a web archive
- the full web application directory, if files are deployed unpacked
- all JSP files, Java classes, tag libraries, and static assets
- any custom JAR files used by the application
- configuration files that are not part of source control
If the site was built by hand over time, do not assume that the live server matches the source repository. Check the deployed instance itself and compare it with the development tree. Missing JARs, hotfix files, and locally edited configuration values are common reasons for a failed move.
2. Java version and Tomcat version
Note the exact Java runtime version and the Tomcat version used on the current host. JSP applications can be sensitive to both. A project compiled for Java 8 may run differently on Java 11 or Java 17 if it depends on removed APIs, older libraries, or deprecated security settings.
Collect:
- Java major version and update level
- Tomcat major and minor version
- whether the application uses a private JVM or shared Java runtime
- any startup flags, memory options, or JVM arguments
If you are moving to a hosting platform where you can install a private Tomcat instance through a control panel extension such as My App Server, matching the runtime is one of the first things to confirm. Even when multiple Java versions are available, you should still document which one the application expects.
3. Context path and deployment structure
Collect the application’s context path and current deployment method. Some JSP applications work only when deployed at a specific path, especially if the code uses hardcoded URLs or relative resource paths.
Record:
- the current context root, such as
/appor/myproject - the server name or virtual host binding
- whether the app must run as the root application
- any reverse proxy or rewrite rules tied to the old host
If the project expects to run as the root application but is moved into a subdirectory, image paths, login redirects, and servlet links may break. This is one of the most common post-migration issues with JSP hosting.
4. Database connection details
Almost every JSP application depends on a database. Gather the information for all database connections before moving. Include not only the credentials, but also the connection method and any database-specific assumptions.
Collect:
- database type: MySQL, MariaDB, PostgreSQL, SQL Server, or other
- host, port, database name, username, and password
- JDBC driver version in use
- connection pool settings, if the app uses one
- character set and collation settings
- stored procedure usage or database-specific SQL syntax
If you will restore the database on the new hosting platform, make sure you know whether the application relies on a specific collation, timezone, or SQL mode. A JSP app may appear to start correctly but still fail on certain pages if the database response differs from the old host.
5. Environment variables and configuration properties
Many Java web applications store key settings outside the codebase. Before migration, collect every environment-specific property the application reads at runtime.
This may include:
- API keys and external service credentials
- SMTP server settings
- file storage paths
- upload limits
- application mode flags such as test or production
- custom Java system properties
Do not rely on memory for this part. Check startup scripts, Tomcat configuration files, application property files, and any control panel settings used by the previous host. When moving to managed JSP hosting, these values may need to be recreated in the new service settings or inside the application configuration itself.
6. File system dependencies and writable directories
Some JSP applications need directories for uploads, logs, caches, generated files, or exports. Collect the full list of paths the application reads from or writes to.
Important items to record:
- upload directory paths
- temporary directories
- log file locations
- image or document storage paths
- any shared filesystem locations
Check whether those paths are absolute or relative. This matters when the application is moved into a new hosting account, because directory layouts are often different. If the application writes outside the web root on the old server, plan equivalent writable paths on the new host and confirm permissions early.
7. Permissions and ownership requirements
File permissions are often overlooked during migration. JSP apps may run fine until the first upload, log write, or cache refresh fails because the new host applies different ownership rules.
Document:
- which directories must be writable
- which files must be read-only
- any special owner or group requirements
- whether the application needs execute permission on scripts
In a hosted Tomcat setup, permissions are usually managed through the hosting account and service configuration. Still, you should note the application’s needs in advance so you can test them after deployment rather than discovering failures during live traffic.
8. SSL, domains, and redirect rules
Gather all domain-level configuration that is attached to the application. A JSP project may rely on HTTPS redirects, canonical hostnames, or session cookies tied to a specific domain.
Record:
- primary domain and any aliases
- SSL certificate status and renewal date
- HTTP to HTTPS redirect rules
- www and non-www handling
- any application-level absolute URLs
If the application sends callback URLs to payment gateways, email verification systems, or third-party APIs, collect those endpoints as well. A migration is the right time to verify that the new host will use the correct public hostname before traffic is switched over.
9. Mail settings and external services
JSP applications often send email for password resets, order notifications, form submissions, or system alerts. Collect the mail configuration and any third-party integrations used by the application.
Document:
- SMTP host, port, authentication method, and encryption
- from-address and reply-to settings
- third-party email APIs or transaction services
- webhook endpoints and callback URLs
- rate limits or sender restrictions
Also check whether the application uses IP-based allowlists for outbound requests. If the new host changes the outbound network behavior, integrations may need to be updated after migration.
10. Logs, error messages, and known issues
Collect the current logs and any recent error messages before the move. They often reveal hidden dependencies that are not visible in the code.
Look for:
- startup errors
- class loading failures
- missing resource warnings
- database connection errors
- deprecated API usage
Saving a recent log snapshot helps during the post-migration validation stage. If something fails on the new host, you can compare behavior quickly instead of guessing what changed.
How to prepare the application for a cleaner move
Once you have collected the basic data, use it to reduce migration risk. The best results usually come from simplifying the application before the cutover rather than trying to reproduce every old server detail perfectly.
Review third-party libraries
Check which JAR files are actually required. Old JSP projects often accumulate duplicate or outdated libraries. Before moving, identify version conflicts, especially for:
- database drivers
- JSON libraries
- logging frameworks
- mail libraries
- framework jars bundled inside the application
Removing duplicates before the move can prevent classpath conflicts in the new Tomcat environment.
Check Java compatibility
Test the application against the Java version you plan to use on the new host. If you are moving into a managed hosting account with a private JVM, confirm that the chosen Java version matches the application’s compile target and runtime needs.
Pay close attention to:
- old servlet APIs
- use of internal JDK classes
- security provider changes
- date and timezone behavior
Confirm external dependencies
Any application that calls external APIs, file shares, payment gateways, or legacy internal systems should be tested from the new environment as early as possible. Even if the code is unchanged, network rules, DNS changes, or certificate checks may alter behavior.
What to verify in Plesk or a managed Tomcat setup
If the destination host uses Plesk with a Java hosting extension such as My App Server, plan the migration around the control panel structure. This gives you a clean way to recreate the service settings without manual server administration.
Service settings to confirm
Before moving the application, confirm the new service details in the control panel:
- selected Java version
- Tomcat service status
- deployment method for WAR or exploded app files
- allocated memory and JVM settings, if available
- application start and stop control
For JSP hosting on a private Tomcat instance, these settings matter because the service should behave consistently from one deployment to the next. A small mismatch in runtime version or application root can cause startup failure even when the files are correct.
Paths and file placement
In a Plesk-based hosting environment, make sure you know where the application files will live after the migration. Document the web root, any private application directories, and the location for logs and writable data. This reduces the chance of putting files in the wrong place during import or manual upload.
Testing before DNS switch
Whenever possible, test the application using a temporary URL, preview hostname, or hosts-file approach before you change public DNS. That allows you to confirm:
- the app starts without errors
- database connections work
- forms submit properly
- uploads and downloads work
- redirects point to the right domain
Testing in advance is especially useful for JSP applications because runtime errors may appear only when a page is compiled or a servlet is first requested.
Recommended migration checklist
Use the following checklist as a practical summary before you move the project:
- collect the WAR file or full application directory
- document Java and Tomcat versions
- record context path and domain mapping
- export database details and JDBC driver versions
- list all configuration files and environment variables
- identify writable directories and permissions
- save SSL, redirect, and hostname settings
- capture SMTP and third-party integration details
- review recent logs for hidden dependencies
- confirm the target host’s control panel and service settings
Common mistakes to avoid
Many JSP migration issues come from missing one small but important detail. These are the most common mistakes:
- moving the code without matching the Java version
- forgetting a custom JAR or JDBC driver
- assuming the context path can stay the same automatically
- not restoring database collation or timezone settings
- overlooking writable directories for uploads or logs
- skipping test requests before DNS changes
- forgetting to update external callback URLs
In managed hosting, the application may still start even if one setting is wrong. That is why it is important to collect everything before migration, not after the site goes live and users start reporting errors.
FAQ
Do I need the source code, or is the WAR file enough?
A WAR file is often enough to deploy and test the application, but source code is still useful for troubleshooting, rebuilding, and checking configuration that may not be packaged into the archive. If you can collect both, that is the safer choice.
Why is the Java version so important for a JSP move?
JSP applications depend on the Java runtime and servlet container. A version mismatch can affect compilation, libraries, TLS behavior, and startup flags. Matching the runtime reduces the risk of hidden incompatibilities.
What should I do if the old server used custom Tomcat settings?
Record every custom setting you can find, including memory options, connector settings, environment variables, and context configuration. Then reproduce only what the application truly needs on the new host. Avoid copying unnecessary legacy settings unless you know they are required.
Can I move the application first and fix redirects later?
It is better to collect redirect rules and hostname settings before the move. JSP applications often generate absolute links, and fixing them after the cutover can cause broken sessions, duplicate content, or failed callback integrations.
What if my JSP app uses uploads and stored files?
Make a full inventory of every directory that stores files. Then create the equivalent writable paths on the new host and test upload and download workflows before switching production traffic.
Final checks before the cutover
Before you change DNS or point users to the new host, confirm that you have a complete migration sheet for the JSP application. At minimum, you should know what to deploy, which Java and Tomcat versions to use, where the database lives, what file paths must remain writable, and which external services depend on the old environment.
For a hosting platform that supports JSP hosting through a private Tomcat or JVM instance in Plesk, this preparation makes the deployment much smoother. You can recreate the application in a controlled way, verify it under the right runtime, and reduce downtime during the move.
In short, the most valuable thing to collect before moving a JSP project is not only the code, but the full runtime picture around it. If you document the application, service settings, database, paths, and integration points in advance, the migration becomes far easier to test, support, and complete safely.