How to update config and database access after moving a Java project

When you move a Java project to a new hosting account or a new server, the application usually does not fail because of the code itself. More often, the issues come from outdated configuration values, wrong database credentials, missing environment variables, or Tomcat paths that still point to the old location. In a managed hosting environment with Plesk and a private JVM or Apache Tomcat instance, these details need to be checked carefully after the files are uploaded and the service is started.

This article explains how to update config and database access after moving a Java project, with a practical focus on Java hosting, Tomcat hosting, JSP/Servlet applications, and Plesk-based deployment through My App Server. The steps below help you restore application access quickly and avoid common migration errors such as connection failures, 404 responses, startup crashes, and authentication problems.

What usually changes after a Java project move

After a migration, the application may still contain settings that were valid on the old host but no longer match the new environment. The most common changes are:

Database hostname, port, database name, username, and password
JDBC connection string or datasource URL
Tomcat context path or deployment location
Filesystem paths for logs, uploads, cache, or temporary files
Environment variables such as JAVA_HOME, DB_HOST, or APP_ENV
Mail server settings if the app sends notifications
External API keys or callback URLs
File permissions for the web app, logs, and writable folders

In a Plesk control panel setup with My App Server, these values are often spread across the application config, Tomcat configuration, and sometimes environment-specific property files. A clean migration means checking each layer, not only copying the WAR or source files.

Identify where your Java application stores configuration

Before changing anything, find the files and settings your project uses for database and environment configuration. Java applications commonly store them in one of these places:

application.properties or application.yml for Spring-based projects
db.properties, config.properties, or custom property files
XML files such as context.xml, server.xml, or framework-specific config
Environment variables loaded by the app at runtime
WAR package resources under WEB-INF/classes
Tomcat JNDI datasource definitions

If you are using a shared hosting account with a private JVM or Tomcat instance, it is important to confirm whether the application reads settings from the deployed archive or from an external config file on the server. External config is often safer during future updates, because it is less likely to be overwritten when you redeploy the application.

Check the old environment first

If possible, review the original project or the previous server before updating the new host. Look for:

Database connection strings
Hardcoded hostnames or IP addresses
Absolute file paths like /var/www/... or C:\...
Old domain names used in redirects, OAuth callbacks, or email links
Java version dependencies and Tomcat-specific settings

This step helps you build a migration checklist and reduces trial-and-error after deployment.

Update database access details

Database connectivity is the most common reason a migrated Java app does not work. Even if the database itself was moved correctly, the application may still be pointing to the old server or wrong credentials.

1. Confirm the database exists on the new hosting account

In Plesk, verify that the database has been created and that the correct database user exists. Check:

Database name
Database user name
Assigned privileges
Database server host, if different from localhost

If you imported a SQL dump, make sure the import completed successfully and the tables are present. Also confirm the character set and collation if the application depends on a specific encoding, especially for non-English content.

2. Update the JDBC URL

The JDBC URL often needs to be changed after a move. Typical examples include:

jdbc:mysql://old-host:3306/old_db
jdbc:mariadb://localhost:3306/new_db
jdbc:postgresql://db.example.com:5432/appdb

Update the host name, port, and database name to match the new environment. If your hosting platform uses a local database service, the host is often localhost. In some managed hosting setups, the database host may be a separate internal name provided in the control panel.

3. Replace username and password

New hosting accounts usually require new credentials. Even if the database name stays the same, the username and password often change during migration. Update all relevant fields in the app config and, if applicable, in Tomcat datasource settings.

Also check for these issues:

Passwords with special characters not escaped correctly in property files
Old credentials cached in environment variables
Separate credentials for read/write or reporting services

4. Verify driver compatibility

Make sure your Java application uses the correct JDBC driver for the database type and Java version. A project that worked on an older host may fail after migration if the driver jar is missing or incompatible.

For Tomcat-based deployments, the driver can be placed in the web application, in Tomcat’s lib directory, or managed through the deployment package depending on your application structure. If you are using My App Server, confirm that the selected Java version and Tomcat version match your application’s requirements.

5. Test database access after the change

After updating the settings, restart the application service and check the logs. Common database-related errors include:

Communications link failure
Access denied for user
Unknown database
Connection refused
JDBC driver not found

If the app starts but pages that depend on the database still fail, the connection pool or datasource configuration may also need to be updated.

Update configuration files after the move

Many Java applications use multiple config layers. After migration, review each file that contains host-specific values.

Application properties

For Spring Boot or similar frameworks, update files such as:

application.properties
application.yml
application-prod.properties
application-local.yml

Typical values to change include:

Database URL, user, and password
Server port if it conflicts with another service
Base URL or public domain name
Upload directory and log directory
SMTP host and sender address

Tomcat configuration

If your Java app runs on Apache Tomcat, check whether the application uses Tomcat-specific config files such as:

context.xml
web.xml
server.xml
JNDI resource definitions

For hosted Tomcat environments, some service settings are controlled through the hosting panel or My App Server interface rather than edited directly in system files. That makes it easier to manage the service, but you still need to confirm that the app points to the right datasource and runtime paths.

Environment variables

If the app reads values from environment variables, set them again in the new hosting environment. Common examples are:

JAVA_HOME
SPRING_PROFILES_ACTIVE
DB_HOST
DB_NAME
DB_USER
DB_PASSWORD

In a Plesk-based Java hosting setup, environment values may be handled through the extension, app service settings, or deployment scripts. Make sure you know where the application actually reads them from.

Check file paths and permissions

After moving a Java project, path-related problems are common because the new hosting account may use a different filesystem layout than the previous provider. Update any absolute paths in your config.

Typical path changes

Upload directories
Temporary directories
Log file locations
Export or import folders
SSL certificate file references, if the app uses them directly

If your application writes files during runtime, the target folder must be writable by the account or service user. This is especially important for JSP, servlet, and file upload applications. If the path is wrong or not writable, you may see errors such as Permission denied or silent failures when uploading files.

Prefer relative or externalized paths when possible

To make future migrations easier, use relative paths or configurable directories outside the compiled application package. This reduces the need to repack and redeploy the whole application whenever a hosting path changes.

Update domain names and callback URLs

Many Java applications include domain-specific settings in the config, such as:

Site URL
Login redirect URL
Payment gateway callback URL
OAuth or SSO redirect URI
API webhook endpoint
Email links used for password reset

After migration, check that these values match the new live domain or subdomain. If the application still points to the old address, users may be redirected incorrectly or integrations may fail.

In hosted Java environments, this step is often overlooked when the app itself works but external services still call the old endpoints.

Update Tomcat and Java service settings in My App Server

If you are using My App Server with Plesk, the application may run under a dedicated Tomcat service or private JVM. After moving the project, review the service settings to make sure the runtime matches the application.

What to confirm in the service configuration

Selected Java version
Tomcat version or custom app server version
Startup parameters and memory settings
Deployment directory or context path
Service status after restart

If the project was built for an older Java release, choose a compatible runtime. If it depends on newer language features or library versions, confirm that the selected JVM supports them. A mismatch here can cause startup errors even if the database settings are correct.

Restart the service after config changes

After updating config files, database credentials, or environment variables, restart the Java service from the control panel. This ensures the new values are loaded. If your hosting setup uses a managed service model, service control is typically done through the panel rather than by direct system commands.

After restart, inspect the application logs for:

Startup exceptions
Datasource initialisation errors
Missing file or directory warnings
Port conflicts
Class loading problems

Practical migration checklist

Use the checklist below to update config and database access after moving a Java project:

Confirm the application files or WAR were uploaded correctly.
Restore the database and verify tables and content.
Create or update the database user and privileges.
Change the JDBC URL to the new database host and name.
Update the database username and password.
Check Tomcat datasource or JNDI settings if used.
Update domain names, callback URLs, and API endpoints.
Adjust file paths for uploads, logs, and temporary files.
Verify environment variables and runtime profiles.
Check Java and Tomcat version compatibility.
Restart the service from Plesk or My App Server.
Review logs and fix any remaining path or permission issues.

Common problems and how to fix them

The app starts, but cannot connect to the database

This usually means the connection string, credentials, or database privileges are incorrect. Recheck the JDBC URL, username, password, and host. Make sure the database user has permission to the correct database.

The app crashes on startup after migration

Possible causes include a missing config file, a bad environment variable, an incompatible Java version, or a datasource defined with the wrong name. Check the logs first, then verify each changed setting one by one.

Static pages load, but admin features fail

Admin functions often depend on the database, email server, or writable folders. If only part of the app works, the problem is usually in a config section that is only used for backend actions.

Uploads or generated files are not saved

This is usually a permissions or path issue. Confirm that the upload directory exists and is writable by the application service user. Avoid hardcoded paths from the old server.

Links and redirects still point to the old domain

Search the project config, database values, and template files for the old domain name. Some applications store absolute URLs in the database, not only in property files.

When to use external config files

For long-term maintainability, many Java projects work better when sensitive settings are stored outside the application package. This approach helps when you move between hosts or redeploy WAR files frequently.

External config is useful for:

Database credentials
Secret keys and API tokens
Environment-specific URLs
Log and upload paths
Deployment profiles such as test, staging, and production

If your hosting plan supports My App Server and a private JVM, this pattern can simplify future changes because you do not need to rebuild the whole application for every config update.

FAQ

Do I need to change anything in the Java code after moving the project?

Usually no, if the application was already designed with external configuration. In most cases you only need to update database settings, file paths, domain-specific values, and runtime configuration. Code changes are only needed if the app has hardcoded old paths or hostnames.

Where should I update the database credentials?

Update them wherever the application reads database settings from: property files, YAML files, Tomcat datasource definitions, environment variables, or external config files. If more than one source exists, make sure they do not conflict.

Why does the app work on the old server but not after migration?

The most common reasons are wrong database access details, missing permissions, incompatible Java/Tomcat versions, or old absolute paths. A migrated app often depends on values that were never included in the code repository.

Can I keep the same database name after moving?

Yes, if you create the same database name on the new hosting account and import the data correctly. However, the username, password, and database host may still need to change.

How do I know if Tomcat settings also need to be updated?

If your project uses JNDI, context resources, custom ports, or Tomcat-specific deployment settings, then yes. Check the logs and the application’s config files for references to Tomcat resources or service parameters.

What should I check first if the app shows a blank page?

Check the logs, then verify database connectivity and file permissions. A blank page often means the app is failing behind the scenes, especially in JSP or servlet projects where server-side errors are hidden from the browser.

Conclusion

Updating config and database access after moving a Java project is mostly a matter of replacing old environment values with the new ones and then verifying that the application service loads them correctly. In a managed hosting setup with Plesk, My App Server, Apache Tomcat, and a private JVM, the process is straightforward when you follow a clear checklist: update the database connection, review application properties, fix paths and permissions, confirm Java/Tomcat compatibility, and restart the service.

For Java hosting, Tomcat hosting, and JSP/Servlet applications, careful config review is often the difference between a smooth migration and hours of troubleshooting. If you standardise your settings and keep environment-specific values outside the application package, future moves become much easier.

How to update config and database access after moving a Java project