If your JSP application uses a database, migration is usually more than copying the web files. You also need to move the database, update connection settings, verify the Java/Tomcat runtime, and check any file paths or permissions that changed during the move. In a managed hosting environment with Plesk and My App Server, this can be done in a structured way without changing your application design.
This guide explains how to migrate a database-backed JSP application in the UK-friendly hosting context, with practical steps for JSP, servlet, Tomcat, WAR deployment, and database configuration. It is suitable whether you are moving from another shared host, a VPS, or a different control panel.
What you need to migrate
A database-backed JSP site usually consists of three parts:
- Application files — JSP pages, Java classes, libraries, static assets, and configuration files.
- Database — typically MySQL, MariaDB, PostgreSQL, or another supported engine.
- Runtime settings — Tomcat version, Java version, context path, JDBC driver, and environment-specific properties.
If your application uses file uploads, generated reports, or local caches, those files must also be moved. For many JSP applications, the most common migration mistake is copying only the WAR or source files and forgetting the database credentials, JDBC URL, and upload directories.
Before you start
Before changing anything, make a full inventory of the existing application. This reduces downtime and makes troubleshooting easier.
Check the current setup
- Which Tomcat version or Java version is the application using?
- Is the application deployed as a WAR file, exploded directory, or both?
- Which database engine is in use?
- Where are the JDBC settings stored: web.xml, context.xml, application.properties, or an external config file?
- Are uploads stored inside the application directory or in a separate path?
- Does the application rely on scheduled jobs, email, or external APIs?
Create backups
Always back up both the application and the database before migration:
- Export the database using your database tool or command line.
- Copy the full application directory or WAR package.
- Save any custom configuration files.
- Keep copies of SSL-related settings, cron jobs, and email templates if they are application-managed.
If possible, test the migration on a staging or temporary subdomain before changing production DNS.
Prepare the target hosting environment
On a hosting platform with Plesk and My App Server, the first step is to ensure the Java runtime and Tomcat service are ready for your application.
Choose the right Java and Tomcat version
Some JSP applications require a specific Java version or a specific Tomcat branch. Confirm the application requirements first. If the app depends on older Java syntax, a newer JVM may not be compatible. If it uses newer servlet APIs, an older Tomcat release may not work.
In My App Server, you can usually:
- install a ready-made Java/Tomcat version from the control panel,
- start, stop, or restart the service,
- deploy a WAR file or application directory,
- configure a private JVM for the hosting account.
For small and medium JSP applications, this provides the main control you need without requiring a separate application server platform.
Review hosting limits and paths
Before uploading files, check the account limits and available paths in Plesk. Confirm:
- disk quota and available storage,
- maximum file size for uploads,
- the deployment directory used by the app server,
- the writable location for logs and uploads,
- which folders are served by Apache and which are internal to Tomcat.
This matters because some JSP applications assume they can write anywhere on disk, but hosted environments normally require explicit writable directories.
Export the database from the old host
The database is often the most critical part of the migration. Export it in a format that can be imported cleanly into the new hosting account.
Recommended export method
For MySQL or MariaDB, use a logical export such as SQL dump. This preserves table structure, data, indexes, and many compatibility settings. For PostgreSQL, use a compatible dump or plain SQL export.
When exporting, make sure you include:
- all tables,
- stored procedures or functions if used,
- views,
- triggers,
- character set and collation details.
Check encoding and collation
Encoding issues are common when moving applications between hosts. If the database stores international text, verify that the old and new environments use the same character set. A mismatch can lead to broken accents, question marks, or import errors.
For JSP applications used by UK businesses, this is especially important if the app stores customer names, addresses, invoice data, or order notes.
Move the application files
Copy the application package and supporting files to the target hosting account. Depending on how the app is built, you may be moving a WAR file, an exploded application folder, or a source tree compiled during deployment.
If you deploy a WAR file
WAR deployment is often the simplest approach. Confirm that the target Tomcat version supports the application and then upload the WAR file through Plesk or the application deployment area. After deployment, verify that the application expands correctly and starts without errors.
If you use an exploded deployment
If the app is deployed as a folder structure rather than a WAR, copy the complete directory, including:
- JSP pages,
- compiled classes,
- JAR dependencies in
WEB-INF/lib, - web.xml and other deployment descriptors,
- static resources such as CSS, JavaScript, and images.
Missing a single library JAR can cause runtime errors that are not obvious at deployment time.
Move uploaded and generated files
If your application stores uploaded files, reports, cache files, or exported documents, move those directories separately. Do not assume they are part of the WAR. Many applications store these files outside the application package for safety and persistence.
Common examples include:
- user uploads,
- image thumbnails,
- PDF invoices,
- temporary processing files,
- log directories referenced by the application.
Create the target database
In the new hosting account, create the database and user first, then import the dump.
Set up the database user
Use a dedicated database user for the application rather than a shared administrative account. Grant only the permissions the application needs. This is a normal best practice for JSP hosting and database-backed web apps.
Import the dump
Import the SQL dump into the new database. If the database is large, use the method that fits your hosting limits and avoid browser timeouts. If needed, split large imports into smaller chunks or use command-line tools where available.
Verify schema and row counts
After import, check a few key tables to confirm that the structure and data came across correctly. If the application has login accounts, product records, or transactions, verify those first.
Update JDBC connection settings
Once the database exists on the new host, update the application so it connects to the new database endpoint and credentials.
Common settings to change
- database host or server name,
- database name,
- database username,
- database password,
- port number if non-standard,
- JDBC driver class, if the app uses an external driver.
Typical configuration locations
Depending on the application, these values may be stored in one of several places:
context.xmlweb.xmlapplication.propertiesjdbc.properties- environment variables or startup scripts
If your app uses JNDI in Tomcat, confirm that the resource definition matches the new database and that the datasource name has not changed.
Do not hardcode production values when avoidable
If possible, keep database values in a separate configuration file rather than embedding them in JSP pages or Java classes. This makes future migrations easier and reduces the risk of exposing credentials in the source tree.
Check the JDBC driver and Java compatibility
A database-backed JSP application also depends on the correct JDBC driver and a compatible Java runtime.
Install or verify the JDBC driver
Some applications bundle the driver JAR inside WEB-INF/lib. Others expect the driver to be installed at the server level. Make sure the driver matches the database version and the Java version used by Tomcat.
Review Java version compatibility
If the application was built for Java 8, running it under a much newer runtime without testing may expose deprecated API usage or library issues. Likewise, some older JSP applications fail when moved to a newer servlet container without adjustments.
In a My App Server setup, selecting the appropriate Java version before deployment can prevent many startup problems.
Fix file paths and permissions
Path differences are a common reason why migrated JSP applications partially work but fail when writing files or loading resources.
Replace absolute paths
If the old application used Windows paths or a different Linux directory structure, update them to the new environment. Prefer relative paths or configured application paths where possible.
Examples of values to review:
- upload directories,
- report output folders,
- temp directories,
- log file locations,
- paths used by image processing or document generation.
Check writable permissions
Tomcat needs write access to the folders used by the application for uploads, logs, and temporary files. In shared hosting, those permissions must be set carefully so the app can write where needed without opening unnecessary access.
If the application fails with access denied errors, look at the path ownership and write permissions first.
Deploy and start the application
After the files, database, and configuration are in place, deploy the application and start the service.
Deployment checklist
- Upload the WAR or application directory.
- Confirm the database import completed successfully.
- Update JDBC settings.
- Verify the correct Java and Tomcat version.
- Restart the app server if required.
- Check application logs immediately after startup.
If you are using Plesk with My App Server, the control panel usually gives you direct service control for start, stop, and restart actions, which makes it easier to apply changes and test them quickly.
Test the migrated JSP application
Testing should cover both the web layer and the database layer. A page loading successfully does not always mean the database connection is correct.
Test the main flows
- Open the homepage and login page.
- Test authentication.
- Create or edit a record that writes to the database.
- Upload a file if the application supports uploads.
- Generate a report or view data from several tables.
- Check logout and session timeout behavior.
Check the logs
Review both application logs and Tomcat logs after startup and after the first few user actions. Typical migration errors include:
- JDBC connection refused,
- authentication failure,
- missing class or library errors,
- incorrect context path,
- file not found for upload or template directories,
- database encoding mismatch.
Logs are often the fastest way to confirm whether the issue is in the application package, the database, or the runtime configuration.
Update DNS only after validation
If the application is moving to a new hosting account or new service endpoint, switch DNS only after testing confirms the app is stable.
Recommended cutover approach
- Test on a temporary subdomain or hosts file entry.
- Confirm the database and application work end to end.
- Lower DNS TTL in advance if you control it.
- Schedule the final switch during a quiet period.
- Keep the old environment available briefly as a fallback if possible.
This reduces downtime and gives you a rollback option if a hidden issue appears after go-live.
Common migration problems and fixes
Application starts, but pages show database errors
Check the JDBC URL, username, password, and host name. Also verify that the database user has permission to access the imported schema.
WAR deploys, but the app immediately crashes
This often means a missing library, unsupported Java version, or incompatible Tomcat release. Review the startup log and compare the source environment with the target.
Uploaded files disappeared after deployment
Your uploads were probably stored inside the old exploded application directory. Move them to a persistent folder and update the path in the app configuration.
Special characters look broken
This is usually an encoding or collation mismatch. Make sure the database, JDBC connection, and JSP page encoding are aligned.
Static assets load, but dynamic pages fail
That usually points to a backend problem, not a web server problem. Focus on Tomcat logs, database connectivity, and JSP compilation errors.
Best practices for future JSP migrations
After the migration is complete, it is worth making a few improvements so the next move is easier.
- Keep database credentials in one external config file.
- Avoid hardcoded server paths.
- Store uploads outside the web root.
- Document the required Java and Tomcat versions.
- Keep a deployment checklist with the database import steps.
- Use version control for application code and configuration templates.
These habits are especially useful for JSP and servlet applications that may need to move between hosts, control panels, or runtime versions over time.
FAQ
Can I migrate a JSP application without rebuilding it?
Yes, if the application is already packaged correctly and compatible with the target Java/Tomcat version. In many cases you can move the WAR file, database, and config with minimal code changes.
Do I need to migrate the database separately from the application files?
Yes. The application files and the database are separate components. If you only move one of them, the application may load but fail when it tries to read or write data.
What is the safest way to move database credentials?
Update them in the external configuration file or Tomcat datasource definition, not inside JSP pages. This reduces errors and makes later changes easier.
Can My App Server host a database-backed JSP app?
Yes, for small and medium JSP or servlet applications that need their own Tomcat instance and controlled Java runtime. It is suitable for practical hosting and deployment tasks, including WAR deployment and database connectivity.
What should I check first if the migrated app shows a blank page?
Check the application logs, Tomcat logs, and browser error messages. Then verify the database connection, library paths, and Java compatibility. A blank page often means an exception is being thrown before output is rendered.
Conclusion
Migrating a database-backed JSP application is straightforward when you treat it as three separate tasks: move the files, move the database, and update the runtime configuration. In a Plesk environment with My App Server, you also have direct control over the Tomcat service, Java version, and deployment process, which helps keep the move predictable.
If you verify the database dump, check JDBC settings, confirm file paths, and test the app before DNS cutover, you can migrate most JSP applications with limited downtime and fewer surprises.