A website migration plan your marketing team can review

Make the move reviewable before making it live

Before I recommend moving a website, I want to know what must survive the move. The visible pages are one part of that picture. Signups, customer records, editorial habits, useful URLs, and the people maintaining them matter just as much. I would rather make those dependencies explicit at the start than discover them when the new homepage is ready.

Build the inventory from more than the navigation

Collect current URLs from the CMS, sitemap, Search Console, available analytics, and known campaign links. Include PDFs, landing pages, images with important incoming links, and pages that are no longer linked from the menu. Note the purpose, owner, and proposed action for each. A crawler can help discover pages, but no single source should be assumed to contain every important address. Ask sales and marketing about URLs used in emails, advertisements, customer documents, and external profiles.

Give every important URL a deliberate destination

Mark each address as retained, moved, merged, or removed. If a page moves, map it to a relevant replacement and implement a permanent redirect where appropriate. If several pages merge, confirm that the destination actually covers their subject. Avoid sending every retired URL to the homepage: Google warns against redirecting many old URLs to an irrelevant destination. If content has no suitable replacement, a proper 404 or 410 may be the honest result. Review the decisions with the people who understand the content before implementing the rules.

Assign content owners and approval states

A migration plan should distinguish content that is approved, needs editing, needs an asset, or should be retired. Give each item an owner and a review deadline. Separate building a CMS template from populating and checking its entries. Test representative content early, including long titles, embedded media, internal links, and optional sections. Decide whether the migration includes rewriting content or transferring it as approved. An unresolved content decision can delay launch even when all the page templates are technically finished.

List integrations by their expected result

For each form, booking link, CRM connection, analytics tool, search feature, or gated resource, describe what a successful interaction should do. Name an account owner and a tester. “Form connected” is too vague; “a labelled test is accepted, appears in the dashboard, and reaches the right inbox” is reviewable. Record whether an integration depends on domain restrictions, credentials, account approval, or a third-party setting. Use the new production domain for the final checks because a successful preview test does not exercise every production condition.

Agree the switch and the rollback decision

Identify who can change DNS or hosting routes, who approves the release, who runs the live checks, and who decides whether to reverse the switch. Record the previous configuration and make the rollback procedure specific to your hosting arrangement. Agree a content freeze or a method for capturing changes made during the final transfer. Back up the content and configuration you may need. A rollback plan is useful only when the named people have the access and information required to carry it out.

Check the release in a deliberate order

• Confirm HTTPS and the intended canonical hostname; test both www and non-www behaviour.
• Open representative pages and assets on mobile and desktop, including deep links entered directly.
• Test the old-to-new URL map and check for chains, loops, and irrelevant destinations.
• Confirm production has the intended robots directives and has not retained a staging noindex setting.
• Check canonical URLs, the production sitemap, and representative structured data.
• Run real form and booking checks, then verify the receiving accounts or inboxes.
• Test a genuinely missing URL and confirm the server returns a proper not-found status.

Give search engines a clear view of the change

Submit the production sitemap in the correct Search Console property and inspect important changed URLs. Google describes a sitemap as a discovery aid, not a guarantee of crawling or indexing. URL Inspection can request indexing for individual URLs; repeated requests do not make crawling faster. If URLs change, search visibility may fluctuate while Google processes the move. Keep redirects in place for the period recommended in Google’s current site-move guidance, generally at least a year, and longer where people still use the old links.

Watch what happens after launch

Review Search Console indexing and crawl information, redirect failures, and real customer journeys after the switch. Compare traffic and enquiries with suitable context rather than assuming every movement was caused by the migration. Assign owners to fix emerging issues and keep the migration record current. A successful move is more than the new homepage appearing: the right content remains reachable, the team can publish, and the business can still receive and respond to enquiries.