Website Migration Checklist

What counts as a website migration

Website migration sounds technical, but it covers a lot of everyday changes. You are migrating if you are:

• moving to a new website platform or builder
• redesigning in a way that changes page addresses
• changing your domain name
• moving from http to https
• moving to a new hosting company
• merging two websites into one

Some moves are low risk, like switching hosts with every address staying the same. Others, like changing domain and platform at the same time, need careful planning. This checklist covers them all, so skip what does not apply.

“A website migration is not a launch. It is a move, and moves go wrong when nobody makes a list.”

Why migrations go wrong

When a migration hurts a business, the cause is usually something simple that nobody checked:

• Missing redirects. Old addresses lead to error pages, so customers and search engines hit dead ends.
• Blocked crawling. A setting that hid the test site from Google is still switched on after launch.
• Lost tracking. Analytics, ad conversion tags or Search Console verification were left behind.
• Broken forms. Enquiries go nowhere for days before anyone notices.
• Email outages. A DNS change breaks the business email running on the same domain.

Every one of these is preventable with a checklist and a bit of patience.

The good news: none of these needs deep technical skill to catch. They need someone with a list, checking each item before and after launch.

Types of migration and their risk

If you can, avoid stacking changes. Changing platform, design and domain at the same time makes it much harder to work out what caused a problem.

Who does what

Even a small migration involves several parties. Know who is responsible for each piece before you start:

Collect logins and contact details for each one before launch day. Hunting for a domain password at midnight is nobody’s idea of fun.

If you are choosing a new platform

If the migration is to a new website platform, choose it with the next move in mind too.

• Can you export your content and data if you leave later?
• Who owns the site: you, or the provider?
• Does it handle the redirects, forms and integrations you need?
• What support is included, and who fixes things when they break?
• Will it be fast and easy to update for the people on your team?

Our guide on how to choose a web designer covers the questions to ask before you commit.

Step one: plan the move

• Set the goal. Why are you moving, and what must be true after launch?
• Pick the timing. Choose a quieter period for your business, not your busiest season.
• Name an owner. One person keeps the checklist and makes final calls.
• Back everything up. Files, database, images and settings, stored somewhere safe.
• Freeze content. Pause major edits to the old site while you build the new one.

Google’s own site move guidance suggests splitting a move into smaller steps where that makes sense, and for large sites, moving one section first to test the effect. For most small business sites, the key is simply not rushing.

A sample timeline

Every project is different, but a typical small business migration might run like this:

• Several weeks out. Goals, owner, inventory and backups.
• A few weeks out. Build on staging, prepare the redirect map and rebuild tracking.
• The week before. Full testing, DNS review, TTL lowered and team briefed.
• Launch day. Switch over, redirects on, blocks removed, sitemap submitted, essentials tested.
• The weeks after. Monitoring, fixing gaps and updating listings.

Rushing the planning stage is the most common way a simple move becomes a painful one.

Step two: take an inventory

You cannot move what you have not listed. Before building anything, record:

• every page address, from your sitemap, your website platform and the Search Console Performance report
• your most visited and most important pages
• every form and where its submissions go
• integrations: booking tools, payments, chat, newsletters and CRM
• tracking: analytics, ad conversion tags, tag manager and Search Console verification
• any redirects already in place

Save the list in a spreadsheet. It becomes your redirect map, your test plan and your launch-day checklist.

Take screenshots of your key pages too. They are a quick reference for what the old site looked like and what it said, long after the old site is gone.

Use the move to tidy up, carefully

A migration is a natural moment to clean house: outdated pages, duplicate content, old offers and pages nobody visits.

• Remove pages that are genuinely obsolete, and redirect them to the most relevant remaining page.
• Merge thin pages that cover the same topic into one stronger page.
• Update facts, prices, team members and photos as you move content.
• Keep your best-performing pages largely intact. If a page brings in steady enquiries, improve it gently rather than rewriting it from scratch.

Do not overdo it. The more you change at once, the harder it is to tell what caused any drop in traffic. Big content overhauls can wait until the new site has settled.

Merging two websites into one

Businesses sometimes run two sites, such as an old brand and a new one, or a separate site for one service. Merging them can simplify everything, but it takes care.

• Decide which domain will be the main one going forward.
• Map every page on the site being retired to its best match on the main site.
• Combine overlapping content into single, stronger pages.
• Redirect the retired site’s addresses page by page, not all to the homepage.
• Keep the retired domain registered, so its redirects keep working.

Merged well, two sites with split attention become one site with all of it.

Step three: map old addresses to new ones

If any page addresses are changing, this is the most important step. Google’s site move guidance calls it preparing a URL mapping: a list that pairs each old address with its new one.

• Keep addresses the same wherever you can. No change means no redirect needed.
• Map each old page to its closest new equivalent, one to one where possible.
• If you combine several old pages into one, redirect them all to that new page.
• Do not send everything to the homepage.

Step four: carry over what search engines rely on

A new design should not mean starting from zero in search. Carry over:

• page titles and meta descriptions, improved where needed but not lost
• headings and the substance of your best-performing content
• image alt text
• structured data, if your old site used it
• links between your own pages, updated to the new addresses

Google’s guidance also says each new page should have a self-referencing canonical tag, pointing to its own new address, and that internal links should be changed to the new addresses rather than relying on redirects.

Step five: build and test on a staging copy

Build the new site somewhere visitors and search engines cannot see it yet, often called a staging site. Then test it properly:

• every form, booking tool and payment, end to end
• every page on a phone, a tablet and a desktop
• page speed on key pages
• links, buttons and menus
• accessibility basics like headings, alt text and contrast

Many teams block search engines from the staging site while it is being built. That is sensible, but Google’s guidance is clear that any temporary blocks, such as robots.txt rules or noindex tags, must be removed when the move starts. Forgetting this one step can quietly hide a new site from Google.

Fix speed and accessibility while you are at it

A new build is the cheapest moment to get the foundations right.

• Compress images and avoid heavy page builders or plugins you do not need.
• Make sure headings are structured, buttons are labelled and colour contrast is readable.
• Check that forms can be completed using a keyboard alone.
• Test key pages with a free speed tool before launch.

Fixing these after launch usually costs more than getting them right during the build.

Step six: rebuild tracking before launch

Tracking is the part most often lost in a platform move, and you only notice weeks later when the numbers look strange.

• Add your analytics tag to the new site and test that visits register.
• Recreate conversion tracking for forms, calls and bookings.
• Update ad tracking and check that conversions still record.
• Carry over your Search Console verification. Google notes that if you verified with a meta tag or analytics, the new site must include it too.

Our guide to website analytics for small business covers what to track and why.

Note the date of the switch in your analytics, so anyone looking at the numbers later understands any change in the trend.

Step seven: protect your email and DNS

Your domain’s DNS settings control where your website lives, and often where your email goes. Moving a website can involve changing DNS records or nameservers, and that is where email accidents happen.

• Write down every existing DNS record before you change anything, especially email records.
• If you are moving nameservers, recreate all records, not just the website ones.
• Lower the TTL on your DNS records ahead of the move. Google’s hosting move guide notes this helps new settings spread faster.
• Test sending and receiving email straight after the change.

Step eight: set up redirects properly

Redirects send visitors and search engines from old addresses to new ones. Google’s redirects documentation explains that permanent redirects tell Google the new page should be shown in search results, and recommends server-side permanent redirects such as 301 or 308 where possible.

• Use permanent redirects for pages that have moved for good.
• Redirect straight to the final page. Google advises avoiding chains of redirects, and if a chain cannot be avoided, keeping it short.
• Test every redirect in your map after launch, not just a few.
• Keep redirects in place for the long term.

Google’s site move guidance also says that 301 and other permanent redirects do not cause a loss in PageRank. In plain terms, redirects done well carry the value your old pages have built over to the new ones.

Moving to https

If your site still runs on http, moving to https is worth doing, and often happens as part of a wider migration.

• Install a valid security certificate for every version of your domain you use.
• Redirect every http address to its https version with permanent redirects.
• Fix mixed content, such as images or scripts still loading over http.
• Add the https version of your site in Search Console if it is not already covered by a Domain property.

Google’s site move guidance notes that the Change of Address tool is not needed for an http to https move. Redirects and updated links do the job.

Extra checks for online stores

If you sell online, a migration has more moving parts. Before launch, also check:

• product and category addresses, and their redirects
• customer accounts, and whether customers need to reset passwords
• payment processing, with real test transactions
• order confirmation and shipping emails
• tax, shipping and discount settings
• inventory levels and product variants

Run a few complete test orders from start to finish, including a refund, before you switch over.

Launch day checklist

1. Take a final backup. Of both the old site and the new one.
2. Switch on the new site. Change DNS or publish, depending on the type of move.
3. Turn on redirects. Every entry in your redirect map.
4. Remove temporary blocks. Robots.txt rules and noindex tags used during building.
5. Submit the new sitemap. In Search Console, so Google discovers new addresses faster.
6. Test the essentials. Forms, bookings, payments, email, tracking and key pages on mobile.
7. Inspect key pages. Use URL Inspection in Search Console on your homepage and top pages.

Launch early in the week and early in the day if you can, so people are around to fix anything that goes wrong.

Have a rollback plan

Most migrations go fine. Plan for the one that does not.

• Decide in advance what would trigger a rollback, such as payments failing or the site going down.
• Keep the old site and hosting ready to switch back to for a while after launch.
• Know exactly which DNS or settings changes would reverse the move.
• Agree who makes the call, so nobody wastes time debating in a crisis.

You will probably never use it. Having it ready is what lets everyone launch calmly.

Tell people what is happening

A little communication prevents a lot of confusion.

• Tell your team when the move happens and what to watch for, like form submissions or customer calls about the site.
• If customers will need to log in again or reset passwords, tell them in advance.
• Let key suppliers and partners know if your domain or email addresses are changing.
• Have someone check incoming enquiries closely for the first few days.

Customers forgive a short disruption they were warned about far more readily than one that takes them by surprise.

Changing your domain name

A domain change needs everything above, plus a few extra steps:

• Verify both the old and new domains in Search Console.
• After redirects are live, use Google’s Change of Address tool for the old domain. Google says you only need it for domain or subdomain changes, not for http to https or www changes.
• Submit Change of Address requests for all verified variants of the old domain, such as www and non-www.
• Keep the redirects running. The Change of Address help page says to maintain them for at least 180 days, and longer if they still receive Google traffic, while the site move guide recommends keeping them as long as possible, generally at least a year.

If you are only changing hosts

A pure hosting move, where every address stays the same, is simpler. Google’s hosting move guide boils it down to preparing the new hosting, testing it, updating DNS to point to it, monitoring traffic on old and new hosting, and only then shutting down the old hosting.

The main risks are DNS mistakes, email records and anything on the old server that was not copied, like images or settings. Keep the old hosting running until you are sure traffic has moved and everything works.

The first few weeks after launch

The move is not finished on launch day. Google’s guidance says to expect temporary ranking fluctuation while it recrawls and reindexes the site, and that for medium-sized sites it can take a few weeks or more for new addresses to replace old ones in results.

• Check Search Console several times a week for errors and indexing problems.
• Watch for 404 errors on old addresses and add missing redirects.
• Compare traffic and enquiries with the weeks before launch.
• Re-test forms and tracking after any fixes.

Our guide to Google Search Console for small business shows where to look.

How to know the migration worked

After the first month or so, compare against your baseline from before the move:

• Enquiries, bookings and sales are back to normal levels or better.
• Search Console shows your key pages indexed at their new addresses.
• Traffic from Google search has settled, with no lasting drop on important pages.
• Forms, tracking and email all work, with no gaps in the data.
• Customers are not reporting broken links or missing pages.

If something is still off, work through the checklist again: redirects, blocks, canonical tags, tracking and DNS. The cause is almost always one of those.

Update your address everywhere else

Your website address lives in more places than your website. After a domain or major address change, update:

• your Google Business Profile website link
• social media profiles
• online directories and listings
• email signatures, invoices and quote templates
• ads, including final destination addresses
• printed materials, as you reprint them

Our guide to setting up your Google Business Profile covers keeping your listing accurate.

Chase down links to your old addresses

Redirects catch most old links, but it is worth updating the important ones at the source so visitors go straight to the right page.

• Ask partners, suppliers and associations that link to you to update the address.
• Update links in your own newsletters, social posts and online profiles.
• Check your most-linked pages in Search Console’s Links report and make sure each one redirects correctly.

Every direct link you update is one less redirect for visitors to wait on.

Common migration mistakes

• No redirect map. Hoping old links will sort themselves out.
• Everything redirected to the homepage.
• Search engines still blocked after launch.
• Tracking left behind on the old site.
• Email broken by a DNS change.
• Old hosting cancelled before everything was copied and confirmed.
• Launching in the busiest week of the year.

A written checklist, a tested plan and a quiet launch window prevent nearly all of them.

Document everything

Keep a simple record of the move: the redirect map, DNS records before and after, logins, the test checklist and any problems you fixed. Store it somewhere the whole team can find it.

The next time anyone touches the website, whether next month or in three years, that record will save hours of guesswork.

Include the date of the move and who did the work.

Doing it yourself vs getting help

A small hosting move or a simple https switch can be a manageable DIY job if you are comfortable with DNS and your platform. A platform change, a redesign with new addresses or a domain change is where professional help usually pays for itself, because the cost of lost enquiries quickly exceeds the cost of doing it right.

Whoever does the work, ask for the redirect map, the test results and a list of every DNS change before launch. Those three documents tell you whether the move has been planned properly. Our website launch checklist covers the final pre-launch checks.

Frequently asked questions