Verify wp-config.php Database Credentials

This is the absolute first place to check after any migration or host change. Your new hosting environment will have different database credentials than your old one. You need to access your site's files via FTP/SFTP or your hosting's file manager and locate the wp-config.php file, typically in the root directory (e.g., /public_html/wp-config.php).

Inside, look for these lines and ensure the values match what your new host provides. You'll find these details in your hosting control panel (cPanel, Plesk, etc.) under the "MySQL Databases" or "Databases" section.

define('DB_NAME', 'your_database_name');
define('DB_USER', 'your_database_username');
define('DB_PASSWORD', 'your_database_password');
define('DB_HOST', 'localhost'); // Often changes!

✓ Time Estimate: 5-15 minutes. Safety Note: Make a backup of wp-config.php before editing.

Confirm DB_HOST Value and Database Server Accessibility

The DB_HOST setting in wp-config.php is crucial. While localhost is common, many hosts, especially managed WordPress providers or those with separate database servers, use a specific IP address or a hostname (e.g., mysql.yourdomain.com, 127.0.0.1:3306). Refer to your new host's documentation or support for the exact DB_HOST. An incorrect host will cause a connection timeout or refusal.

To test accessibility: if you have SSH access, try telnet [DB_HOST] 3306. If it connects, the port is open. If not, a firewall or incorrect host is likely. If you don't have SSH, try to access phpMyAdmin from your hosting control panel; if that fails to connect, the database server itself might be down or unreachable. This often points to a firewall blocking port 3306 or the MySQL service not running. Learn more about database credentials and configuration errors here.

✓ Time Estimate: 10-20 minutes. Safety Note: Ensure you're using the correct port if specified (e.g., DB_HOST could be 127.0.0.1:3307).

Check Database User Permissions

Even if the database name, user, and password are correct, the specified database user might not have the necessary permissions to access and manipulate the database. This is a common issue after a cPanel transfer where user permissions aren't fully migrated.

Log into your hosting control panel, go to the "MySQL Databases" section, and ensure that the DB_USER you're using is assigned to the DB_NAME with ALL PRIVILEGES. If not, add the user to the database and grant all permissions. Without these, WordPress cannot perform basic operations like reading posts or saving settings.

✓ Time Estimate: 5-10 minutes. Safety Note: Granting excessive permissions to a user not tied to your WordPress database can be a security risk, but for your specific WordPress database, all privileges are typically required.

Test for Database Corruption

While less common immediately after a migration unless the database dump or import was flawed, database corruption can also lead to connection errors or an inability to retrieve data. If the database server is accessible and credentials are correct, but the error persists, consider this.

You can enable WordPress's built-in database repair tool by adding this line to your wp-config.php (preferably above the /* That's all, stop editing! Happy publishing. */ line):

define('WP_ALLOW_REPAIR', true);

Then, navigate to http://yourdomain.com/wp-admin/maint/repair.php in your browser. After running the repair, remove the line from wp-config.php for security. For more severe corruption, refer to our guide on WordPress Database Corrupted or Crashed Fix.

✓ Time Estimate: 10-20 minutes. Safety Note: Always back up your database before attempting any repair operation.

Check Server Error Logs for Clues

Your web server (Apache, Nginx) and PHP installation generate logs that can provide crucial diagnostic information. These logs are often located in directories like /var/log/apache2/error.log, /var/log/nginx/error.log, or within your hosting control panel's "Logs" section.

Look for recent entries (timestamped around when your site went down) that mention database connection failures, PHP errors related to MySQLi or PDO, or permission denied messages. These often provide a more specific reason for the connection failure than the generic WordPress error. For instance, a message like "SQLSTATE[HY000] [2002] Connection refused" directly points to the database server not accepting connections from your web server.

✓ Time Estimate: 10-30 minutes. Safety Note: Log files can be large; focus on the most recent entries.

Review PHP Version and Extensions

Sometimes, a new host might use a different PHP version or lack essential PHP extensions required for MySQL connectivity. WordPress relies on extensions like mysqli or mysqlnd to talk to the database. If these are missing or disabled, the connection will fail.

Check your hosting control panel for a PHP Version Manager or Selector. Ensure you're running a PHP version compatible with your WordPress installation (usually PHP 7.4 or newer is recommended). Also, verify that the necessary MySQL extensions are enabled. If you can create a phpinfo.php file (<?php phpinfo(); ?>) and access it, search for mysqli or mysqlnd to confirm their presence.

✓ Time Estimate: 10-20 minutes. Safety Note: Always test PHP version changes on a staging site first if possible, as incompatible versions can cause other issues.