After moving a JSP project to a new hosting account, the application usually fails for one of three reasons: the runtime points to the old paths, the database connection still uses the previous credentials, or file permissions and service settings were not updated for the new environment. In a managed hosting setup with Plesk and a private Tomcat instance, these issues are common after a migration, but they are usually quick to fix once you know where to look.
This guide explains how to update your JSP configuration and database access after a move, with practical steps for Tomcat hosting, JSP hosting, and shared hosting accounts that use a private JVM through My App Server. It also covers what to check in your web app, which config files are most often involved, and how to validate the application before putting it back into production.
What usually changes after moving a JSP application
When a JSP project is moved to a new hosting platform or a different account, the code may remain the same, but the environment does not. That means the application may need updated settings for:
- database host, database name, username, and password
- JDBC driver location or version compatibility
- Tomcat context path or application root directory
- filesystem paths used by uploads, logs, or temporary files
- Java version selected for the app server
- service permissions and file ownership in the hosting control panel
If your hosting platform provides a Plesk extension for Java applications, such as a private Tomcat service, the move is often straightforward: deploy the WAR or application files, update configuration, restart the service, and test the connection. Still, the exact steps depend on how the application stores its settings.
Check where the application stores its configuration
Before editing anything, find out whether the project keeps settings in a file, in environment variables, or in a database table. JSP applications often use one of these common patterns:
1. Properties files
Many projects store database credentials and paths in files such as:
db.propertiesapplication.propertiesconfig.propertiesjdbc.properties
These files may sit under WEB-INF, inside the source tree, or in an external directory referenced by the app.
2. XML configuration files
Some JSP and Java web applications use XML files such as:
context.xmlweb.xmlhibernate.cfg.xmlspring-config.xml
In Tomcat-based hosting, context.xml is often used for JNDI database resources, while web.xml may define servlets, filters, and initialization parameters.
3. External environment variables or control panel settings
With a managed hosting platform, part of the configuration may be stored in the control panel instead of inside the application package. In a Plesk-based Java hosting environment, you may need to update application settings, service options, or startup parameters from the hosting interface.
Update database access after the move
Database access is the most common item that needs adjustment after migration. A moved JSP application often still points to the old database server, the old schema name, or a credential that is not valid on the new account.
Step 1: collect the new database details
From your hosting panel or database management screen, note the following values:
- database host or server name
- database name
- database username
- database password
- database port, if it is not the default
- JDBC URL format required by the database engine
For example, a MySQL or MariaDB JDBC URL may look similar to:
jdbc:mysql://dbhost.example.com:3306/database_name
For PostgreSQL, the format may be different:
jdbc:postgresql://dbhost.example.com:5432/database_name
Use the exact format expected by your driver and application framework.
Step 2: update the JDBC connection string
Search the project for the old connection details. Typical places include:
- properties files
- Spring configuration
- JNDI resource definitions
- custom DAO classes
- startup scripts or wrapper files
If the application uses a hardcoded JDBC URL, replace the host, database name, and port. If it uses a JNDI resource, verify that the resource name in the app matches the one configured in Tomcat or in the hosting control panel.
Step 3: replace the database username and password
After a move, the new hosting account usually has its own database user. Even if the schema was imported successfully, the old login may not work on the new platform. Update the username and password in the application config and make sure the user has the required privileges.
Common permissions needed by JSP applications include:
- SELECT
- INSERT
- UPDATE
- DELETE
- CREATE, ALTER, or DROP when the app performs schema changes
If your application uses a read-only reporting database, then the privilege set may be smaller. Always grant only the rights the app actually needs.
Step 4: test the connection before starting the app
Where possible, test the database login separately before restarting Tomcat. This helps you identify whether the issue is with the credentials, the driver, or the application code itself.
In a managed hosting environment, you can usually test by:
- using the database tool in the control panel
- running a simple connection check page
- reviewing Tomcat or application logs after startup
Check JDBC driver compatibility
After migration, a JSP application may fail because the database driver is missing or does not match the installed Java version. This is especially relevant in a private JVM setup where you can choose the Java runtime for the app.
What to verify
- the JDBC driver JAR is present in the application or server classpath
- the driver version supports your database server version
- the driver is compatible with the selected Java version
- the application is not loading an outdated driver from a previous deployment
If the old server had the driver bundled globally, but the new hosting account expects it inside the application, you may need to add the JAR to WEB-INF/lib or update the service configuration in My App Server.
Update file paths and upload locations
Many JSP projects store uploads, generated reports, cache files, or temporary files outside the web root. After a move, those paths often still point to the old server or old account structure.
Common path changes to look for
- absolute paths like
/home/olduser/app/uploads/ - Windows paths from development environments
- temporary directory references
- log file directories
- export or import folders
On a hosted Linux environment, use paths that match the current account structure. If the application requires a writable directory, confirm that the directory exists and has the correct permissions.
Practical example
If the old application used:
/var/www/oldsite/uploads
and the new account uses a private app directory under the hosting account, change it to the new valid location, for example:
/home/username/app/uploads
Use the exact path shown by your hosting panel or file manager.
Review Tomcat settings in My App Server or Plesk
If your JSP application is deployed through a control panel-based Java hosting solution, check the Tomcat service settings after migration. A project may run fine on one environment and fail on another if the app server version, Java version, or startup configuration changed.
Verify the Java version
Ensure the selected Java version is supported by your application. Older JSP applications may depend on a specific Java release, while newer projects may need a more recent runtime. If your hosting platform lets you choose the Java version per application, confirm the selection before starting the service.
Verify the deployment path
Make sure the application root, context path, and deployed WAR file location are correct. A missing context path may lead to 404 errors, while a wrong web root may cause the wrong app version to load.
Restart the private Tomcat service
After updating config files or database credentials, restart the service so the new settings are loaded. In a managed hosting environment, this is often done from the control panel rather than from the shell. If your platform provides service controls for the app server, use them to stop and start the app cleanly.
Update web.xml or context.xml if the app uses JNDI
Some JSP applications do not connect directly with hardcoded credentials. Instead, they use a JNDI resource configured in Tomcat. This can be a cleaner setup, but it requires the application and the server configuration to match after a move.
What to check in context.xml
If the project uses a resource definition, review the following:
- resource name
- database URL
- username and password
- driver class name
- connection pool settings
Make sure the resource name defined in Tomcat is the same one referenced in the application. If the old environment used a different naming convention, the app may start but still fail when it tries to connect.
What to check in web.xml
Look for:
- resource references in
resource-ref - initialization parameters that point to old paths
- servlet mappings that changed during the migration
Even if the database settings are correct, a broken initialization parameter can stop the app from reading its configuration properly.
Move the database content correctly
Updating credentials is not enough if the actual database data was not imported or if the schema differs from the old server. After moving a JSP project, confirm that the database content is complete.
Checklist for database migration
- all tables were exported from the old database
- the import completed without errors
- stored procedures, views, and triggers were included if needed
- character encoding matches the application
- the database user has access to the imported schema
Encoding issues are common with JSP applications that handle multilingual content. If special characters appear broken after the move, compare the source and target encoding settings, especially for UTF-8.
Fix file ownership and permissions
In hosted Java environments, permission problems can prevent Tomcat from reading config files or writing to upload folders. After a move, check that the application can access what it needs.
What to verify
- the application files are readable by the app server process
- upload directories are writable
- log directories exist and can be created if missing
- temporary file paths are writable
If your hosting platform uses a private JVM managed through the control panel, permissions are usually easier to handle than on a custom server, but you should still confirm them after deployment.
Test the application after updating config and database access
Do not assume the app is working just because the homepage loads. A JSP site can appear functional while backend features are still broken. Test the application in a structured way.
Recommended testing order
- open the homepage and confirm the correct version is deployed
- log in if the application has authentication
- submit a form that writes to the database
- check an edit or update operation
- test upload functionality if the site stores files
- review error pages and logs for hidden failures
If the application throws an exception, check the stack trace for the exact cause. Common database errors include invalid credentials, unknown host, connection refused, driver not found, and permission denied.
Common errors after moving a JSP project
SQLException: Access denied
This usually means the database username or password is incorrect, or the user does not have rights on the new schema.
Unknown host or connection timeout
The JDBC URL may still point to the old database server, or the database host value was not updated.
ClassNotFoundException for JDBC driver
The driver JAR is missing from the new environment or is not loaded by the current Java/Tomcat setup.
404 or application not found
The context path or deployment location may be wrong after the move.
Permission denied when uploading files
The upload directory exists, but Tomcat cannot write to it. Review directory permissions and ownership.
Broken characters in content
The database encoding, page encoding, or connection settings may not match the original environment.
Recommended migration checklist
Use this checklist after every move of a JSP project on a hosting platform:
- confirm the WAR or project files were uploaded to the correct location
- update database host, name, user, and password
- verify JDBC URL and driver class name
- check JNDI resources if used
- change all old file paths to the new account structure
- verify Java version in the app server
- restart Tomcat or the private JVM
- test login, forms, uploads, and database writes
- review logs for warnings and exceptions
FAQ
Do I need to edit the JSP files themselves after a move?
Usually not. In most cases, the changes are in config files, database settings, deployment paths, or control panel settings. Only edit JSP code directly if the project hardcodes paths or credentials inside the source.
Where should I store database credentials in a JSP application?
It is better to keep credentials out of JSP pages and place them in a properties file, XML config, or JNDI resource. That makes migration and maintenance easier.
What if the app worked on the old host but not on the new one?
Check the Java version, JDBC driver, database permissions, and file paths first. These are the most common differences between hosting environments.
Can I reuse the same database name after moving?
Only if the new hosting account and database setup support it. Often the database name can be similar, but the host, username, and password will still need to be updated.
How do I know if my app uses JNDI?
Search for resource references in web.xml, context.xml, or your framework configuration. If the application looks up a datasource by name rather than using direct JDBC credentials, it is likely using JNDI.
What logs should I check first?
Start with the Tomcat logs and the application error log if your hosting panel exposes one. They usually show whether the issue is related to database connection, missing files, or startup configuration.
Conclusion
Updating config and database access after moving a JSP project is mostly about finding every place where the old environment is still referenced. In a Plesk-based Java hosting setup with a private Tomcat service, that usually means checking database credentials, JDBC URLs, file paths, Java version, and deployment settings before restarting the app server.
If you follow a clear checklist and test the app step by step, most migration issues can be fixed quickly without changing the application logic. For JSP hosting, servlet hosting, and small to medium Java applications, this approach keeps the move predictable and helps the project run cleanly in the new hosting account.