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

After moving a Java project to a new hosting account, the application will usually start only when its configuration still points to the correct database host, database name, username, password, and connection settings. In a managed hosting environment with Plesk and My App Server, the application files may move cleanly, but the database access details often need to be updated manually before the app can connect again.

This guide explains how to update config and database access after moving a Java project, with a focus on Tomcat, WAR-based deployments, JSP/servlet applications, and private JVM setups commonly used in Java hosting. It also covers where to check settings in Plesk, how to test database connectivity, and what to verify if the application still returns connection errors after the migration.

What usually changes after a Java project move

When a Java application is moved to a new hosting platform or a different hosting account, the source code is normally not the only thing that matters. The application may also depend on:

  • database connection details stored in a properties file, XML config, or environment variables
  • Tomcat context settings or JNDI resources
  • server paths that changed after the transfer
  • JDBC driver version or class name
  • filesystem permissions for uploaded config files, logs, or temporary folders

In a control panel environment such as Plesk with My App Server, the app can usually keep its structure, but it is common to adjust the database connection string and related config after the move. If the project was built for another provider, it may still contain the old hostname, an old database user, or a hardcoded local address such as localhost that no longer works in the new account.

Where database settings are commonly stored

Before editing anything, identify where the application reads its database settings. In Java projects, the most common places are:

application.properties or application.yml

Many Spring Boot and modern Java applications store database connection values in application.properties or application.yml. Typical values include:

  • spring.datasource.url
  • spring.datasource.username
  • spring.datasource.password
  • spring.datasource.driver-class-name

context.xml or server.xml

Tomcat applications often define database resources in context.xml, server.xml, or a context file under the application deployment. These settings may use JNDI and look like a named resource instead of a direct JDBC URL.

config.properties, db.properties, or similar files

Older or custom Java applications frequently keep database settings in a separate properties file. The file name varies, but the purpose is the same: store the database host, name, credentials, and sometimes the pool settings.

Environment variables

Some applications read database values from environment variables. This approach is common when the application was designed to be moved between environments without changing source code.

Startup scripts or deployment scripts

If the app is started with a custom script, the connection settings may be passed as arguments or loaded from a file outside the WAR archive.

Step 1: Identify the new database details in Plesk

In the new hosting account, open Plesk and create or check the database that the Java project will use. Make sure you have the following information available:

  • database name
  • database username
  • database password
  • database host or server name
  • port number, if the application needs a non-default port
  • database type, such as MySQL or MariaDB, if the application expects a specific driver

In many hosting setups, the database host is not always the same as the web host. If the application was moved from another provider, do not assume the old database server name still applies. Use the exact values shown in the hosting panel.

If the project uses a shared hosting database, confirm that the user has the correct permissions for the required schema. The database user must be allowed to read and write the tables used by the application.

Step 2: Update the JDBC connection string

The JDBC connection string is the most important part of the configuration. If it still points to the old provider, the app cannot connect.

Example MySQL or MariaDB JDBC URL:

jdbc:mysql://dbhost.example:3306/database_name

Common edits after migration include:

  • replacing the old database host with the new one
  • changing the database name to the newly created schema
  • updating the port if the hosting environment uses a different one
  • adding or removing parameters such as useSSL, serverTimezone, or characterEncoding

Example in a properties file:

spring.datasource.url=jdbc:mysql://dbhost.example:3306/appdb?useUnicode=true&characterEncoding=UTF-8&serverTimezone=Europe/London

For UK-facing applications, timezone settings matter if the app stores or displays timestamps. If your business logic depends on local time, verify that the database and JVM timezone are aligned with the expected application behaviour.

Step 3: Replace the database username and password

After migration, the old database user usually does not exist in the new account. Create a new user in Plesk, assign it to the database, and set the application config to use the new credentials.

Check the following carefully:

  • the username in the config exactly matches the Plesk database user
  • the password has been copied without extra spaces
  • special characters in the password are escaped correctly if needed
  • the user has sufficient privileges for the application tables

If the config uses encrypted secrets or externalized settings, update the value in the appropriate place rather than changing the source code. This reduces the chance of deployment errors and makes future migrations easier.

Step 4: Verify Tomcat or My App Server deployment settings

When Java applications run under My App Server or a Tomcat-based setup, the database settings may be linked to the application context rather than stored in the WAR file. In that case, review:

  • Tomcat context configuration
  • JNDI resource definitions
  • environment variables used by the service
  • startup options configured in Plesk

If you use a JNDI datasource, the app may refer to a resource name such as java:comp/env/jdbc/MyAppDB. After moving the project, confirm that the resource still points to the correct database and that the service definition matches the current account.

In a managed hosting environment, service control is often done from the panel rather than directly from the operating system. That makes it easier to restart the private JVM or Tomcat instance after you change config files.

Step 5: Check the JDBC driver and Java version

Database errors after a move are not always caused by wrong credentials. Sometimes the project uses a JDBC driver that is incompatible with the Java version or database server version now running in the new hosting environment.

Verify the following:

  • the JDBC driver JAR is included in the correct lib folder
  • the driver class name matches the database driver in use
  • the Java version selected in My App Server is supported by the application
  • the application was not relying on an older driver removed during deployment

For example, a MySQL application might need com.mysql.cj.jdbc.Driver instead of an older class name used in legacy projects. If the app was moved from an older Java environment, a small compatibility update may be necessary.

Step 6: Update file paths and upload locations

Database access is often only one part of the migration. Java projects also use filesystem paths for:

  • log files
  • temporary upload files
  • export folders
  • reports or generated documents
  • external config files

After moving to a new hosting account, any hardcoded path from the old server may no longer exist. Review the application config for absolute paths such as:

  • /var/www/...
  • C:\...
  • old deployment folders tied to the previous provider

Use the folder structure provided by the current hosting account and confirm that the Java process can read and write where needed. If the application needs a writable directory, make sure permissions are correct in Plesk and that the app user can access it.

Step 7: Import the database and confirm the schema

If the project uses a database dump from the old hosting provider, import it before testing the application. Then confirm that the schema is complete and matches the app version.

Check for:

  • missing tables
  • truncated imports
  • incorrect character set or collation
  • test data left in place after migration
  • version mismatch between application code and database structure

If the database import used a different collation or encoding, you may see strange characters in the UI or failed queries when the application reads text fields. For UK applications, UTF-8 is usually the safest option for multilingual content and external data imports.

Step 8: Test connectivity before going live

Before switching traffic to the migrated Java project, test the database connection in a controlled way. A practical checklist is:

  • open the application logs and look for connection errors
  • restart the Tomcat service or private JVM after config changes
  • test a login page, admin area, or any feature that writes to the database
  • confirm read and write operations both work
  • verify that no fallback to an old database is happening

If the app shows a generic error page, check the logs first. Common messages include:

  • authentication failed for user
  • unknown database
  • communications link failure
  • JDBC driver not found
  • timeout waiting for connection

These messages usually point directly to the setting that needs to be fixed.

Example: Updating a properties file after migration

A simple configuration file might look like this before the move:

db.url=jdbc:mysql://oldhost.example:3306/oldappdb
db.username=olduser
db.password=oldpassword

After migration, update it to the new account values:

db.url=jdbc:mysql://newdbhost.example:3306/newappdb
db.username=newuser
db.password=strong-new-password

If the application also stores pool settings, review those too:

  • minimum and maximum connection pool size
  • connection timeout
  • validation query
  • idle connection timeout

In shared hosting Java setups, keep pool settings realistic. A small or medium application usually does not need aggressive pooling values, especially when the service runs inside one private JVM.

Example: Updating Tomcat JNDI database settings

If the app uses a JNDI datasource in Tomcat, the resource definition may need to be changed after the move. The important parts are the name, URL, username, and password. Make sure the application context points to the same resource name after the migration.

Typical checks include:

  • the datasource name matches the application reference
  • the URL uses the correct host and database name
  • the driver class is available to the Tomcat instance
  • the service was restarted after the change

With My App Server, this is usually managed through the hosting control panel and the service control options rather than by editing the server directly. That makes it easier to keep the deployment consistent, especially for smaller Java hosting projects.

Common problems after updating config and database access

The application still tries to use the old database

This usually means there is another config file, environment variable, or cached setting still pointing to the old values. Search the project for the old host name, old database name, or old user name.

The database user exists but login still fails

Check whether the password is correct and whether the user has access to the schema. In some panels, a user can exist without being assigned to the database properly.

The app connects locally but not through the panel service

Confirm that the connection is made from the correct JVM or Tomcat instance. In a managed environment, the service may have its own config scope.

Character encoding looks broken

Review the database collation, JDBC parameters, and application encoding settings. UTF-8 should be used consistently across the app, database, and output layer.

Connection pool errors appear after restart

Reduce the pool size or check whether the database allows enough simultaneous connections for the application. Also verify that the driver and JDBC URL are valid.

Best practice checklist for moved Java projects

  • create or confirm the new database in Plesk
  • create a dedicated database user
  • import the schema and data
  • update JDBC URL, username, password, and driver class
  • check JNDI settings if Tomcat is used
  • verify file paths and writable directories
  • restart My App Server or Tomcat after the change
  • test login, forms, and database writes
  • review logs for connection or permission errors

When to edit config files and when to use the control panel

Some settings are best changed directly in the application config, while others are better handled in the hosting control panel. A useful rule is:

  • edit the app config for database URL, username, password, and app-specific properties
  • use Plesk for database creation, permissions, and service control
  • use My App Server controls for Java version, service restart, and deployment-related service options

This separation keeps the migration cleaner and helps avoid accidental changes to files that should remain stable between deployments.

FAQ

Why does my Java app still fail after changing the database password?

Often the password was updated in one place but not everywhere. Check for duplicate config files, cached values, environment variables, and JNDI settings. Also restart the Tomcat or private JVM service after the update.

Do I need to change the JDBC driver after moving the project?

Not always, but you should verify that the driver matches the database version and Java version in the new hosting account. A migration is a good time to replace an old driver with a current compatible one.

Can I keep the same database name after the move?

Yes, if the new hosting account allows it and the name is available. Even if the database name stays the same, the host, username, and password often change and must be updated in the app config.

Where should I look if the app uses Tomcat JNDI?

Check the Tomcat context configuration, the application resource reference, and the My App Server or Plesk service settings. The datasource name must match exactly on both sides.

What if the app was built for another provider and has hardcoded paths?

Replace old filesystem paths with paths that exist in the current hosting account. Also verify permissions for any folders used for logs, uploads, or temporary files.

Conclusion

After moving a Java project, updating config and database access is usually the step that decides whether the application starts successfully. In a hosting environment with Plesk and My App Server, the process is straightforward when you identify where the app stores its database settings, create the new database and user, update the JDBC details, and restart the service before testing.

For Tomcat hosting, JSP hosting, servlet hosting, and private JVM deployments, the key is to keep the database config, file paths, and service settings aligned with the new account. Once those values are correct, most migrated Java applications will connect normally and continue working with minimal downtime.

  • 0 Users Found This Useful
Was this answer helpful?