How to migrate a website to new hosting

A website migration goes wrong in one of two ways. Either something is missed — a database, a mailbox, a cron job — or the steps are done in the wrong order and the domain starts pointing at a server that is not ready yet.

The order is the whole trick, and it is always the same:

Before you start: what you are actually moving

Write this list down for your own site. Almost every "we forgot something" story is an item that was never on a list.

• Website files — everything in the web root, including hidden files like .htaccess.
• The database — nearly every CMS has one.
• Email — mailboxes, forwarders, autoresponders, and the mail itself.
• DNS records — not just the website. Verification TXT records, mail records, subdomains pointing elsewhere.
• Cron jobs — scheduled tasks do not travel with files.
• SSL — you will need a certificate on the new host. Free certificates are issued automatically on most platforms once DNS points at them.
• Anything custom — redirect rules, IP allowlists, PHP settings that differ from default.

Step 1 — Back up the old site

Before touching anything, take a copy you could rebuild from. Download the files over FTP or as an archive, and export the database. Keep it somewhere off both servers until the migration is finished and verified.

This backup is not the migration copy. It is the thing you fall back to if the migration copy turns out to be incomplete.

Step 2 — Prepare the new account

Set the destination up before you send anything to it:

• Add the domain to the new hosting account.
• Create an empty database, plus a user with access to it. Note the name, user and password.
• Match the PHP version to whatever the old host was running. Migrating and upgrading PHP simultaneously means two possible causes for every problem.

Step 3 — Copy the files

Upload the site files into the web root of the new account. Two things people miss:

• Hidden files. .htaccess starts with a dot and most FTP clients hide it by default. Turn hidden files on before you transfer.
• The right folder. Files must land inside the web root, not in a subfolder of it. A site that shows a directory listing or a default page after migration is usually one folder too deep.

For a large site, transferring via the server rather than through your own connection is dramatically faster — see moving files directly between two hosts.

Step 4 — Import the database

Import your export into the empty database you created. For anything under about 50MB, phpMyAdmin handles it. Larger than that and the browser upload limit becomes the obstacle — the command line handles it without complaint:

mysql -u newuser -p newdatabase < backup.sql

Step 5 — Point the application at the new database

The new database has a different name, user and password, and the site does not know that yet. Update the configuration file:

Getting this wrong produces a database connection error, which is at least an unambiguous signal — see fixing a database connection error.

Step 6 — Test before you switch anything

This is the step that separates a calm migration from a frightening one. You can load the site from the new server while the whole world is still being served by the old one, by telling only your own computer where to look. Add a line to your hosts file mapping the domain to the new server's IP address, and your browser alone will use the new server.

Full instructions are in previewing a site with your hosts file. Once it is active, work through the site properly:

• The home page, and several inner pages.
• Any form that submits — contact, search, login.
• The admin area, logged in.
• Images and stylesheets loading, not just the HTML.
• For a shop: add to basket, and reach the checkout.

Step 7 — Switch DNS

Only now. A day ahead, drop the TTL on the relevant records to 300 seconds so the change takes minutes rather than hours. Then either change the nameservers to the new host's, or update the A record — see pointing a domain to your hosting for which is right for you.

Remove the hosts file entry you added in step 6 afterwards. Otherwise your machine keeps using it forever and you will be the only person on earth who cannot see a future DNS change.

Step 8 — Do not cancel the old hosting yet

Leave it running for at least a week. DNS reaches different networks at different times, and until it has reached all of them some visitors are still being served by the old server. Cancelling early turns those visitors' experience into an outage.

During that week, watch for the things that only show up in real use: forms that do not send, scheduled jobs that no longer run, and email arriving at the old server. When a week has passed with none of those, take a final backup of the old account and close it.