Why Is Your Website Showing Database Connection Errors After Migration?

Seeing a database connection error after migration usually means the website files moved successfully, but the application can no longer reach the database, authenticate with it, or talk to it using the expected host, port, or permissions. This is one of the most common post-migration issues in hosting environments, especially when moving WordPress, Joomla, Drupal, Magento, custom PHP apps, or any site that uses MySQL or MariaDB.

In a managed hosting or control panel environment such as Plesk, the problem is often caused by a mismatch between the old and new database settings, a restored database user with missing privileges, a changed database host, or a PHP version or extension mismatch. In EU hosting setups, this can also happen when the site is moved to a different infrastructure layer and the application still points to legacy connection details.

Why database connection errors happen after migration

During a website migration, there are two separate parts to move correctly: the website code and the database. If either part is incomplete or misconfigured, the application may not be able to load content and may display an error such as:

  • “Error establishing a database connection”
  • “Database connection failed”
  • “Access denied for user”
  • “Can’t connect to local MySQL server through socket”
  • “Unknown database”
  • “Connection timed out”

These messages usually point to one of five areas:

  • Incorrect database name, username, or password
  • Wrong database host or port
  • Missing database user permissions
  • Database not imported fully or imported into the wrong database
  • Application or server compatibility issue after the move

Most common causes after a move

1. The database credentials were not updated

When the site is moved to a new hosting account, the database name, username, or password often changes. Many applications store these values in a configuration file, and if the old values remain in place, the site cannot connect.

Common configuration files include:

  • WordPress: wp-config.php
  • Joomla: configuration.php
  • Drupal: settings.php
  • Magento: app/etc/env.php
  • Custom PHP apps: usually a config file in the app root or .env

2. The database user no longer has access

After migration, the database may exist, but the user account assigned to it may not have the correct privileges. This is common when importing databases manually or when creating a new database in Plesk or another control panel.

The database user should typically have the required permissions on that specific database, such as:

  • SELECT
  • INSERT
  • UPDATE
  • DELETE
  • CREATE
  • ALTER
  • INDEX
  • DROP

3. The database host changed

Some applications use localhost by default, but the destination hosting platform may require a different host value. In shared hosting or managed hosting environments, the database host can be a local socket, a server hostname, or an internal service address.

If the database host is wrong, the site may return a timeout or socket-related error even if the username and password are correct.

4. The database import was incomplete

If the database was exported from the old server and imported to the new one, a broken dump file, interrupted import, or charset issue can leave tables missing or data incomplete. The application may then fail during startup, especially if key tables such as settings, users, or content tables are unavailable.

5. PHP version or extension mismatch

After migration, the site may run on a different PHP version than before. Some older applications depend on specific PHP extensions or behave differently when the database driver changes. In hosting environments using Plesk, this is often related to MySQLi, PDO MySQL, or a PHP handler difference.

How to troubleshoot the error step by step

Step 1: Confirm that the database exists

Log in to your hosting control panel and check whether the database was created on the new account. In Plesk, this is usually found under the domain’s database section. Verify that the database name matches what the application expects.

If the database is missing, create it and import the backup again.

Step 2: Verify the database user and password

Open the application configuration file and compare the stored credentials with the database settings in your control panel. Make sure the database name, username, and password all match exactly.

Things to check carefully:

  • No extra spaces in the username or password
  • Correct prefix if the hosting panel adds one automatically
  • Updated password if the user was recreated during migration
  • Correct capitalization where applicable

Step 3: Check the database host value

Look for the database host setting in the config file. Typical values are localhost, 127.0.0.1, or a specific hostname provided by the hosting platform.

If the application was moved between environments, test the following:

  • localhost
  • 127.0.0.1
  • the database hostname shown in the hosting control panel

In some cases, localhost uses a Unix socket, while 127.0.0.1 uses TCP. If one fails, the other may work depending on the server configuration.

Step 4: Reassign database privileges

If the user exists but still cannot connect, reassign the user to the database and grant full permissions required by the application. In Plesk, this is usually done from the domain’s database management page.

After changing permissions, save the settings and test the site again.

Step 5: Confirm the import completed successfully

Open the database tool in your hosting panel or use a management interface to verify that the expected tables are present. For example, a WordPress database should include tables such as:

  • wp_options
  • wp_posts
  • wp_users
  • wp_usermeta

If the table list is incomplete, re-import the database from a fresh export file.

Step 6: Check for charset or collation issues

Some migration failures are not due to connectivity itself, but to incompatible database encoding. If the source site used a different charset or collation, the import may succeed but some queries may fail later.

Look for settings such as:

  • utf8mb4
  • utf8mb4_unicode_ci
  • latin1

For modern websites, utf8mb4 is usually preferred. Make sure the application and database use the same encoding where possible.

Step 7: Test the database service from the server side

If you have SSH access or server diagnostics in your hosting platform, test whether the database service is running and reachable. A connection error may be caused by a temporary service issue rather than a website config problem.

Useful checks include:

  • Is MySQL/MariaDB running?
  • Are there resource limits or overload alerts?
  • Is the server firewall blocking the connection?
  • Are there socket permission issues?

Step 8: Review PHP error logs and application logs

Logs often show the real reason behind the error. In many hosting panels, you can access:

  • Website error logs
  • PHP logs
  • Database server logs
  • Application-specific logs

Search for messages like:

  • Access denied
  • Unknown database
  • Too many connections
  • Can't connect
  • Table doesn't exist

How to fix the issue in common CMS platforms

WordPress

Open wp-config.php and confirm these values:

  • DB_NAME
  • DB_USER
  • DB_PASSWORD
  • DB_HOST

If the database was imported under a new name in the hosting panel, update the file with the new values. Also ensure that the database user has been assigned to that database with sufficient permissions.

Joomla

In configuration.php, verify the database settings such as host, user, password, and database name. Joomla is sensitive to host formatting, so test both localhost and the host provided by your platform if connection issues continue.

Drupal

Check sites/default/settings.php for the database connection array. Make sure the driver, hostname, database name, username, and password all match the new environment.

Magento

Review app/etc/env.php and confirm the resource configuration. Magento can also fail after migration if the database import is incomplete or if the PHP version is not compatible with the installed release.

What to check in Plesk or a similar control panel

If your hosting account uses Plesk, the following areas are usually the fastest way to find the issue:

  • Databases: confirm the database exists and contains tables
  • Database Users: confirm the user is assigned correctly
  • PHP Settings: confirm the selected PHP version and handler
  • Logs: review site and error logs for connection messages
  • File Manager: edit the application config file directly if needed

When moving a website to a new EU hosting environment, it is also important to confirm that the domain points to the correct subscription and that the database belongs to the same site account. A database restored under the wrong subscription can look valid but still fail when the application tries to connect.

How to prevent database connection errors during migration

  • Export the database from the old hosting account using a consistent method.
  • Import the database into the new account before switching DNS.
  • Update all connection details in the application configuration file.
  • Confirm that the database user has the correct privileges.
  • Test the site on a temporary URL or hosts file entry before going live.
  • Check PHP version compatibility before the move.
  • Keep a backup of both files and database before making changes.

A staged migration reduces downtime and makes it easier to isolate whether the issue is related to the database, the application, or the hosting configuration.

Example of a simple migration checklist

  1. Create a full backup of files and database on the old server.
  2. Set up the new hosting account and database.
  3. Import the database into the new environment.
  4. Upload website files to the new document root.
  5. Update config files with the new database name, user, password, and host.
  6. Assign the database user to the database with proper permissions.
  7. Test the site before changing DNS.
  8. Check logs after the switch to catch any hidden errors.

When the error is not actually the database

Sometimes the message looks like a database problem, but the root cause is elsewhere. For example:

  • The site is calling the wrong environment file after migration
  • The web root points to an old copy of the application
  • The database server is under heavy load
  • A firewall rule blocks remote database access
  • The application cache still contains old connection data

If the standard checks do not fix the issue, clear the application cache and review the domain configuration in the hosting panel.

FAQ

Why does my site work on the old host but not after migration?

The most common reason is that the application still uses the old database credentials or host. The database may also have been imported incorrectly, or the new server may require different permissions or PHP settings.

What is the first thing I should check?

Check the database name, username, password, and host in the application config file. Then confirm that the database user is attached to the correct database with proper permissions.

Can a wrong PHP version cause a database connection error?

Yes, especially with older CMS versions or custom applications that rely on specific PHP extensions or database drivers. A PHP mismatch can make the site appear to have a database problem even when the credentials are correct.

Why do I get a socket error on the new server?

This often means the application is trying to connect using localhost and a local socket, but the hosting environment expects TCP or a different host value. Try 127.0.0.1 or the host provided in the control panel.

Do I need to recreate the database user after migration?

Not always, but it is often the simplest fix. If permissions are unclear or the previous user was not imported cleanly, creating a new database user and assigning it to the database can resolve the problem quickly.

How can I tell if the database import failed?

Compare the table count and key tables against the old database. If important tables are missing or the import stopped early, re-export and re-import the database using a fresh backup file.

Conclusion

Database connection errors after migration are usually caused by a small mismatch between the application and the new hosting environment. In most cases, the fix is to verify the database credentials, confirm the database host, restore the correct permissions, and make sure the import completed successfully. If you are working in a control panel such as Plesk, the database management tools, logs, and PHP settings can help you identify the problem quickly.

For reliable post-migration troubleshooting, always check the database configuration file first, then the database user permissions, then the import status and server logs. This approach resolves most connection errors without needing to rebuild the entire site.

  • 0 Users Found This Useful
Was this answer helpful?