After moving a JSP project to a new hosting account or a different deployment path, the application usually fails for one of three reasons: the database connection still points to the old server, the configuration file still contains the previous hostname or credentials, or the Tomcat/JSP runtime cannot read the updated path and service settings. In a managed hosting environment with Plesk and a private JVM or Tomcat instance, these changes are normally straightforward once you know where the project stores its configuration and how the database access is defined.
This guide explains how to update config and database access after moving a JSP project, with practical steps for hosting users who deploy WAR files, JSP applications, servlet-based apps, or custom Java web applications through a control panel such as Plesk and a Java hosting service like My App Server.
What usually changes after a JSP project move
When a JSP application is moved, the application files may be copied successfully, but the runtime context changes. The most common items that must be checked are:
- Database hostname, database name, username, and password
- JDBC connection string, pool settings, and driver class name
- Application configuration files such as
*.properties,*.xml,*.yml, or environment-specific config - Absolute paths to uploads, logs, temporary files, or exports
- Java version and Tomcat version compatibility
- Permissions for the new document root, application directory, or service user
If your JSP app uses session storage, scheduled jobs, file uploads, or local cache folders, those may also need adjustment after migration.
Find where the application stores its configuration
Before changing anything, identify which files control the app’s environment. In JSP and Tomcat applications, configuration is often stored outside the web pages themselves.
Common config locations
WEB-INF/classes/for properties files and application resourcesWEB-INF/web.xmlfor servlet and application settingscontext.xmlfor datasource definitionsserver.xmlor Tomcat-specific service files for advanced server settings- External files under a private config directory, often set by the deployment process
- Plesk-managed service or app settings if the hosting platform provides them
If the application was deployed as a WAR file, some settings may be inside the archive and others may be loaded from an external path. If possible, keep environment-specific settings outside the WAR so they can be updated without rebuilding the application.
Look for hardcoded old values
Search the project for the old database server name, old IP address, old path, and old credentials. Typical places include:
.propertiesfiles- Spring or framework config files
- JDBC utility classes
- XML datasource definitions
- Deployment scripts
A practical search for strings such as the previous domain, localhost, an old port, or an old schema name can quickly reveal what needs to be changed.
Update the database connection details
In most JSP hosting setups, database access is one of the first things to break after a move. The application may still start, but pages that query the database will return errors such as connection refused, authentication failed, or table not found.
Check the new database account
Create or confirm the database in your hosting control panel. Then verify the following values:
- Database name
- Database username
- Database password
- Database host or server address
- Port number
- Required privileges for the user
In many managed hosting environments, the database host is not the same as the web host. It may be a separate internal hostname provided by the platform. Use the values shown in the control panel or service documentation, not the old local development settings.
Update JDBC URL
The JDBC URL often needs to be changed after migration. A MySQL example may look like this:
jdbc:mysql://db-host.example:3306/new_database
An app moved from one provider to another may also need driver updates. For example, newer MySQL deployments often use com.mysql.cj.jdbc.Driver, while older applications may still use legacy driver names.
If you use PostgreSQL, the pattern is similar:
jdbc:postgresql://db-host.example:5432/new_database
Make sure the URL matches the new database server, port, and schema name. If SSL is required or supported, check whether the JDBC URL needs additional parameters.
Update username and password securely
Do not leave the old credentials inside the app package. Replace them in the config file, environment variables, or datasource settings. If your hosting panel supports application-level secrets or service settings, use those instead of embedding credentials in source code.
If the project is shared with multiple environments, keep separate values for local, staging, and production. That reduces the chance of accidentally connecting to the wrong database after future moves.
Confirm database privileges
Even with correct credentials, the application may fail if the database user does not have the right permissions. For a JSP application, the user commonly needs:
- SELECT for reading data
- INSERT for new records
- UPDATE for editing records
- DELETE if the app removes data
- CREATE, ALTER, and INDEX for schema changes during upgrades
If the application uses initialization scripts, check whether the new account has enough rights to create or migrate tables.
Adjust configuration files for the new hosting environment
Moving a JSP project is not only about database access. A typical application also has environment-dependent settings that must be aligned with the new hosting account.
Update application paths
After a move, any hardcoded file path may become invalid. Review values for:
- Upload folders
- Image or document storage paths
- Export directories
- Log file paths
- Temporary folders
- Config directories
Use relative paths where possible, or set paths based on the application’s runtime directory. This makes the app easier to move between hosting accounts.
Check Tomcat-related settings
If your application runs on a private Tomcat instance through My App Server, confirm that the service configuration matches the deployed app. This can include:
- Context path
- Memory limits
- Java runtime version
- JSP compilation settings
- Session timeout
- Port bindings if custom ports are used
Some hosting platforms allow you to control the app server directly from Plesk. In that case, service start, stop, restart, and version selection are usually handled in the control panel rather than in a shell script.
Review environment variables
Modern Java applications often use environment variables for database access and runtime options. After migration, confirm that any required variables are still set, such as:
JAVA_HOMECATALINA_HOMECATALINA_BASE- Custom application variables for database or API access
If the platform uses a private JVM or isolated service instance, these values are typically managed by the hosting system, but custom variables may still need to be re-entered.
Update datasource settings in Tomcat if needed
Some JSP applications connect to the database through a Tomcat datasource instead of creating connections directly in code. This is common when the app is deployed to a managed Java hosting service and should be checked carefully after a move.
Typical datasource items to verify
- Resource name used by the app
- JDBC driver class
- Connection URL
- Username and password
- Maximum active and idle connections
- Validation query
If the application uses JNDI lookup, the name in the application code must match the datasource name defined in Tomcat or in the hosting panel. A mismatch here is a common reason for runtime errors after migration.
Test direct database access first
Before testing the full JSP application, verify that the new database credentials work outside the app. If the database itself is reachable and the user can log in, you reduce the number of possible causes when troubleshooting the JSP project.
Check the web application descriptor and deployment path
Sometimes the code is correct, but the app still fails because the deployment path changed.
Review web.xml and context paths
The web.xml file may contain servlet mappings, welcome pages, or init parameters that affect runtime behavior. After moving the project, ensure that the application is still deployed under the correct context path and that any path-based references remain valid.
If your site used to live at a different base URL, links to internal pages, callback URLs, or redirects may need to be updated as well.
Check file permissions
In a hosted environment, the application user must be able to read deployed files and write to required folders. If uploads or log generation fail after the move, verify permissions on:
- Application directory
- Upload directory
- Temp directory
- Log directory
With a private Tomcat or JVM service, the service account must also have permission to access those directories.
Rebuild or redeploy if the configuration is packaged inside the app
If the app stores its config inside the WAR or inside compiled resources, you may need to rebuild it after editing the settings. This is common when properties are bundled into the project during the build process.
When to rebuild
- The config file is inside the source tree and gets packaged into the WAR
- The database URL is compiled into a Java class
- The app reads values from build-time resources
- The deployment package is cached and does not pick up manual changes
After rebuilding, redeploy the application to the new Tomcat instance or service and restart the server if required.
When to edit without rebuilding
- The app reads an external properties file
- The control panel allows direct config editing
- The datasource is configured at the server level
- The app loads values from environment variables
External configuration is usually easier to maintain because you can update credentials or paths without repackaging the application.
Restart the service and test the app
After updating database access and configuration, restart the Java service or Tomcat instance so the new values are loaded. In a managed hosting environment, this is usually done from the control panel.
Test in this order
- Confirm the database server responds
- Confirm the credentials work
- Confirm the application starts without startup errors
- Open a page that reads data from the database
- Test a form or action that writes data
- Check upload, export, and log functionality
If the app loads the home page but not deeper pages, the issue may be in a query, datasource, or path-specific configuration rather than the deployment itself.
Common errors after moving a JSP project
Database connection refused
This usually means the JDBC URL points to the wrong host or port, the database server is unreachable from the hosting account, or a firewall or provider setting blocks access.
Access denied for user
This normally means the username or password is wrong, or the database user does not have access to the schema.
Class not found for JDBC driver
Check whether the correct driver JAR is present in the application or Tomcat library folder, and verify that the driver class name matches the installed version.
File not found or permission denied
This often happens when the app still points to an old local path or a directory that does not exist in the new hosting account.
Application starts but shows blank pages or 500 errors
Review the Tomcat logs and application logs. A bad config value, invalid datasource, or failed initialization code often appears there first.
Best practices for future JSP migrations
If you want the next move to be easier, structure the app so that config and database settings can be changed without touching the business logic.
- Store environment settings outside the WAR file
- Use a single config source for database access
- Avoid hardcoded absolute paths
- Document the required Java and Tomcat versions
- Keep a backup of the working config before each move
- Test the app on a staging deployment before switching production traffic
For JSP hosting, servlet hosting, and small to medium Java applications, this approach makes deployment simpler and reduces downtime during migration.
FAQ
Do I need to change code when I move a JSP project?
Not always. If your application uses external config files or control panel settings, you may only need to update database credentials, paths, or datasource values. Code changes are usually needed only if values were hardcoded into Java classes or JSP files.
Where should I store database credentials in a hosted JSP app?
The safest option is outside the source code, such as an external properties file, environment variables, or a server-managed datasource. This makes future moves and password changes easier.
Why does the app work locally but fail after deployment?
Local setup often uses a different database host, different Java version, or local file paths. After deployment, all of these may change, so the app must be adjusted to match the hosting environment.
Should I use localhost in the JDBC URL?
Only if the database runs on the same server and the hosting platform is configured that way. In many managed hosting setups, the database host is separate, so use the hostname provided by the control panel or hosting documentation.
What should I check first if a JSP app shows a 500 error after migration?
Check the application logs and Tomcat logs first. Then verify database access, config file values, driver availability, and file permissions. A 500 error usually points to a startup or runtime configuration issue.
Can I manage a private Tomcat instance from Plesk?
Yes, in a managed Java hosting setup with a service like My App Server, Tomcat and private JVM services can be controlled from the hosting panel. That usually includes service start, stop, restart, version selection, and deployment-related settings.
Conclusion
Updating config and database access after moving a JSP project is mostly a matter of aligning the application with its new hosting environment. Focus first on the JDBC connection, then review config files, paths, datasource settings, permissions, and Tomcat service options. In a Plesk-based Java hosting setup with private Tomcat or JVM control, these changes can usually be completed quickly once the app’s configuration structure is understood.
For the best results, keep environment-specific settings outside the application package, document all database values, and test the deployed site page by page after each migration. That way, future moves are easier, safer, and much faster to troubleshoot.