How to migrate a WordPress site to a new server

Moving a WordPress site can feel like carrying a full fish tank across the room: the site still needs to stay alive, but one wrong tilt can spill files, data, or visitors.

Short version: to migrate WordPress to a new server, you copy the site files, move the database, recreate the connection between them, point the domain to the new server, and check HTTPS before visitors arrive. The important parts are the wp-content folder, the MySQL or MariaDB database, and the wp-config.php file that tells WordPress how to talk to that database.

What are you actually moving when you migrate WordPress to a new server?

A WordPress site is not one single thing. It is more like a small shop.

The WordPress files are the shelves, signs, and front door. Your theme, plugins, uploaded images, and custom code usually live in wp-content. That folder is where much of the visible personality of the site sits.

The database is the stockroom. WordPress stores posts, pages, users, settings, menus, product data, and many plugin settings in MySQL or MariaDB. If you copy only the files, the new site may look empty. If you copy only the database, WordPress has no building to stand in.

Then there is wp-config.php. Think of it as the note taped under the counter that says where the stockroom is and which key opens it. If the database name, user, password, or host is wrong, you may see the exact error string Error establishing a database connection.

What should you prepare before moving WordPress?

Start with a backup you can actually restore, not just a file you hope is useful. A good migration begins with a copy of both the WordPress files and the database. If something goes sideways, that backup is your undo button. If you want the broader safety picture, read our guide on how to back up your server and restore it.

Next, check the target server. It needs enough storage for your files, enough memory for WordPress and its plugins, and the right runtime pieces: a web server, PHP, and MySQL or MariaDB. If your old site already felt slow, do not treat the migration like a magic cure. Moving a crowded closet into a smaller closet does not create space.

Before you touch DNS, lower the DNS time-to-live value if your current domain provider allows it. DNS is the internet’s address book. Lowering the time-to-live means the new address can spread faster when you finally point the domain at the new server.

Also write down what the current site depends on: PHP version, important plugins, email sending, cron jobs, redirects, and any custom rules. These are the small hooks people forget, and they are often why a migrated site “mostly works” but still has strange broken parts.

How do you move WordPress without breaking the site?

The safest pattern is copy first, switch later.

First, place the WordPress files on the new server. That includes WordPress core files, themes, plugins, and especially wp-content/uploads, where media files usually live. Missing uploads are the classic “the site loads, but every image is broken” migration problem.

Second, export the database from the old server and import it on the new one. This carries over posts, pages, settings, users, comments, products, and plugin data. After that, make sure wp-config.php points to the new database details.

Third, test the site before changing the public domain. This is like walking through the new shop before putting the sign outside. Open pages, submit forms, check the WordPress admin area, test search, inspect images, and confirm that important plugin screens still load.

Fourth, point the domain at the new server. Domain changes happen through DNS records, usually an A record for the main domain and sometimes www. If that part feels fuzzy, this guide explains how to point a domain at your server in plain English.

Finally, set up HTTPS on the new server. HTTPS is the lock icon in the browser. If the certificate is missing, wrong, or expired, visitors may see a security warning even though the site itself moved correctly. Here is the plain version of getting free HTTPS on your server.

FAQ

Will my WordPress site go offline during migration? It does not have to. If you copy and test first, downtime can be limited to the short period when DNS starts sending visitors to the new server.

**Why do I see Error establishing a database connection?** WordPress cannot reach the database. The usual causes are a wrong database name, username, password, host, or a database service that is not running.

Why are images missing after migration? The wp-content/uploads folder was probably not copied fully, or file paths were changed in a way WordPress does not expect.

Do I need to change WordPress URLs in the database? Sometimes. If the domain changes, WordPress may still contain old URLs in settings, posts, widgets, or plugin data.

Should I delete the old site immediately? No. Keep it for a short safety window, locked down if needed, until you are sure the new site is complete and stable.

The shortcut

Server Manager helps by keeping the migration understandable instead of turning it into a pile of half-remembered steps. The outcome you want is simple: the files are in the right place, the database connection is clear, the domain points where it should, and HTTPS does not surprise visitors with a warning.

It also helps months later. A WordPress move often fails slowly because nobody remembers which site uses which database, which domain points where, or why a certificate was set up a certain way. The real benefit is that the setup stays legible, so future fixes do not begin with archaeology.

That means fewer familiar migration traps: a wrong wp-config.php, a missing uploads folder, a domain still pointing to the old server, a wrong or expired certificate, or one WordPress project being confused with another.

How do you know the migration worked?

A clean WordPress migration feels boring in the best way. Visitors reach the same site at the same domain. The WordPress admin opens. Images load. Forms send. HTTPS shows a valid lock. Search engines and customers do not notice the move.

That is the win: your site changes homes, but your readers, customers, and editors do not have to think about the move at all.