Website migration checklist: how to move a site to a new host or platform without losing traffic

Two kinds of migration

People say “migration” for two different jobs, and the risks differ.

• Moving host: the same site, same files, same addresses, on a different server. Lower risk. The main dangers are missing files, missing email settings and downtime during the domain switch.
• Moving platform: rebuilding the site on a different system, for example from a database-driven platform to a static site, or from a site builder to your own files. Higher risk, because addresses, templates and content structure often change.

Many migrations are both. Work out which you’re doing before you start, because platform moves need the redirect and content work described in our website redesign checklist as well as everything below.

Phase 1: Prepare

1. Write down why you’re moving and what must not change. Usually: addresses, content, email, forms.
2. Take a full copy of the old site: files, any database, uploaded images and documents. Store it somewhere other than the old host. See how to back up a website.
3. List every page. Use the sitemap, a crawler or your search tools. Note which pages get the most visits and which have links from other sites.
4. Record the domain settings. Log in to wherever the domain is registered and write down every DNS record: where the site points, email records, verification records for other services. Missing email records is one of the most common migration mistakes.
5. List everything else the site depends on: forms and where they send, scripts and embeds, analytics, redirects already in place, any scheduled tasks.
6. Check who controls the accounts. Make sure the business owns the domain and has access to both the old and new hosting. If you’re setting up access for a client, our article on handing off a website without giving away your accounts helps.
7. Choose a switch time when traffic is low and someone can watch for a few hours afterwards.

Phase 2: Set up the new home

1. Copy or rebuild the site on the new host or platform.
2. Keep every page address identical wherever possible, including trailing slashes and capital letters if the old site used them.
3. Where addresses must change, write a redirect map from each old address to its closest new page, using permanent (301) redirects.
4. Carry over existing redirects from the old site, pointing them straight to final addresses.
5. Bring across page titles, descriptions and headings exactly, unless you’re deliberately improving them.
6. Recreate forms and connect them to the right inbox.
7. Set up https on the new host so the site will load securely from the first minute.
8. Hide the temporary copy from search engines while it’s being tested.

Phase 3: Test before switching

Test the new site on a temporary or staging address before the domain points at it. If you haven’t worked this way before, staging vs production explains the idea.

• Compare page by page. Open the old and new versions of your most important pages side by side. Same content, same images, same links?
• Check every address on your list loads on the new site or redirects correctly.
• Test every form end to end.
• Check on a real phone and in at least two browsers.
• Check speed on key pages; a move should make things faster, not slower.
• Check images and downloads all load; missing files are common when moving between platforms.
• Check internal links point to the right addresses.
• Check the “don’t index” setting is on for the temporary copy and will be off for the live site.

Phase 4: Switch the domain

1. A day or two before, lower the cache time (often called TTL) on the domain’s records if your provider allows it, so the switch spreads faster.
2. Freeze changes on the old site, so nothing is edited in the old place after you’ve copied it.
3. Take a final copy of the old site and any recent content.
4. Update the domain records to point at the new host. Leave email records alone unless email is moving too.
5. Make sure the plain domain and the “www” version both work and one redirects to the other.
6. Check https works on the live domain with no warnings.
7. Turn off the “don’t index” setting on the live site.

Phase 5: Check after the switch

Right away:

• Load the site on a phone using mobile data, which is less likely to show a cached old version.
• Click through the main pages and test every form.
• Send a test email to and from the business’s address to confirm email still works.
• Spot-check old addresses that should redirect.

In the first week:

• Submit the sitemap in your search tools and watch for “page not found” errors.
• Add redirects for any old addresses you missed.
• Confirm analytics, if used, is recording visits.

In the first month:

• Compare visits to your most important pages with before the move. A sharp drop on a specific page usually means a missing redirect or missing content.
• Keep the old hosting running for at least a couple of weeks, until you’re sure nothing still depends on it. Then cancel it, after taking one last copy.

Common migration mistakes

Most failed migrations come down to a handful of avoidable slips:

• Forgetting email. The website moves and the business stops receiving email, because the domain’s email records were replaced or not copied.
• Changing addresses without redirects, often because the new platform formats them differently by default.
• Leaving the “don’t index” setting on after the temporary copy becomes the live site.
• Editing the old site after the copy was taken, so recent changes are lost in the move.
• Cancelling the old hosting too soon, before checking that nothing, like an image or a download, still loads from it.
• Moving and redesigning at once without the extra checks. If you change the look and the host together, treat it as a redesign as well as a migration.

Migration checklist at a glance

• Reason for moving and must-not-change list written.
• Full copy of the old site stored elsewhere.
• Every page listed, with visits and links.
• Every domain record written down, especially email.
• Forms, scripts, redirects and other dependencies listed.
• Account ownership confirmed.
• New site set up with identical addresses, or a redirect map.
• Titles, descriptions, forms and https carried over.
• New site tested on a temporary address.
• Domain cache time lowered; changes frozen; final copy taken.
• Domain switched; www and https checked; indexing turned on.
• Forms, email and redirects tested after the switch.
• Errors and traffic watched for a month.
• Old hosting cancelled only when safe.

Where Devdwell fits

Devdwell isn’t a host, so it doesn’t replace the domain and hosting work above. It can help with the site itself. You can import an existing website from a folder or zip, check and change it with a live preview, and publish a private staging copy to test before anything goes to the real address. When you’re ready, production is one button. Afterwards, the site sits on your dashboard with its live status, so you can see that it’s published, and every saved change is kept with its history and synced between your computers.

Questions