When you move a JSP application to a new host, the code often works exactly as before, but the configuration no longer matches the new environment. Paths, database credentials, mail settings, JVM options, and Tomcat-specific values are usually the first items that need attention. In a managed hosting setup with Plesk and a private Tomcat instance such as My App Server, these updates are usually straightforward, but they still need to be done carefully to avoid startup errors, broken connections, or hidden environment mismatches.
This guide explains how to review and update config files after migrating a JSP app to a new hosting account. It is written for Java hosting, Tomcat hosting, servlet hosting, and JSP hosting environments where the application may run in its own JVM and be managed through a control panel.
What usually changes after a JSP app migration
A JSP application may depend on several types of configuration. After moving to a new host, the most common changes are:
- Database host, database name, username, and password
- JDBC driver class name or driver JAR location
- File system paths for uploads, logs, exports, cache, or temporary files
- SMTP server settings for outbound email
- Base URL, callback URL, or environment-specific application URLs
- Java version settings and JVM options
- Tomcat context parameters, server ports, and resource definitions
- Permission-related values, especially if the old host used different directory structures
In many JSP projects, these values are stored in one or more files such as .properties, .xml, context.xml, web.xml, environment scripts, or application-specific config files. Some applications also read values from system properties or environment variables.
Check where the application stores its environment values
Before editing anything, identify where the app keeps its configuration. This is important because different frameworks and deployment styles store values in different places.
Common configuration file types in JSP and Tomcat apps
application.propertiesor similar properties filesconfig.properties,settings.properties,db.propertiescontext.xmlfor JNDI resources or Tomcat context settingsweb.xmlfor init parameters and resource referencesserver.xmlor Tomcat service configuration, when custom server tuning is used- Framework files such as Spring XML, Hibernate configuration, or custom XML descriptors
- Shell scripts or startup scripts used for private JVM settings
If your hosting plan includes My App Server, some values may be managed in Plesk through the Java hosting extension instead of being edited directly in Tomcat files. That is often the preferred method for service control, Java version selection, and runtime parameters.
Find hardcoded values and external references
Look for:
- Absolute paths such as
/var/www/...,/home/olduser/..., or Windows-style paths from a previous environment - Old hostnames, IP addresses, or database server names
- Ports that may differ on the new host
- File names or directories that no longer exist
- Credentials stored directly in files
Search the application package for strings such as localhost, jdbc:, smtp, upload, temp, log, and the old domain name. That usually reveals where the app expects environment-specific values.
Update database settings first
For most JSP applications, database access is the first thing that fails after a move. If the application cannot connect to the database, the rest of the site may still load partially, but dynamic pages will return errors.
Verify the new database details
In the hosting control panel, confirm:
- Database name
- Database username
- Password
- Database host, if it is not
localhost - Port, if the database uses a non-default value
Some hosting platforms use a local database service, while others provide a separate database host name. Never assume the old host values will work on the new account.
Check JDBC connection strings
Example database URL formats often look like this:
jdbc:mysql://localhost:3306/dbnamejdbc:mariadb://localhost:3306/dbnamejdbc:postgresql://dbhost:5432/dbname
Make sure the URL matches the database engine and host environment. If your old setup used one driver and the new server uses another supported version, review the JDBC driver JAR and compatibility notes before restarting Tomcat.
Review JNDI datasource settings
If the application uses JNDI, check both the application configuration and the Tomcat resource definition. In a managed Tomcat setup, datasource details may be defined in context.xml or in a Plesk-managed Java service area rather than inside the application WAR.
Typical values to confirm are:
nameof the datasource referencedriverClassNameurlusernamepassword- Connection pool parameters, if used
Adjust file paths for the new hosting account
Moving to a new host often means a different directory structure, even when the application files are copied correctly. Any file path pointing to uploads, logs, attachments, cache, exports, or backup folders may need to be updated.
Review writable directories
Common directories that need revision include:
- Upload folders
- Temporary folders
- Generated report directories
- Export or import folders
- Image cache or thumbnail directories
- Application logs
On a shared hosting account with a private JVM, it is usually best to store writable data outside the deployed application package if the platform recommends that approach. That helps preserve data during redeploys and reduces the risk of losing files when the WAR is replaced.
Prefer relative or configurable paths
If possible, avoid hardcoding absolute paths in Java source or config files. Use variables such as:
app.homeupload.dirlog.dirtemp.dir
Then define those values in a single config file or as JVM system properties. This makes future migrations much easier.
Update Tomcat and JVM-related settings
When the application runs on a private JVM or managed Tomcat instance through My App Server, the runtime configuration can matter as much as the app config. Some JSP apps need specific memory settings, encoding options, or startup parameters.
Confirm the Java version
Make sure the new host is using a Java version compatible with your application. If the app was built for an older or newer runtime, mismatches can cause compilation or runtime errors. Managed Java hosting often lets you choose from several ready-to-use Java or Tomcat versions, and in some cases you can upload and configure a custom version manually.
Review JVM options
Typical JVM settings that may need attention include:
-Xmsand-Xmxmemory values- Garbage collector flags
- Character encoding options such as UTF-8
- Timezone settings
- Application-specific system properties
If you use Plesk with My App Server, these options are often controlled through the service settings rather than by editing low-level startup files. That reduces the risk of breaking the service configuration.
Check Tomcat context parameters
Some JSP applications rely on context parameters defined in Tomcat, for example:
- Database JNDI resources
- Environment flags such as development or production mode
- Session timeout values
- Custom resource links
Make sure any context definitions still match the application package name and deployment path after the move. A changed context root can break relative URLs or resource lookups.
Fix environment-specific URLs and integration points
After moving to a new host, the application may still point to the old domain, old callback endpoint, or old API location. These values are often forgotten because the app loads successfully, but background functions fail later.
Common URL values to update
- Base application URL
- Login redirect URL
- Payment gateway callback or webhook URL
- OAuth redirect URI
- SMTP server host
- External API endpoints
- CDN or static asset URL
If your new host uses a different domain or temporary migration URL, update any absolute references inside config files, JSP templates, or Java properties. This is especially important for authentication flows and third-party integrations.
Update email and notification settings
Email settings often break during migration because the SMTP server or sender address is tied to the old environment. Check:
- SMTP host
- SMTP port
- Username and password
- SSL or TLS requirements
- From address and reply-to address
If the application uses the hosting platform’s mail service, confirm the allowed relay settings in the control panel and verify that the app is using the correct host name and authentication method.
Use a safe process for editing config files
Editing configuration after a migration should be done in a controlled way. A small syntax mistake in a properties file, XML file, or Tomcat context file can prevent the app from starting.
Recommended workflow
- Make a backup of the original config files.
- Edit one file at a time.
- Change only the values that are tied to the old host.
- Keep comments, spacing, and encoding intact.
- Validate XML syntax if the file is XML-based.
- Save the file in UTF-8 unless the application explicitly requires another encoding.
- Restart or reload the Java service after each major change.
Watch for common formatting mistakes
- Missing quotation marks in XML attributes
- Trailing spaces in passwords or URLs
- Incorrect escape characters in properties files
- Broken line endings when moving files between systems
- Accidentally editing binary or compiled files instead of source config
If your hosting platform provides file management through Plesk, use it carefully and download a local copy before making larger changes. For repeated edits, SFTP or SSH access is usually more reliable than editing directly in the browser.
Test the application in a structured order
After changing configuration, test the app step by step instead of opening every feature at once. That makes it easier to identify what still points to the old host.
Suggested test order
- Start the Tomcat service and confirm that it stays running.
- Check the startup log for syntax errors or missing resources.
- Load the home page and confirm that the application responds.
- Test database-backed pages.
- Test login, session handling, and form submissions.
- Verify uploads, downloads, and file writes.
- Test email notifications.
- Confirm any third-party API calls or payment callbacks.
If the app starts but specific pages fail, the logs usually point to the remaining config mismatch. Common errors include connection refused, authentication failed, file not found, class not found, and permission denied.
Where to look in a Plesk managed Java hosting setup
In a hosting environment with Plesk and My App Server, many administrative actions can be done without touching low-level server files directly. That is useful when you want to update runtime values safely within the hosting account.
Useful places to review
- Java application settings in the hosting control panel
- Tomcat service control and restart options
- Java version selection
- Custom JVM arguments
- Application deployment path
- Log files for the Java service and the web application
If you are using a private JVM inside a shared hosting account, remember that the service may have account-specific limits. Those limits can affect memory, process count, or resource usage, so it is important to tune the application realistically for the hosting plan.
Example migration checklist for JSP config files
Use this practical checklist when moving a JSP application to a new host:
- Confirm the application package was uploaded completely
- Identify all config files used by the app
- Change database host, name, username, and password
- Update JDBC URL and driver settings if needed
- Replace old file system paths with valid paths on the new account
- Update SMTP settings and sender information
- Check base URLs, callback URLs, and API endpoints
- Review Java version compatibility
- Verify Tomcat context and JNDI settings
- Restart the Java service
- Test logs, database access, forms, uploads, and email
Common error messages after a move and what they usually mean
Database connection refused
The host, port, username, password, or firewall-related access settings are wrong, or the database service is not reachable from the new environment.
File not found or permission denied
The app is still using an old absolute path, or the target directory is not writable under the new hosting account.
Class not found
A required JAR file is missing, the driver version changed, or the app is loading libraries from an outdated path.
Malformed XML
An edited XML file contains a syntax error, often caused by missing brackets, quotes, or invalid characters.
Null pointer or configuration missing errors
The app expects a value that was not copied to the new host, or a property key changed during migration.
Best practices for future migrations
If you want future moves to be easier, design the application configuration with portability in mind:
- Keep environment values in one dedicated file
- Use system properties for host-specific settings when practical
- Avoid hardcoded absolute paths
- Separate code from writable data
- Document each config key and what it controls
- Keep a copy of the working production config outside the application package
- Test the application on the new host before switching traffic
This approach is especially helpful for JSP and Tomcat applications managed through a control panel, because it reduces downtime and makes redeployments more predictable.
FAQ
Should I edit config files before or after uploading the application?
Usually after uploading, but before putting the application into regular use. That lets you compare the deployed files with the old configuration and confirm which paths and values need to change.
Can I keep the same database settings after moving to a new host?
Only if the new environment uses the same database host, credentials, and network access. In most migrations, at least some database values need to be updated.
Do I need to change Tomcat files for every JSP migration?
No. Many apps only need changes in their own properties or XML config. Tomcat-level changes are needed when the app uses JNDI, custom context settings, JVM arguments, or service-specific options.
What is the safest way to update XML configuration files?
Use a plain text editor, keep a backup, change only one setting at a time, and validate the XML after each edit. A single syntax error can stop the app from starting.
Where should writable files be stored on a hosted Java account?
Ideally in a dedicated writable directory outside the deployed application package, if the hosting setup recommends that approach. This helps preserve uploads and generated files when the app is redeployed.
What if the app works locally but not on the new host?
That usually means one or more environment values still point to the old setup. Check database URLs, file paths, SMTP settings, external API endpoints, and Java/Tomcat version compatibility.
Conclusion
Updating config files after moving a JSP app to a new host is mostly about replacing environment-specific values with settings that match the new hosting account. Start with the database, then check file paths, Tomcat settings, Java version, SMTP, and any external URLs. In a managed Java hosting setup with Plesk and My App Server, you can usually control many of these items from the hosting panel while keeping the application itself unchanged.
A careful migration process, backed up by structured testing and clear configuration files, will help your JSP application run cleanly on the new host with fewer errors and less downtime.