How to migrate a database backed JSP application

If your JSP application uses a database, migration is not just about copying files. You also need to move the database itself, update connection settings, verify the Tomcat or private JVM configuration, and check that the application still works after deploy. In a managed hosting environment with Plesk and My App Server, this usually means coordinating the application files, database export/import, and any runtime-specific settings such as JDBC drivers, datasource names, and context configuration.

This guide explains a practical way to migrate a database-backed JSP application to a new hosting account or another server. It is written for JSP hosting, Tomcat hosting, and Java hosting setups where you manage your application through a control panel and deploy either a WAR file or unpacked application files.

What you need to migrate

A database-backed JSP application usually contains four parts:

Application files – JSP pages, servlets, classes, static assets, and configuration files.
Database – MySQL, MariaDB, PostgreSQL, or another database used by the application.
Connection settings – JDBC URL, username, password, driver class, and datasource configuration.
Runtime environment – Tomcat version, Java version, context path, and any app server settings.

If one of these parts is missed, the application may deploy but fail at login, show database errors, or start with a blank page.

Before you start the migration

Plan the migration before changing DNS or switching traffic. The safest approach is to prepare the new hosting account first, test the application on the new environment, and only then point the domain to it.

Check the current application setup

Collect the following information from the source environment:

JSP framework or application server version
Java version in use
Tomcat version or servlet container version
Database type and version
Database name, user, and host
Application context path
Any environment variables or custom JVM parameters
External services used by the app, such as SMTP or file storage

If your app runs under My App Server, note the service name, whether it uses a private JVM, and whether the application is deployed from a WAR file or from extracted files.

Make a full backup

Always create backups before migration:

Backup all application files
Export the database
Save any custom configuration files
Copy uploaded files, attachments, and media directories
Record scheduled tasks or cron jobs if the app uses them

For JSP applications, uploaded content is often outside the WAR package. Do not assume that deploying the application code is enough. Check for folders such as uploads, files, media, attachments, or custom directories used by the application.

Prepare the target hosting account

In a Plesk-based Java hosting environment, the first step is to create or activate the Java service for the destination domain or subscription. With My App Server, you can install a ready-made Tomcat version or configure a custom app server if your application needs a specific runtime.

Choose the correct Java and Tomcat version

Try to match the source environment as closely as possible. If the old application ran on an older Tomcat or Java release, test compatibility before switching production traffic. Some JSP applications depend on older libraries or servlet behavior.

In practice, you should:

Select a Java version supported by the application
Install the Tomcat version that matches the app requirements
Confirm that the application can use the same servlet/JSP APIs
Check whether the app needs a specific character encoding or locale

If you are not sure which version to use, review the application documentation or check the WEB-INF configuration files.

Create the database on the new server

Before importing data, create a new database and database user in the destination control panel. Assign only the permissions required by the application. In most cases, the application needs standard read/write privileges, not full administrative access.

Write down:

Database name
Database username
Database password
Database host or socket value
Port number, if custom

If the new hosting environment uses a different host address or different database port, you will need to update the application configuration after the import.

Export the database from the old environment

The most common way to migrate the database is with a SQL dump. You can create this dump from phpMyAdmin, the database console, or a command line tool depending on your access level.

Recommended export options

When exporting, make sure the dump includes:

Tables and table structure
Data rows
Indexes and primary keys
Auto increment values
Stored procedures or triggers, if used

If the application uses MySQL or MariaDB, a plain SQL dump is usually the simplest method. For large databases, consider exporting in chunks or using a compressed file to reduce transfer size.

What to check in the dump

Open the SQL file and verify that it contains the correct database statements. If the old and new servers use different database names, you may need to remove or edit CREATE DATABASE and USE statements before importing.

Also check for:

Engine-specific syntax that may not be supported on the target server
Character set declarations
Collation settings
Absolute path references inside stored data, if applicable

Import the database on the new hosting account

Import the SQL file into the database created on the destination server. In a control panel environment, this is usually done through phpMyAdmin or another database tool provided by the hosting platform.

After import, verify the data

Do a quick check after the import:

Confirm that all tables were created
Check row counts for key tables
Make sure there are no import errors
Verify that UTF-8 or the original encoding displays correctly

If the application shows missing text, broken symbols, or garbled content, the issue is often related to character set mismatch. In that case, compare the database collation, table collation, and the connection settings used by the JSP application.

Move the application files

Next, transfer the application code from the old hosting account to the new one. Depending on how the app is packaged, this may mean uploading a WAR file, copying an exploded web application directory, or moving a source tree that is built during deploy.

Common file locations to include

WEB-INF/web.xml
WEB-INF/lib for third-party JARs
WEB-INF/classes for compiled classes and properties
JSP files in the web root or subfolders
Static assets such as CSS, JavaScript, and images
Upload folders and generated content

Do not forget hidden or server-specific files. Some JSP applications also use configuration files like .properties, XML descriptors, or environment-specific settings stored outside the WAR archive.

Pay attention to file permissions

After upload, confirm that the web application can read its files and write to the directories that need write access. This is especially important for logs, uploads, cache folders, and temporary files. If your app is hosted in a managed Java environment, the control panel and app server service must have the right filesystem permissions for the application to start and operate normally.

Update database connection settings

Once the database and files are in place, update the application so it connects to the new database host and credentials.

Where connection settings are usually stored

Depending on the application, database details may be stored in:

WEB-INF/classes/*.properties
XML configuration files
Environment variables
Tomcat context configuration
JNDI datasource definitions
Application-specific config files outside the web root

Typical settings include:

JDBC URL
Database username
Database password
Driver class name
Pool settings, if used

Example of what to verify

Old host: jdbc:mysql://old-host.example:3306/appdb
New host: jdbc:mysql://localhost:3306/appdb or the host shown in the control panel

After migration, even small differences such as hostname, port, SSL requirement, or database name can cause connection failures. If the application uses a connection pool, restart the Tomcat or private JVM service after updating settings so the new values are loaded.

Configure Tomcat or My App Server correctly

In a managed JSP hosting setup, the app server configuration matters as much as the application files. My App Server is designed to give you practical control over the Java runtime, Tomcat service, and deployment process inside the hosting account.

Check the context path

If the application used a specific context path on the old host, make sure the new deployment uses the same path or that all internal links are updated. A mismatch can break login redirects, API endpoints, and asset loading.

Review JVM and server settings

Some applications need custom JVM memory values, system properties, or encoding flags. Check whether the app expects:

-Xms and -Xmx memory settings
UTF-8 default encoding
Timezone settings
Application-specific system properties

If your hosting plan uses a private JVM, verify that the service starts with the same or compatible parameters as the original environment.

Install missing libraries if necessary

Many migration issues happen because the old server had a library that is missing on the new one. If the app fails with ClassNotFoundException or NoClassDefFoundError, check the WEB-INF/lib folder and any server-level dependencies used by Tomcat.

If the application relied on a custom JDBC driver, upload it to the correct location and make sure the runtime can load it.

Test the application before switching traffic

Before updating DNS, test the migrated app on the new environment using a temporary URL, hosts file entry, or staging domain if available. This helps you catch issues without affecting users.

Test checklist

Homepage loads correctly
Login works
Database reads and writes succeed
Forms submit without errors
File uploads work
Images and static assets load
Admin pages open correctly
Sessions persist during navigation

Also check the logs. Tomcat logs and application logs are often the fastest way to find the source of migration problems. Look for SQL exceptions, permission issues, missing classes, or incorrect context paths.

Common migration problems and how to fix them

Application starts but database calls fail

This usually means one of the following:

Wrong database credentials
Incorrect JDBC URL
Missing JDBC driver
Database user does not have enough privileges
Database host or port is wrong

Recheck the config file and restart the app server after making changes.

JSP pages show encoding problems

Encoding issues often happen after migration to a new environment with different defaults. Confirm that the application uses the same character set end to end: database, JSP page directives, request handling, and response headers.

Look for:

UTF-8 declarations in JSP files
Database collation consistency
Servlet filters that set request and response encoding

Uploads or generated files disappeared

These files are often not part of the WAR package and must be copied separately. Verify the exact path used by the application and move the content manually if needed.

Application works in browser but not after login

This can happen if sessions, cookies, or redirects depend on an old context path or domain. Check cookie settings, base URLs, and any hardcoded links inside the JSP templates.

Tomcat service does not start

Look at the service logs and validate the runtime configuration. Common causes include unsupported Java version, bad JVM options, broken XML configuration, or file permission issues.

Recommended migration order

A reliable migration sequence for a database-backed JSP application is:

Back up files and database on the old host
Create the new database and user
Import the database dump
Upload the application files
Update configuration files with new connection details
Check Tomcat or My App Server settings
Test on the new environment
Switch DNS or domain routing when the app is ready

This order reduces downtime and makes troubleshooting easier because each layer is verified separately.

Best practices for JSP database migrations

Keep the old site available until the new one is fully tested
Use the same Java and Tomcat versions when possible
Export and import the database in a known character set
Store passwords securely and update them only in the right config files
Document every change you make during migration
Check logs immediately after first start
Preserve uploaded files and custom content folders separately from the code

For managed Java hosting environments, the biggest advantage is that you can control the runtime without handling a full enterprise stack. A private JVM and Tomcat service are usually enough for small and medium JSP applications that need predictable deployment and straightforward administration through Plesk.

FAQ

Can I migrate only the WAR file and skip the database?

Only if the application is static or does not use data storage. Most JSP applications that rely on login, content management, shopping carts, or admin panels need the database migrated as well.

Do I need the same Tomcat version on the new host?

It is strongly recommended. A different Tomcat version may work, but it can also introduce compatibility issues. If you must change versions, test the application carefully before going live.

Where should I update database credentials in a JSP app?

It depends on the application. Common locations are properties files, XML config, JNDI datasource definitions, or environment-specific settings in the web application. Search the codebase for the old database host, username, or database name.

What if my application uses a custom JDBC driver?

Upload the driver JAR to the correct library location and make sure Tomcat or the private JVM can load it. Then restart the service and test the connection again.

Can I test the migrated application before changing DNS?

Yes. That is the recommended approach. Use a temporary URL, hosts file override, or staging domain so you can verify the new setup before public traffic is moved.

Why does the app work locally but fail on the hosting account?

Differences in Java version, Tomcat version, file permissions, datasource settings, or character encoding are common causes. Review the logs first, then compare the runtime and config with the source environment.

Conclusion

Migrating a database-backed JSP application requires more than moving files. To complete the process safely, transfer the database, update connection settings, verify the Java and Tomcat runtime, and test the application before switching the domain. In a Plesk-based hosting environment with My App Server, this workflow gives you practical control over the application while keeping deployment manageable for standard JSP, servlet, and Tomcat use cases.

When the files, database, and runtime are aligned, most migrations can be completed with minimal downtime and fewer surprises after launch.

How to migrate a database-backed JSP application