What the error means after a migration
WordPress.org's Common WordPress Errors page says the message is usually caused by an error in wp-config.php, and tells you to check the database name, database username, database password and database host in that file. It also lists two causes outside your control: a host shutting down a database that exceeded its quota, or the database server being down.
A migration makes the first cause likely. The files you copied still contain the old host's wp-config.php, while the new host created a database and user with its own names and password. Even when a migration tool rewrites the file, a manual import into a database you created yourself leaves the old values in place. On a course or membership site nothing works while this error is showing: logins, lessons, checkout and webhooks all fail, so fix it before you change DNS whenever you can.
Work through the causes in the order below. Each step is cheap to check, and the later steps (repair, restore) can make things worse if the real problem is a typo in a password.
Step 1: compare the four wp-config.php values with the new host
The WordPress wp-config.php reference defines each value: DB_NAME is the database name, DB_USER the username, DB_PASSWORD the password, and DB_HOST the database server. It says there is a good chance you will not need to change DB_HOST, but that hosts using an alternate port or a Unix socket need a different value, and that you should contact your host if installation fails.
Open the new host's database screen and the wp-config.php on the new server side by side. GoDaddy's help article on this error warns to replace only the text inside the apostrophes, so that nothing else in the file changes.
| Constant | Must match | Typical migration mistake |
|---|---|---|
| DB_NAME | The database you imported the dump into on the new host | Still the old host's database name, or the import went into a different database than the one named here |
| DB_USER | A user that exists on the new database server | Old host's username copied across; the new host never created it |
| DB_PASSWORD | That user's current password | Password reset on the new host after the file was copied, or special characters broken while pasting |
| DB_HOST | The server address the new host documents, including port or socket if required | Old host's remote database hostname left in place; port omitted for a managed database that does not use 3306 |
Step 2: confirm the database user has privileges on that database
Correct credentials are not enough if the user is not attached to the database. WordPress.org's Creating Database for WordPress page grants rights with GRANT ALL PRIVILEGES ON databasename.* TO the WordPress user. SiteGround's knowledge base article on this error says the user must have permission to run all types of MySQL operations on the database, and recommends selecting All Privileges.
In a control panel this usually means opening the database user list and checking that the user appears against the database WordPress is configured to use. If you created a fresh database for the import, add the user to it again; privileges granted on an earlier, empty database do not carry over to a new one.
Step 3: use the DB_HOST value your new host documents
DB_HOST is the value most likely to differ between hosts. The table below lists what each host's own documentation says. Where a page does not state a value, the table says so rather than guessing.
| Host | What its documentation says about the database host | Where to look |
|---|---|---|
| Kinsta | The database hostname is localhost for all WordPress sites; remote access uses a different hostname and its own tutorial | Kinsta knowledge base: MySQL hostname |
| SiteGround | Typically localhost (127.0.0.1 also works); use the remote server's hostname only for a remote database | Site Tools > Site > MySQL, per SiteGround's article on this error |
| WP Engine | The support article does not state DB_HOST; it says DB_NAME is wp_ followed by the environment name and DB_USER is the environment name | WP Engine support: fixing the database connection error |
| GoDaddy cPanel hosting | Always use localhost for cPanel; Plesk users get the host name from Plesk | GoDaddy help: fix error establishing a database connection |
| DigitalOcean managed MySQL | Use the hostname and port from the Connection Details on the cluster's Overview page (DigitalOcean's examples use 25060); clients default to 3306 if no port is given; the docs say to add the connecting machine to the cluster's trusted sources | DigitalOcean docs: connect to MySQL database clusters |
| Any host using a port or socket | WordPress accepts host:port, for example 127.0.0.1:3307, or host:/path/to/mysqld.sock | WordPress wp-config.php reference |
Step 4: repair tables only after the connection details are right
If WordPress connects but reports damaged or unavailable tables, the WordPress wp-config.php reference documents a built-in repair script: add define( 'WP_ALLOW_REPAIR', true ); and open /wp-admin/maint/repair.php on your site. It says the setting should only be enabled if needed and disabled once the issue is solved. WordPress.org's troubleshooting FAQ also gives phpMyAdmin steps: select the affected tables and choose Repair Table from the drop-down.
Take a database backup first. The Common WordPress Errors page says to always back up your database before performing any actions on it, and describes error 145 as a table that is damaged or corrupted. A repair on a table that was only half-imported will not bring back missing rows; in that case re-run the import from your export file.
If every value is right and it still fails
SiteGround's article lists further causes: wrong site URLs in the database (it calls this rare), WordPress core files damaged by malware, a failed update or an incomplete manual transfer, and a database server that is down or overloaded. Its last two steps are restoring a backup and contacting the host.
WP Engine's article puts restoring the last working backup first where that is viable, noting that it backs up sites nightly and that manual checkpoints can be created at any time. On a fresh migration, the cleaner option is usually to re-run the migration rather than restore over a half-configured site. If you see the error only after switching DNS, compare the new server with the old one directly; our guide to restore rehearsals covers how to prove a backup restores before you need it.
Database connection checklist after a host move
- Copy the database name, user, password and host from the new host's panel, not from the old wp-config.php.
- Edit only the text inside the quotes in wp-config.php and keep a copy of the original file.
- Confirm the user is assigned to that exact database with all privileges.
- Use the DB_HOST format the new host documents, including the port shown in a managed database's connection details.
- For an external database, confirm the web server is allowed to connect (trusted sources or firewall).
- Back up the database before any repair; turn WP_ALLOW_REPAIR off as soon as you finish.
- If the import may be incomplete, re-import rather than repair.
- Fix this on the new server before DNS cutover, while the old site still serves students.
Questions before you decide
Should DB_HOST be localhost after a migration?
Often, but not always. Kinsta documents localhost for all WordPress sites, SiteGround says typically localhost, and GoDaddy says always localhost on cPanel. A managed database such as DigitalOcean's needs the cluster hostname and the port from its connection details, 25060 in DigitalOcean's examples.
Can the WordPress repair page fix this error?
Only if the connection works and tables are damaged. WordPress documents WP_ALLOW_REPAIR and /wp-admin/maint/repair.php for that case and says to disable it once solved. Wrong credentials or a missing user will not be fixed by a repair.
What are the WP Engine database name and user?
WP Engine's support article says the database name is always wp_ followed by the environment name and the database username is the environment name. Updating those two values in wp-config.php is the fix it documents.
Why does the error appear only on the new host?
Because the copied wp-config.php still points at the old host's database name, user, password or host. WordPress.org says the error is usually caused by wp-config.php, so compare all four values with the new host's panel.
Sources & verification
Product details and prices can change. Check the linked provider before buying.
- WordPress.org: Common WordPress errors Accessed 30 Oct 2026
- WordPress.org: wp-config.php reference Accessed 30 Oct 2026
- WordPress.org: Creating database for WordPress Accessed 30 Oct 2026
- WordPress.org: FAQ troubleshooting Accessed 30 Oct 2026
- SiteGround: How to fix Error establishing a database connection in WordPress Accessed 30 Oct 2026
- Kinsta: What is MySQL hostname and how to find it Accessed 30 Oct 2026
- WP Engine: Fixing the Error establishing database connection error Accessed 30 Oct 2026
- GoDaddy: Fix Error establishing a database connection in WordPress Accessed 30 Oct 2026
- DigitalOcean: How to connect to MySQL database clusters Accessed 30 Oct 2026
Sources link directly to providers. Product buttons may use separately labeled affiliate links. Read our disclosure.