Website Migration Checklist & Governance Playbook

Most migration checklists you’ll find are SEO checklists wearing a bigger hat. Crawl the old site, map the redirects, check the title tags, watch the rankings. All necessary. None of it is the part that actually breaks.

The part that breaks is everything else.

DNS is the easy part. What’s hard is the silent breakage of the surrounding ecosystem. When you move a domain, SMTP settings can go haywire, stopping your order confirmations from sending. Automated Salesforce ingestion rules go kaboom; the form submits and the thank-you message appears, but nothing lands in your CRM for four days. Call tracking numbers stop swapping, and your Merchant Center feed ends up pointing at URLs that 404. 

Unfortunately, none of these potentially catastrophic failures show up in a rank tracker until the die is already cast.

The Often Overlooked Need: Everything needs to function from A to B 

Whether the initial goal was a visual update, a server upgrade, or a shopping platform switch, the reality is that there are more moving parts than most site owners realize. Understanding the technical ecosystem a website lives inside is fundamentally different than just updating DNS records, and that is the entire thesis of this document.

Our team has run migrations across ecommerce, lead-gen, and SaaS platforms. We frequently coordinate directly with IT, ERP vendors, dev shops, sales ops, and marketing teams, acting as the party holding the most direct responsibility for a smooth landing. The migrations that go well all share one common trait, and it isn’t the tooling.

It is effective communication. Every migration failure we’ve post-mortemed traces back to a handoff nobody owned, an assumption nobody stated, or a connected system nobody knew about. That’s exactly what “Phase 0” is for, and it is the phase most checklists skip entirely.

TL;DR: The Website Migration Playbook Phases 

A successful migration requires managing the entire ecosystem, not just the website. Here is how we break it down:

• Phase 0: Ecosystem Mapping & Communication Governance – Identifying every connected system (CRM, ERP, email) and assigning strict human ownership before you begin.
• Phase 1: Pre-Migration Asset Recovery – Extracting data, mapping 1:1 redirects, and preventing orphan content.
• Phase 2: SEO Architecture & Structure – Preserving PageRank, consolidating semantic meaning, and mapping schema.
• Phase 3: Conversion Engineering & UX – Testing end-to-end forms, transaction flows, and optimizing the user journey.
• Phase 4: Technical & Analytics Verification – Baselining performance, verifying GA4, and ensuring tracking data integrity.
• Phase 5: Privacy & Compliance Governance – Enforcing WCAG accessibility and proper consent logic.
• Phase 6: Editorial Continuity & Final Cut-over – Managing the content delta and executing the final launch protocol.
• Phase 7: Launch & Post-Launch Monitoring – Verifying live data, tracking index coverage, and safely sunsetting the legacy environment.

What You’re Actually Inheriting

Before anything else: a re-platform is not a website build.

Building a new site from the ground up is straightforward when it connects to nothing. You design it, you build it, you ship it. A re-platform is a different activity that happens to also involve a website. You are moving a live, load-bearing system that is connected to an order pipeline, an inventory system, an email infrastructure, a CRM, an ad account, and however many years of accumulated technical debt — while it continues to take orders and generate leads.

The technical debt is the part leadership almost never sees. On a mature legacy site — a WordPress install that’s been extended for a decade, say — there is frequently no usable backend. Every element was custom-developed. Every user journey, every touchpoint, every form was a dev ticket. Nobody documented it. The person who built it left in 2019.

That debt is why the migration is happening, and it’s also why the migration is expensive. Those two facts get separated in reporting, and they shouldn’t be. When you scope a re-platform, the honest math is often: bringing the legacy system up to modern standard would cost more than moving off it. That’s the decision. Say it out loud, in the deck, to the people funding it.

See Appendix B for how to frame this for an executive audience. Leadership tends to hear “we moved the website.” They need to hear “we replaced the engine while the car was moving.”

Phase 0: Ecosystem Mapping & Communication Governance

This phase does not exist in most migration checklists. It is the one that determines whether the rest of them matter.

Map every system that touches the domain

Do not start with the site. Start with the domain and work outward. Inventory every system that sends, receives, or depends on something at this hostname:

• DNS records: A/AAAA, CNAME, MX, TXT (SPF, DKIM, DMARC), CAA, and every subdomain record pointing at a third-party service you forgot you bought.
• Email infrastructure: Transactional sends (order confirmations, password resets, form autoresponders), the marketing platform’s sending domain and authentication, SMTP relay credentials, and any shared mailbox sitting behind a contact form.
• CRM ingestion: Field-level mapping from form to object. Hidden fields (UTM parameters, GCLID, referrer, originating page URL). Lead assignment and routing rules. Duplicate-detection rules. Required fields that will silently reject a payload if the new form doesn’t populate them.
• Call tracking: Dynamic number insertion scripts, number pools, provisioning. Whether tracking numbers conflict with your NAP consistency for local search.
• Chat, scheduling, and support widgets: Scripts, routing rules, and whether they carry session context.
• ERP / inventory / PIM: SKU sync direction, pricing authority, stock levels, order writeback.
• Payments and tax: Gateway, tax engine, subscription and recurring billing, saved payment methods.
• Authentication: SSO, customer accounts, password hash portability, order history.
• Advertising: Conversion tags, remarketing audiences, product feeds, and every landing page URL sitting inside a live campaign.

For each one, answer three questions: Who owns it? What breaks if it fails? How would we know?

That third question is the important one. Most migration failures aren’t dramatic. They’re silent.

Establish communication governance

• Name a single owner per system, not per team. “IT owns it” is not an owner. A person is an owner.
• One source of truth for the URL map. One document, one location, versioned. Not a spreadsheet emailed around, and not three spreadsheets with different tab names.
• Define who holds go/no-go. One person. Decide this before you need it, because you will need it at 4pm on a Tuesday.
• Set a cadence with every external vendor — dev shop, ERP integrator, agency, IT. Weekly minimum during build, daily during cut-over week.
• Document the inherited technical debt as you find it. You are the only people who will ever have this visibility. Write it down while it’s in front of you. It becomes the scope narrative later, and it’s the difference between “the project took a long time” and “here’s what the project actually involved.”

Migration Red-Flag: Silent Failure. A form that submits successfully, returns a thank-you message, and never reaches the CRM produces no error and no alert. Nothing looks broken. You find out when sales asks why the pipeline is empty. Every integration needs an affirmative test — an end-to-end submission you personally confirm landed in the destination system — not an assumption that it carried over.

Migration Red-Flag: Email Blackout. Changing DNS without auditing MX, SPF, DKIM, and DMARC can take down company email or silently route transactional mail to spam. On an ecommerce site, that means customers stop receiving order confirmations and start calling support. This is the single fastest way to turn a migration into a crisis.

Vertical flags:

• Ecommerce: ERP is usually the system of record for inventory and pricing, not the website. Confirm sync direction and cadence before launch, and confirm what happens to in-flight orders during the cut-over window.
• Lead-gen: CRM field mapping is your revenue path. Map it field by field, including hidden attribution fields. Confirm routing rules fire on the new payload.
• SaaS: The marketing site and the application are frequently different systems on different subdomains with different owners. Establish whether auth, session, and trial-signup attribution survive the handoff between them.

Phase 1: Pre-Migration Asset Recovery

The foundation of a successful migration is a comprehensive understanding of the existing footprint. This phase focuses on data extraction and mapping to prevent orphan content or broken user journeys.

• Double crawl methodology: Perform a full crawl of the legacy site (Screaming Frog or equivalent) to identify every live URL and asset. Run a second crawl against your XML sitemaps and log files to catch URLs the crawler can’t reach through internal links.
• Asset inventory: Catalog all images and PDF files currently hosted on the legacy server. PDFs in particular accumulate external links and rank on their own.
• Asset migration: Confirm all inventoried assets are moved to the new file manager and that internal content links point to the new paths.
• 1:1 redirect mapping: Map legacy URLs to new counterparts and import existing 301 maps from the legacy CMS into the new environment.
• Legacy redirect audit: Identify existing 301 redirects inside the legacy system and move them into the new environment’s URL mapping tool. Mature sites often carry redirects from two migrations ago, still passing equity.
• Content valuation: Not every page earns its move. Pull traffic, conversions, inbound links, and rankings per URL. Decide deliberately what moves, what merges, and what returns a 410.

Migration Red-Flag: 404 Loops. Failing to migrate existing legacy redirects into the new system can create recursive 404 errors, rapidly tanking organic rankings. Chained redirects from stacked migrations are the second-order version of the same problem — flatten every chain to a single hop.

Vertical flags:

• Ecommerce: Discontinued and out-of-stock products need a documented policy before you build the map. 301 to the parent category, 410 the dead SKU, or keep the page live with alternatives — pick one and apply it consistently. Faceted and filtered URLs need their own handling rules, and legacy sites often generated thousands of them.
• Lead-gen: Location pages, service-area pages, and thank-you page URLs. Thank-you URLs are load-bearing — conversion tracking in GA4 and ad platforms frequently depends on the exact path.
• SaaS: Documentation, changelog, and API reference URLs carry disproportionate link equity and are frequently on a separate system from the marketing site.

Phase 2: SEO Architecture & Structure

This phase ensures the SEO DNA of the original site is grafted onto the new infrastructure without losing semantic meaning.

• Metadata and hierarchy: Validate title tags, meta descriptions, and H1–H3 hierarchies for consistency. Page builders reformat headings during import more often than anyone expects.
• Money page internal link audit: Export inlinks from Screaming Frog and analyze the distribution.
  • Topic relevance: Do the links pointing at your money pages bring the intended topic clearly into view?
  • PageRank preservation: Identify extraneous links that dilute equity. Consolidate groups of low-relevance links into single hub page links to tighten topic grouping.
• Anchor text profile optimization: Use the link position filter to audit in-content anchors.
  • Variety and context: Avoid repetitive, spammy anchors. Introduce semantic variety to give search engines better context.
  • GSC integration: Use Search Console data to identify high-performing keywords worth folding into the anchor profile.
• Schema validation: Verify page-specific and sitewide Organization schema.
• Canonicalization: Decide www vs. root and trailing slash vs. not, then enforce it at the server. Every page answers to exactly one URL.

Migration Red-Flag: PageRank Dilution. Having 40+ low-relevance links on a page instead of 3–5 high-relevance hub links scatters authority and weakens the signal to your money pages.

Vertical flags:

• Ecommerce: Product and variant URL structure is the single highest-leverage architectural decision. Legacy platforms often produce dynamic, parameter-driven URLs that were effectively undiscoverable; a clean, hierarchical structure on the new platform is frequently the largest single organic gain in the entire project. Product and Offer schema, collection architecture, and taxonomy all compound from here.
• Lead-gen: LocalBusiness schema and NAP consistency across citation sources. If the migration changes addresses, phone numbers, or location page URLs, run a citation audit — Google Business Profile, Bing Places, Apple Maps, and the aggregators all need to match.
• SaaS: SoftwareApplication and FAQ schema, plus careful handling of docs subdomains and versioned documentation paths.

Phase 3: Conversion Engineering & UX

A migration is an opportunity for feature upgrades. This phase focuses on streamlining the user journey and ensuring messaging remains consistent.

• Subdomain consolidation: Move content from subdomains back to the root domain where possible to consolidate authority.
  • Targeted subdomain use: Reserve subdomains for isolated cases — PPC landing pages, specific email campaigns, the application itself.
• Feature upgrade — embedded forms: Instead of linking out to an external page, embed forms directly into site pages to reduce friction.
• End-to-end form testing: Test every form. Confirm the data reaches the CRM with all fields populated, and confirm the thank-you state appears.
• Transaction flow: Verify every checkout path, donation button, and third-party payment integration is functional and tracked.
• Search functionality: On any site with meaningful inventory, internal site search is frequently a top-visited page. Users expect it to behave like Amazon’s. Confirm it works on the new platform and that your taxonomy actually feeds it.

Migration Red-Flags:

• Lead Leakage. If form data fails to reach the CRM post-migration, the business loses immediate revenue and the attribution data needed to diagnose the loss.
• Design Bloat. Over-designing a page distracts from conversion. If a user would convert faster on your Google Business Profile than on your website, your website UX is failing.

Vertical flags:

• Ecommerce: Cart and checkout are the highest-risk surfaces on the site. Test guest checkout, saved payment methods, promo codes, tax calculation, shipping rules, and subscription billing separately. Also confirm what happens to existing carts at cut-over.
• Lead-gen: Quote request flows, phone click tracking, and call tracking DNI. Confirm the swap script fires on the new templates and that the tracking number appears where it should — and doesn’t appear where it shouldn’t.
• SaaS: Trial signup, demo request, and the handoff from marketing site to application. Attribution frequently dies at that boundary.

Phase 4: Technical & Analytics Verification

• JavaScript rendering audit: Confirm scripts load correctly and don’t interfere with page content or modules. Check that content requiring JS to render is actually visible to crawlers.
• Performance benchmarking: Test load times against a pre-migration baseline. You need the baseline to prove you didn’t regress.
• GA4 integration: Confirm the measurement ID is active on every page of the new site. Every page.
• Conversion listener setup: Implement GTM listeners for form submissions, phone clicks, and email clicks as GA4 key events.
• Event verification: Manually trigger each key action and verify it appears in GA4 DebugView. Manually. Not “the tag is installed, so it should work.”
• Session recording: Confirm Hotjar, Clarity, or equivalent is installed and configured. Installed and configured are different states, and post-launch is exactly when you want qualitative data on what’s confusing people.
• Annotate the launch in GA4 and any BI layer sitting on top of it.

Migration Red-Flag: Tracking Blackout. If GA4 isn’t verified immediately at launch, you have no data to troubleshoot a post-launch traffic drop. You’ll be arguing about whether traffic actually fell instead of fixing why.

Vertical flags:

• Ecommerce: Enhanced ecommerce / GA4 ecommerce events (view_item, add_to_cart, begin_checkout, purchase) each need independent verification. Revenue reconciliation against the platform’s own order data in week one is non-negotiable — if GA4 and the backend disagree, you need to know before anyone builds a forecast on it.
• Lead-gen: Conversion imports back into Google Ads and the CRM. Offline conversion tracking breaks quietly when the lead payload changes shape.
• SaaS: Product analytics identity stitching across the marketing-to-app boundary. Signup attribution is usually the first casualty.

Phase 5: Privacy & Compliance Governance

Compliance is a legal requirement integrated into the technical deployment, not a checkbox at the end.

• Consent banner configuration: Configure for GDPR and CCPA/CPRA as applicable to your traffic, not just your headquarters.
• Consent logic mapping: Ensure tracking scripts only fire after the user has provided the appropriate level of consent. Verify this per-vendor, including tags added by third parties you don’t control.
• Consent Mode and data retention: Confirm settings carried over rather than reverting to platform defaults.
• Accessibility: A re-platform is the cheapest moment you will ever have to address WCAG conformance. It gets more expensive every day after launch.

Migration Red-Flag: Non-Compliant Firing. Triggering tracking scripts before a user clicks Accept can result in legal penalties and brand distrust. Re-verify after launch — tag containers get modified during cut-over.

Phase 6: Editorial Continuity & Final Cut-over

This phase manages the delta — content created on the legacy site during the migration window — and protects existing subscribers.

• Final delta import: Import any blog posts or content published on the legacy site during the transition. Someone published something in week six. They always do.
• Editorial ownership: Formally define whether the internal team or the agency owns new content during cut-over, and freeze publishing on the legacy system at a named date.
• RSS feed redirect: Redirect the legacy feed URL to the new environment’s feed to retain subscribers.
• Choose a smart launch day. Tuesday or Wednesday morning. You get a full day to fix things and the weekend still in reserve. Never Friday.
• Lower DNS TTL in advance of cut-over, and restore it after.

Migration Red-Flag: Orphaned Content. Missing the final delta import creates a gap in your content timeline and loses whatever engagement that content had earned.

Phase 7: Launch & Post-Launch Monitoring

The migration isn’t done at cut-over. It’s done when the data says it’s done.

Launch day:

• Confirm the site is fully available outside your internal network.
• Confirm no assets, links, or canonicals point at the dev or staging environment.
• Confirm robots.txt permits crawling and no sitewide noindex survived from staging. This is the most common catastrophic migration error, and it is entirely preventable.
• Spot-check redirects with a script against the full legacy URL list — not a sample.
• Submit XML sitemaps and file the Change of Address in Search Console if the domain changed.
• Watch the error logs.
• Run one live transaction or one live form submission and follow it all the way to its destination system.

Week 1:

• Daily crawl error monitoring in Search Console.
• Redirect verification against the full legacy list.
• Revenue or lead-volume reconciliation against the backend system of record.
• Confirm transactional email is sending and landing in inboxes.

Days 30–90:

• Track index coverage as the new URLs replace the old.
• Compare rankings and traffic against the pre-migration benchmark, not against last week.
• Coordinate inbound link updates for your highest-value external links — a 301 works, but a direct link works better.
• Sunset the legacy environment deliberately once traffic has stopped.

Appendix A: Vertical Flag Index

Quick reference for the flags that differ by site type.

Appendix B: Reporting Migration Scope to Leadership

This section exists because the work is routinely invisible to the people funding it.

Executives see a new website. They don’t see the eighteen months of accumulated dev tickets, the vendor coordination, or the fact that content and product data had to be sourced by the agency because nobody internally had it in a usable form. When the scope isn’t communicated, the migration gets evaluated against the wrong baseline — “we built a website” — and the team doesn’t get credit for what actually happened.

Four things to make explicit in any leadership readout:

1. The technical debt you inherited. Not as a complaint. As scope. “The legacy platform had no usable backend — every element, user journey, and touchpoint required custom development” is a factual statement about why the project cost what it cost.
2. Why re-platform beat remediation. The decision was economic. Bringing the legacy system to standard would have cost more than moving off it. State the comparison.
3. That a re-platform is not a build. Building from scratch is easy when the site connects to nothing. Moving a live system that’s wired into inventory, orders, email, and CRM is a fundamentally different activity. It’s a transplant, not a print job. Both involve a website in the same sense that both involve a scalpel.
4. What was accomplished against what it normally takes. If the team compressed a multi-year scope into eighteen months, say so with the comparison attached. Work done well looks easy from the outside, and looking easy is expensive.

Timing matters as much as content. Don’t introduce this complexity to an executive audience during a launch window when the priority is keeping the delivery team focused. Let the launch settle, then bring the strategic picture forward when it can actually inform decisions.

Hive Digital has been running site migrations since 2002 — domain changes, platform changes, and full re-platforms across ecommerce, lead-gen, and B2B. No one can guarantee a perfect migration. What we can do is make sure every system that has to function A to B actually does, and that everyone who needs to know something knows it before it matters.