Table of Contents

After you have copied a WordPress site’s files and imported its database to a new host, one small file stands between two lifeless copies and a working site: wp-config.php. It is the file that tells WordPress how to find and connect to its database, and editing it correctly with the new host’s database details is the reconnection that brings your migrated site to life. Get it right and the site loads; get it wrong and you meet the infamous ‘Error establishing a database connection.’ This guide makes that edit foolproof.

You will learn what wp-config.php does, the exact values you need to change after a migration, how to find and edit the file, the database-connection error and how to fix it, other settings in the file worth knowing, and how to keep the file secure. By the end you will be able to reconnect any migrated WordPress site to its database confidently, and diagnose the one error this step commonly produces.

Animated illustration of website files on a server going live to a website in the cloud

Did you know?

wp-config.php is the bridge between your WordPress files and your database. After a migration, updating its four database values — name, user, password, host — is what turns two copied halves into a living site. A wrong value is the #1 cause of the ‘database connection error.’

What wp-config.php does

wp-config.php is one of the most important files in a WordPress installation: it holds the core configuration WordPress needs to run, and above all, it tells WordPress how to connect to its database. When WordPress loads, it reads wp-config.php to learn the database’s name, the username and password to access it, and the database server’s address — and uses those to connect and pull your content and settings.

This is why the file is the linchpin of a migration’s reconnection step. Your migrated site is two separate halves — the files (including wp-config.php) on the new host, and the imported database on the new host — and they are not connected until wp-config.php points WordPress at the new database. The file is the bridge; without the correct details in it, WordPress on the new host has no way to find its data.

So understanding wp-config.php as ‘the file that tells WordPress where its database is’ explains exactly why editing it is the pivotal migration step. The files can be perfectly copied and the database perfectly imported, but the site will not work until wp-config.php is updated to reconnect them on the new host. That single edit is what assembles your two copied components into a living website.

The values you need to change

After a migration, the values in wp-config.php you need to update are the database connection details, so they match the new database you created on the new host. There are four, and they must correspond exactly to the new host’s database:

  • DB_NAME: the name of the database — set it to the new empty database you created and imported into on the new host.
  • DB_USER: the database username — set it to the user you created for the new database.
  • DB_PASSWORD: that user’s password — set it to match exactly.
  • DB_HOST: the database server address — usually ‘localhost’, but some hosts use a specific hostname, so check the new host’s database details.

These four values are the entire reconnection. They must match the database name, user, password, and host of the new database precisely — a single wrong character in any of them stops WordPress connecting. The first three (name, user, password) are whatever you set when you created the database on the new host, and the fourth (DB_HOST) is ‘localhost’ for most hosts but occasionally a specific server address the host documents. Update all four to the new host’s values, and WordPress can find its data.

Finding and editing the file

wp-config.php lives in the root directory of your WordPress installation on the new host — the same web-root folder (public_html or similar) that contains the wp-content folder and the other WordPress files. You edit it directly on the new host, using either the host’s file manager (which usually has a built-in text editor) or by downloading it via FTP, editing it locally, and re-uploading it.

When you open it, you will find the four database lines near the top, each defined with a line like define(‘DB_NAME’, ‘something’);. You replace the value inside the second set of quotes on each line with your new host’s corresponding value — the new database name, user, password, and host. Take care to change only the value inside the quotes, leaving the rest of each line and the quotes themselves intact, since a stray edit to the syntax can break the file.

So editing is: open wp-config.php in the new host’s web root, find the four DB_ lines near the top, and carefully replace each value with the new database’s details. Save the file (in place via the file manager, or re-upload it via FTP). It is a small, precise edit — the whole task is changing four values accurately. Once saved, WordPress on the new host is pointed at the new database, and the site should be reconnected.

The database-connection error and its fix

The one error this step commonly produces is ‘Error establishing a database connection’ — a full-page message WordPress shows when it cannot connect to the database. If you see this after editing wp-config.php, do not panic: it almost always means one of your four database values is wrong, and it is usually a quick fix.

Work through the four values against the new host’s database details: is DB_NAME exactly the new database’s name? Is DB_USER exactly the user you created? Is DB_PASSWORD exactly right (passwords are the most common culprit — a mistyped or mis-copied character)? Is DB_HOST correct (localhost for most, but a specific address for some hosts)? A single wrong character in any of these produces the error, so check each carefully, ideally by copying the values directly from the new host’s database settings rather than typing them.

Less commonly, the error can mean the database user lacks privileges on the database (grant it full privileges), or the database import did not actually complete (re-check the import). But the overwhelmingly likely cause after a migration is a wp-config.php credential mismatch, so start there. The reassuring point is that this error is not a sign of a failed migration — it is simply the reconnection not quite matching, and correcting the four values almost always resolves it and brings the site up.

Other settings worth knowing

While the four database values are the essential migration edit, wp-config.php holds other settings worth being aware of, some of which occasionally matter during a migration. The table prefix ($table_prefix) tells WordPress the prefix of its database tables (commonly wp_); if your imported database uses a different prefix, this must match it, or WordPress will not find its tables even with correct credentials — a subtle cause of problems if the prefix differs between old and new.

The file also contains the security keys and salts (the authentication unique keys), which secure user sessions; these can be carried over as-is, and if you ever want to force all users to log in again, changing them does that. And it can hold the site URL definitions (WP_HOME and WP_SITEURL) if they are hard-coded, which on a migration that changes the domain would need updating to the new URL, though these are more often set in the database.

So beyond the four database credentials, check the table prefix matches your imported database, be aware the keys and salts secure sessions, and note any hard-coded site URLs if your domain changed. For a standard host migration keeping the same domain, the four database values are usually the only edit needed. But knowing these other settings exist helps you troubleshoot the less common cases — particularly the table-prefix mismatch, which can mimic a connection problem even when the credentials are correct.

Keeping the file secure

Because wp-config.php contains your database credentials and security keys, it is a sensitive file, and a migration is a good moment to ensure it stays secure on the new host. The most basic protection is correct file permissions: wp-config.php should not be world-writable, and setting it to a restrictive permission (your host or WordPress documentation specifies the safe value) limits who can read or change it.

After editing the file during migration, make sure you have not left it exposed — for instance, avoid leaving a backup copy like wp-config.php.bak or wp-config.old in the web root, since such files can sometimes be downloaded and would leak your credentials. If you edited via FTP, delete any local copies containing the credentials once you are done, and never share the file or paste its contents anywhere.

So treat wp-config.php as the sensitive credential file it is: set restrictive permissions on the new host, do not leave exposed backup copies of it in the web root, and handle the credentials it contains carefully. A migration involves opening and editing this file, so it is the natural time to confirm it is properly secured afterward. With the four database values correctly set and the file kept secure, wp-config.php has done its job — reconnecting your migrated WordPress site to its database and bringing it to life on the new host, safely.

FAQs

How do I edit wp-config.php after migrating WordPress?

Open wp-config.php in the new host’s web root (via the file manager or by downloading it over FTP), find the four database lines near the top, and replace their values with your new host’s database details: DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST. Change only the value inside the quotes on each line, save, and WordPress on the new host will connect to the imported database, bringing the site to life.

What is wp-config.php?

It’s the core WordPress configuration file that, above all, tells WordPress how to connect to its database — the database name, username, password, and server address. When WordPress loads, it reads wp-config.php to connect and pull your content. In a migration it’s the bridge between your copied files and imported database; updating it is what reconnects the two on the new host.

What values do I change in wp-config.php after a migration?

The four database connection values, to match the new database you created: DB_NAME (the new database’s name), DB_USER (its user), DB_PASSWORD (that user’s password), and DB_HOST (usually ‘localhost’, but some hosts use a specific address). All four must match the new host’s database exactly — a single wrong character stops WordPress connecting.

Why do I get ‘Error establishing a database connection’ after migrating?

Almost always a wrong value in wp-config.php — check DB_NAME, DB_USER, DB_PASSWORD (the most common culprit, from a mistyped character), and DB_HOST against the new host’s database details, ideally copying them directly rather than typing. Less commonly, the database user lacks privileges or the import didn’t complete. It’s not a failed migration — just a reconnection mismatch, usually a quick fix.

What is the table prefix in wp-config.php?

$table_prefix tells WordPress the prefix of its database tables (commonly wp_). It must match the prefix in your imported database — if the old and new differ, WordPress won’t find its tables even with correct credentials, which can mimic a connection problem. So if you’ve double-checked the four database values and still have issues, verify the table prefix matches your imported database.

Is wp-config.php sensitive — should I secure it?

Yes — it contains your database credentials and security keys, so keep it secure on the new host. Set restrictive file permissions (not world-writable), don’t leave exposed backup copies like wp-config.php.bak in the web root (they can be downloaded and leak credentials), and delete any local copies with the credentials after editing. A migration is the natural time to confirm it’s properly secured.

The bottom line

wp-config.php is the small file that decides whether a migrated WordPress site lives or shows an error, because it is the bridge that tells WordPress how to find its database. After you have copied the files and imported the database to a new host, the two halves sit there unconnected until you edit wp-config.php with the new host’s database details — and that reconnection is the pivotal migration step. The essential edit is four values that must match the new database exactly: DB_NAME, DB_USER, DB_PASSWORD, and DB_HOST (usually ‘localhost’). You make it by opening the file in the new host’s web root, finding the four DB_ lines near the top, and carefully replacing only the value inside the quotes on each line, then saving. A single wrong character in any of them produces the famous ‘Error establishing a database connection.’

That error is the one thing this step commonly produces, and it is reassuringly simple to fix: it almost always means one of the four values is wrong — most often the password, from a mistyped character — so check each against the new host’s settings, ideally by copying rather than typing, and it comes right. Less common causes are the database user lacking privileges, an incomplete import, or a table-prefix ($table_prefix) mismatch that can mimic a connection problem even with correct credentials, so keep those in mind if the four values check out. Finally, because the file holds your credentials and security keys, treat it as sensitive: set restrictive permissions and leave no exposed backup copies in the web root. Get the four values right and keep the file secure, and wp-config.php does its job — reconnecting your migrated site to its data and bringing it to life on the new host.

When you are ready, you can start with Hostinger and use code PROTIPS for the reader discount. After migrating WordPress, edit wp-config.php in the new host’s web root: update the four database values (DB_NAME, DB_USER, DB_PASSWORD, DB_HOST — usually ‘localhost’) to match the new database exactly, changing only the value inside the quotes. This reconnects the files to the database. A wrong value causes ‘Error establishing a database connection’ — recheck the four (password is the usual culprit) and the table prefix. Keep the file secure with restrictive permissions.

Scroll to Top