Website Migration Checklist 2026: The 72-Point Launch Plan

A website migration is not a design handoff. It’s a controlled move of a working business asset.

If your site brings in calls, quote requests, form submissions, demo bookings, orders, or search traffic, a bad migration can quietly damage revenue. The site might look better on launch day while old URLs return 404s, forms stop sending, tracking breaks, or Google spends weeks sorting out signals that should have been clear.

Google treats URL-changing moves as serious enough to publish a dedicated site move and migration guide. Google also says a hosting move without URL changes should be handled by testing the copy, verifying Googlebot access, and lowering DNS TTL before the move. That tells you the standard: plan it like operations, not like a Friday afternoon upload.

Use this checklist before a redesign, CMS switch, domain change, host move, HTTPS cleanup, page structure change, or ecommerce rebuild. It is written for business owners and web professionals who need one thing above all else: no surprises after launch.

What counts as a website migration?

A website migration is any change that can affect how people, search engines, browsers, or business systems reach your site.

Google’s migration documentation covers moves with URL changes, including protocol changes, domain changes, path changes, and full site replacements. Google separately documents hosting moves where URLs stay the same because infrastructure changes can still affect crawling, DNS, speed, and availability.

The practical version is simpler. If the change touches URLs, hosting, CMS, templates, content, navigation, forms, analytics, redirects, structured data, or DNS, treat it as a migration. That includes:

1. Redesign with the same CMS. The risk is usually templates, internal links, page speed, tracking, forms, and changed content.
2. CMS move. WordPress to Webflow, Squarespace to WordPress, Shopify to a custom stack, or anything similar changes templates, URLs, fields, media handling, redirects, and publishing workflows.
3. Domain or URL structure change. This is where redirect mapping becomes the job. Google recommends permanent server-side redirects when a URL changes permanently.
4. Hosting move. Even when URLs do not change, Google recommends preparing the new infrastructure, testing a copy, checking Googlebot access, and temporarily lowering DNS TTL values.
5. HTTPS, www, or trailing-slash cleanup. These look small, but they can create duplicate URL versions, redirect chains, broken canonicals, and mixed content.
6. Ecommerce or lead-gen rebuild. This adds checkout, forms, CRM routing, inventory feeds, email delivery, payment settings, thank-you pages, and conversion tracking.

The business case for slowing down before launch

Speed matters, but rushing the wrong parts costs more than a careful launch window.

Google’s Core Web Vitals guidance says good user experience targets are LCP within 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. Those are not decoration metrics. They measure whether the main content appears quickly, whether the page responds when someone interacts, and whether the layout jumps around while loading.

The web has also gotten heavy. The 2025 HTTP Archive Web Almanac reported that the median home page was 2.86 MB on desktop and 2.56 MB on mobile. The same chapter explains why large pages can create performance, data-cost, accessibility, and device-processing problems, especially for users on slower devices or constrained connections.

A good launch plan protects the old value while fixing the parts that made the old site hard to run.

Security belongs in the same conversation. Verizon’s 2026 DBIR page says businesses reduce breach risk by using MFA, keeping software updated, training employees, encrypting sensitive data, testing defenses, and having an incident response plan. A migration that moves admin accounts, plugins, hosting, forms, and customer data without a security pass is asking for trouble.

Phase 1: Define the migration before anyone designs

Do this before wireframes, theme shopping, platform demos, or agency proposals.

1. Name the migration type

Write down exactly what is changing:

1. Domain
2. CMS
3. Hosting
4. URL structure
5. Design templates
6. Content
7. Navigation
8. Ecommerce
9. Forms and CRM
10. Analytics and ad tracking
11. DNS and email records
12. Security model

2. Set the success metrics

Pick the numbers you will protect and improve. For a small business site, that usually means organic sessions, top landing pages, form submissions, call clicks, booked appointments, quote requests, ecommerce revenue, Core Web Vitals, indexed pages, and 404 count.

Use the numbers from your own analytics and Search Console. Google’s Core Web Vitals report is based on real-world usage data and groups URLs by LCP, INP, and CLS status, so use it as one baseline.

3. Freeze risky changes

Separate the migration from unrelated experiments. Do not change brand positioning, cut half the content, rebuild all URLs, replace every form, and swap CRMs in one launch unless there is no other choice.

4. Pick a launch window

Avoid launching right before a trade show, paid campaign, holiday sale, hiring push, or the busiest week of your sales cycle. If your team is small, launch when your developer, marketer, owner, and hosting support can all respond quickly.

Cloudflare recommends lowering TTLs 24 to 48 hours before a planned DNS migration window, or longer if your longest current TTL requires it. That single detail can change your timeline.

Phase 2: Inventory the current site

You cannot protect what you never counted.

5. Crawl the current website

Export every indexable URL, title tag, meta description, H1, canonical, status code, redirect, image, PDF, and internal link. Screaming Frog’s migration tutorial recommends crawling old URLs and then using list mode with redirect following to test where they land after migration.

Keep the crawl export, Search Console landing pages, analytics landing pages, backlink data, and sitemap URLs in one folder.

6. Pull the pages that already matter

Not every page has the same business value. Mark pages that have organic traffic, paid traffic, backlinks, form submissions, sales value, local visibility, or customer support value.

Google says a sitemap helps search engines understand pages, videos, files, and relationships on your site so they can crawl more efficiently, but your migration plan should go deeper than a sitemap. A page with no recent traffic might still be the only page explaining a service your sales team sends to prospects.

7. Export business-critical content

Save copy, images, PDFs, videos, downloads, forms, testimonials, case studies, schema, tracking snippets, robots.txt, XML sitemaps, redirects, DNS records, and plugin settings.

If you cannot export full content, media, metadata, redirects, and form data, put that risk in writing before launch.

8. Identify pages to keep, merge, redirect, or retire

Create one row per current URL and assign one action:

1. Keep the same URL
2. Move to a new URL
3. Merge into another page
4. Redirect to the closest relevant page
5. Return 410 only if the content is truly gone and has no useful replacement

Avoid redirecting everything to the homepage. Google’s redirect guidance says redirects help send people and Google Search to the new location, and permanent redirects are the right signal for permanent URL changes. A vague homepage redirect is not a replacement for a specific old service page.

Phase 3: Build the redirect map

This is the part that saves rankings, backlinks, and sanity.

9. Map old URLs to new URLs one-to-one

Every old URL with traffic, backlinks, internal links, paid campaign history, or customer use should have a new destination. The destination should match intent, not just topic category.

Example: an old /cnc-machine-repair/ page should point to the new CNC repair page, not to /services/ unless that is truly the closest replacement.

10. Keep redirect chains short

A redirect chain slows the trip and creates more places to fail. If an old URL already redirects, update the rule so it goes straight to the final destination.

Screaming Frog’s SEO Spider product page describes features to find temporary and permanent redirects, redirect chains, loops, broken links, 404s, and server errors. Use a crawler before customers find the mess.

11. Preserve canonical signals

Google says canonical methods include redirects, rel=“canonical”, and sitemap inclusion, and its documentation describes redirects as a strong canonicalization signal. Your canonical tags, sitemap URLs, internal links, and redirects should all agree.

12. Keep a rollback copy

Save the old redirect file, DNS export, old crawl, current sitemap, analytics baseline, and database backup. If something goes wrong, you want files, not memories.

Phase 4: Build the staging site like it will be inspected

13. Block staging from indexing

Use authentication or another reliable control for staging. Do not let the staging site compete with the live site. Google’s robots.txt guide says robots.txt is not a mechanism for hiding pages from Google because disallowed pages can still be indexed if linked elsewhere. Password protection is cleaner for a private staging site.

14. Keep real content in the templates

Use real service pages, real products, real testimonials, and real conversion paths. Placeholder copy hides layout breaks, weak CTAs, missing alt text, and oversized images.

15. Test forms like a salesperson

Submit every form. Check required fields, spam controls, thank-you pages, email notifications, CRM records, autoresponders, UTM capture, phone links, calendar embeds, and file uploads.

16. Rebuild tracking intentionally

Install analytics, ad pixels, consent tools, call tracking, heatmaps, CRM scripts, ecommerce events, and conversion goals from a written list. Do not copy random old snippets unless someone knows what they do.

17. Check accessibility while fixes are still cheap

Use semantic headings, readable contrast, keyboard-friendly navigation, descriptive link text, labels on form fields, useful alt text, and visible focus states.

The W3C Web Content Accessibility Guidelines explain that WCAG is built around content being perceivable, operable, and understandable. You do not need to turn a small business launch into a legal seminar, but you do need to make the site usable.

Phase 5: Pre-launch technical QA

18. Crawl staging before launch

Find broken internal links, missing titles, duplicate titles, missing H1s, accidental noindex tags, broken images, redirect loops, orphan pages, wrong canonicals, and blocked resources.

Google’s Search Console Core Web Vitals report only includes URLs with enough field data and indexed URLs, so new or low-traffic pages may not show complete field data immediately. That is why you need your own crawl and lab tests too.

19. Test performance on the templates that matter

Run PageSpeed Insights or Lighthouse on the homepage, top service page, top blog post, contact page, ecommerce category, product page, and any landing page template.

Start with the things users feel: oversized hero images, render-blocking scripts, heavy third-party tags, font loading, layout shifts, and slow server response.

20. Check mobile manually

Tap the phone number. Open the menu. Submit the form. Read a service page. Scroll a product page. Click the sticky CTA. Try it on a real phone, not only a desktop browser set to mobile width.

21. Verify security basics

Turn on MFA for admin accounts, remove unused users, update plugins and dependencies, check SSL, remove default admin paths when practical, restrict staging access, and confirm backups.

Verizon’s DBIR guidance lists MFA, software updates, employee training, encryption, security testing, and an incident response plan as ways businesses can reduce breach risk. A migration is a natural time to clean up old access.

22. Confirm DNS and email records

Export DNS records before touching anything. Confirm A, AAAA, CNAME, MX, TXT, SPF, DKIM, DMARC, verification records, CDN settings, and SSL settings.

Cloudflare’s TTL documentation says proxied records use an Auto TTL of 300 seconds, while nameserver documentation notes that shorter TTLs can be useful when changing nameservers or migrating. Know your provider’s behavior before launch day.

Phase 6: Launch day

23. Put one person in charge

One owner should call the sequence. Another person can QA. A third can watch analytics and forms. Do not let five people make DNS, CMS, and redirect changes at the same time.

24. Run the launch sequence

Use this order unless your stack requires otherwise:

1. Final content freeze
2. Final backup
3. Put redirects in place
4. Push the new site
5. Switch DNS or hosting route
6. Confirm SSL
7. Remove staging blocks from production
8. Check robots.txt and noindex tags
9. Crawl key URLs
10. Submit forms
11. Verify analytics and conversions
12. Submit the XML sitemap in Search Console
13. Test old URLs from the redirect map
14. Check the top landing pages on mobile
15. Watch server logs, uptime, and Search Console

Google’s sitemap documentation says you can build and submit a sitemap, but a sitemap does not replace redirects, internal links, or quality control.

25. Test the old URLs first

Paste your top old URLs into a crawler or redirect checker. Confirm status code, final URL, canonical, title, and page content.

26. Check real conversions

Submit a real test lead. Place a test order if ecommerce is involved. Confirm the lead lands in the right inbox, CRM, analytics goal, and ad platform. ## Phase 7: The first 30 days after launch

27. Watch the daily signals

For the first week, check organic landing pages, 404s, redirect errors, form submissions, Core Web Vitals lab tests, server errors, crawl anomalies, ad conversions, and revenue.

Google’s Core Web Vitals report uses field data, so it may lag behind your launch work. Pair it with crawl data, analytics, PageSpeed Insights, and actual form testing.

28. Fix 404s by value

Sort 404s by pages with backlinks, traffic, paid visits, internal links, or business value. Fix those first.

29. Keep the old domain and redirects alive

If you changed domains, do not let the old domain expire. Keep redirects running. Google provides a Change of Address tool for some site moves, and its help page says redirects and rel=canonical can reduce old URLs shown in Search when equivalent pages exist.

30. Compare against your baseline

Look at the numbers you wrote down before launch. Compare leads, calls, traffic, rankings, page speed, indexed pages, and error counts.

If top service pages lose traffic and their redirects, content, internal links, or canonicals changed, investigate quickly.

A simple migration scorecard

Use this scorecard before you give final approval:

If any of those rows are blank, the site is not ready. That does not mean you cancel the project. It means you have found the risk while you can still control it.

FAQ

How long does a website migration take?

A small brochure site can move in a few weeks if content, DNS, hosting, redirects, and approvals are clean. A larger site with ecommerce, hundreds of URLs, CRM integrations, and paid campaigns can take months. The timeline depends less on page count than on risk count.

Will a migration hurt SEO?

It can, but it does not have to. The safest migrations preserve valuable content, map old URLs to relevant new URLs, use permanent server-side redirects, keep internal links clean, submit accurate sitemaps, and monitor Search Console after launch. Google’s own migration guidance exists because URL changes need careful signaling.

Should I change URLs during a redesign?

Only when the new URLs are clearly better. If an existing URL ranks, earns leads, has backlinks, and makes sense to customers, keeping it is often safer. Change URLs when structure is confusing, old slugs are wrong, services changed, or the CMS requires it. Then redirect with intent.

What is the biggest website migration mistake?

The most common mistake is launching the new design without a full old-to-new URL map. The second is not testing forms, tracking, and conversion paths like real customers use them. Pretty pages do not matter if leads disappear.

Who should own the migration checklist?

One person should own the checklist, even if several people do the work. For a small business, that might be the owner, marketing manager, agency project lead, or developer. Shared ownership sounds polite, but launches need one clear driver.

Need help moving a website without breaking it?

If you’re planning a redesign, CMS move, or hosting change and want a calm launch instead of a fire drill, Your Web Team can help. We’ll map the risks, protect the pages that matter, test the conversion paths, and keep the launch grounded in business outcomes.

Start here: get help with your website migration.