Migrations do not fail because one person forgets a redirect. They fail when dozens of small assumptions collide on launch day and blunt the momentum you spent months building. Over the last decade I have helped organizations move millions of URLs across replatforms, redesigns, and rebrands. The successful ones look boring from the outside, because every risk is named, planned for, and rehearsed. The messy ones share a pattern too, improvised decisions under pressure that ripple through traffic, conversions, and morale.
I wrote this checklist to prevent the messy version. It blends technical SEO, analytics, product management, and operations, and it reflects what an experienced team at (un)Common Logic asks before they put a date on the calendar. Treat it as a living document. Your stack, your constraints, and your goals should tune the details, but the logic holds across industries.
What you are migrating, and why that matters
People say site migration as if it were a single event. In reality, it describes a handful of very different projects.
A replatform moves the backend, such as from a custom .NET app to Shopify or from Drupal to headless. Expect differences in URL patterns, rendering, caching, and permissions. SEO risk is moderate to high, driven by technical parity and how well you map legacy routes.
A redesign changes templates, navigations, and components. SEO risk skews toward internal linking and content visibility, along with Core Web Vitals and accessibility. Conversions can move a lot here, for better or worse.
A rebrand changes names, domains, and messaging. The domain switch brings the largest single SEO risk on the table. If done well, we see 85 to 95 percent of organic traffic retained within the first 4 to 8 weeks, with the remainder usually returning by the 12 week mark. If the brand repositioning also trims content, expect a longer recovery.
An information architecture overhaul reorganizes categories and hubs. SEO risk depends on how your most linked content is handled. Expect flux as Google crawls, consolidates signals, and reassigns canonical importance.
Hybrids occur often. A retailer combines replatforming and IA changes. A SaaS company rebrands while rolling out a component library. The more fronts you open at once, the more time you need to stage, test, and measure.
The stakes, in plain numbers
One client moved 120,000 product pages to a new ecommerce stack. The soft launch environment passed spot checks, but the live CDN cached 302s from old PDPs to category pages, and the redirects never upgraded to 301 at the edge. Crawl budgets went to waste. Rankings fell on mid tail product terms. It took 7 weeks and a lot of pressure to unwind. That one caching header mismatch cost roughly 18 percent of organic revenue for two quarters.
On the other side, an enterprise B2B software company merged two domains into one. They staged redirects for every legacy route, preserved internal anchor text, and pre warmed sitemaps. Within 3 weeks, 92 percent of non branded traffic returned. Within 10 weeks, the consolidated site was up 12 percent YoY, with fewer pages and better internal link equity.
Those outcomes are not luck. They follow from details that teams can control.
Timeline sanity check
Backward plan from a real launch window. Put immovable events on the calendar, like peak season, major ad campaigns, fiscal closes, code freezes, and staffing constraints. A mid sized migration covering https://johnathanwpvd919.image-perth.org/growth-hacking-vs-un-common-logic-what-works 5,000 to 50,000 URLs typically needs 10 to 16 weeks from kickoff to launch if the codebase already exists, longer if you are still building. Shorter timelines force trade offs. If you cannot do everything, pick the right things.
For large catalogs, crawl and mapping tasks alone can consume 2 to 3 weeks, even with automation. Vendor lead times for SSL, DNS, and security reviews often surprise newer teams. Legal approvals for cookies and consent banners move on their own schedule. Pad time around these.
Pre migration discovery that pays dividends
Start with a full crawl of the current site, with rendering where needed. Capture URL inventory, canonical tags, titles, meta descriptions, hreflang, robots directives, structured data, internal links, pagination, and status codes. Add performance timing for key templates on both desktop and mobile. You are creating a baseline.
Pull your analytics and search data, segment by template types and intent layers. Revenue or lead value by path, assisted conversions, organic landing pages, and search queries. Identify the 10 percent of URLs that drive 80 percent of sessions or value. These are your red routes. Changes that affect them receive deeper scrutiny, earlier testing, and redundant checks.
Inventory backlinks for your top content and categories. Save copies of your most linked assets. If your top guide on cloud security has 3,000 referring domains, you treat that URL like a crown jewel, keep its slug, and maintain the first screen of content.
Finally, define what will change and what will not. If you can keep slugs stable across a replatform, do it. Stability reduces redirect complexity and preserves relevance signals. If you must change patterns, design rules early and document them.
URL mapping is not just find and replace
I have seen migrations where teams used regex to transform tens of thousands of URLs in minutes. The speed felt satisfying. The aftermath did not. Good mappings are both systematic and opinionated. You need rules, and you need exceptions.
Start with templated rules, like legacy /blog/yyyy/mm/title to /resources/title, but carve out high value pages that must keep their slugs or move to dedicated hubs. Use a mapping table that includes old URL, new URL, redirect type, canonical intent, and notes. Enforce one hop redirects. Two hops bleed crawl budget and increase the chance of loops and chains. If your CMS enforces trailing slashes or lowercase only, bake that into the mappings so you do not create duplicate routes.
Pay attention to query parameters. If your old site relied on parameters for filters, and the new site uses facet paths, map representative variants to the closest new canonical, and then block crawling of infinite combinations with robots rules or nofollow on non canonical links. For PPC and social, coordinate UTM handling so analytics attribution survives.
Redirect strategy at the edge
Redirects belong as close to the network edge as you can manage, not buried in application logic. Edge redirects remove dependencies on code deploys, reduce latency, and survive application failures. Use 301 for permanent moves. Reserve 302 for staging or limited time reroutes you plan to remove. Avoid meta refresh or JavaScript redirects, they waste crawl and underperform for users.
Test redirects both ways. Crawl old URLs to confirm they land once, with a 301 direct hit on the new destination. Then crawl the new site to see whether internal links still point at old routes. Every internal link that hits a redirect is self inflicted friction. Clean them in templates, navs, sitemaps, and footers.
CDNs sometimes cache 301 and 302 differently. Coordinate with your CDN team on TTLs and purge procedures. Document who can invalidate caches on launch day, and what fallbacks exist if the primary person is unavailable.
Content parity, cannibalization, and tone
Content parity does not mean copying every sentence into a new template. It means preserving the intent, coverage, and page level uniqueness that earned you rankings and links. When teams condense a 2,000 word product page into 500 words because a new design favors white space, conversion rates often dip. Search rankings can follow. Run controlled tests in lower traffic categories before rolling a pattern across your catalog.
Watch for cannibalization. New hubs, tags, and filters can create multiple pages targeting the same query space. Clarify canonical targets at the template level. If you introduce a resource hub for cloud security and already have a long running blog series on the same theme, consolidate or differentiate. A common approach is to build a canonical guide with tangible subtopics, and then link in depth posts as children with unique intents.
Tone shifts matter too. During a rebrand, marketing teams refine voice. Preserve key phrases that prospects and customers use, especially in headlines, h1s, and first paragraphs. Searchers write in their own language, not yours. Meet them there.
Technical SEO essentials
You can carry forward 90 percent of your SEO posture with habits that never make the press release. Keep self referencing canonicals on indexable pages. Use hreflang where it already exists, and do not expand it on launch day unless you have time to validate reciprocals and language codes. Retain pagination patterns users and spiders can follow. Strong internal linking beats complex XML for discovery, but sitemaps still matter. Generate new sitemaps tied to the new routes, keep file sizes under limits, and submit them in Search Console only after launch traffic begins to flow.
Handle robots.txt carefully. Stage environments often include Disallow rules and IP blocks. Before launch, audit the robots file that will deploy to production. Add a calendar hold to remove noindex headers, meta tags, and server level auth if they were used in staging. It sounds obvious, but the number of launches delayed by a single leftover noindex is larger than most admit.
For structured data, replicate what worked, and add enhancements only if they validate cleanly in staging with live like data. Schema can help, but half baked markup triggers alerts and diverts attention precisely when the team needs calm.
Analytics, tagging, and consent
Migrations break analytics more often than they break rankings. The causes are predictable. Changes to DOM structures break click tracking. SPA transitions alter pageview logic. Consent platforms change event timing. Tag Manager container snippets get lost in template refactors. Fix these before launch.
Decide whether you will preserve historical continuity by keeping the same GA4 property and measurement protocol, or start fresh. For most brands, continuity wins, but it demands careful event name mapping and parameter parity. Document the dozen or so events that drive real decisions, like form submissions, demo bookings, add to carts, and checkouts. Validate them in staging with live like traffic.
Cookie consent requires legal and UX design, not just a script. Test geography based behavior if you operate in multiple jurisdictions. Make sure autoconsent or cookie walls do not hide key CTAs unintentionally on small screens.
Performance and Core Web Vitals
A shiny redesign that adds blocking scripts, invisible carousels, and unoptimized media can erase hard won SEO gains. Measure Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint in staging on real devices. Favor server side rendering or at least HTML with meaningful placeholders over heavy client side hydration. Lazy load media below the fold, inline critical CSS, and delay non essential scripts.
I tend to budget for performance early, not late. Set thresholds for your heaviest templates, like PDPs and resource articles. If your pre migration LCP averaged 2.3 seconds on mobile, lock a target range and test designs and components against it. Explain to stakeholders that those 400 milliseconds can be the difference between a pass and a fail on lab tests, and that lab performance tracks conversion, not just rankings.
Internationalization, subdomains, and multiple markets
Global sites add complexity. When migrating multilingual or multi market properties, draw a clear map of language and region relationships. Keep language codes consistent, and avoid splitting a language across multiple top level domains without a strong reason. If you consolidate from ccTLDs to subdirectories, preserve dedicated sitemaps per market, and ensure hreflang points to the new routes with reciprocity.
Edge case, if you are moving a language from a subdomain to a directory, like de.example.com to example.com/de, watch for resource loading that still points to the old subdomain. Mixed resource origins create latency and CORS issues that are hard to debug under pressure.
Accessibility is not optional
A migration is a chance to improve accessibility. It also introduces risk. Alt text, heading hierarchies, focus management, and form labels often regress when templates change. Run audits with a screen reader and automated tools, but also with a human who relies on assistive tech. If your consent banner traps focus or your new mega menu is not navigable by keyboard, you will frustrate users and harm performance. Search engines notice when users bounce due to unusable interfaces.
Security, privacy, and legal reviews
SSL should be table stakes. Yet certificates expire, and redirects from http to https regress in the chaos of launch. Confirm HSTS policies, mixed content checks, and CSP settings. If you change cookie scope due to domain changes, update SameSite and Secure attributes. Legal teams should sign off on privacy policy updates required by new tracking or data processing.
Security teams often add headers in the load balancer or CDN layer. Coordinate to ensure those headers do not break scripts you need on launch day. Again, document who has keys to modify these settings if urgent changes are required.
Environments, data, and rehearsal
Staging parity saves launches. If staging uses different domains, ensure all absolute links resolve and do not leak into production. Sanitize data, but keep enough reality to test edge cases. For ecommerce, seed carts with combinations of variants, coupons, and shipping methods. For SaaS, test account states like trial, expired, and enterprise.
Run a dress rehearsal. Pick a slice of URLs, route them through the full redirect and caching layers, flip feature flags, and watch logs. A canary release teaches you where the surprises live. You learn whether DNS TTLs behave, whether your WAF blocks innocuous requests, and whether your build pipeline deploys the exact artifacts you expect.
The two checklists that keep you honest
Launches create adrenaline, and adrenaline degrades memory. Write down the smallest steps. Keep both checklists short, and empower someone to read them out loud in the war room.
Pre launch checklist:
- Redirect mappings covering 100 percent of legacy indexable URLs, with one hop only, validated by crawl Robots.txt, meta robots, and headers audited for noindex, with staging blocks removed and production file approved Analytics and event tracking validated in staging, with consent banner behavior tested in all target regions Sitemaps generated for new routes, with significant templates measured for Core Web Vitals against targets DNS, SSL, CDN and cache purge procedures documented, including who has access and a backout plan
Post launch checklist, first 48 hours:
- Compare live traffic and conversions by hour against a recent comparable period, segmented by channel and top landing pages Crawl a representative sample of old and new URLs to confirm redirect health, canonical tags, and internal links without redirect hops Monitor 404s and 5xx in server logs and Search Console, triage high volume patterns first Submit new sitemaps, fetch and render priority pages, and spot check indexation signals Track Core Web Vitals with RUM if available, and fix the obvious regressions quickly, such as uncompressed hero images or blocking scripts
Limit these lists to the essentials. Everything else belongs in runbooks and docs that specific owners execute.
Communication beats heroics
Treat the migration like a release train. Publish a plain language plan for marketing, sales, support, and executives. Set expectations that traffic may fluctuate for a few weeks, and that fluctuation does not equal failure if leading indicators look healthy. Share the backout criteria, for example, if critical checkout errors exceed a certain threshold for more than half an hour, we revert to the old stack.
Decide how you will update stakeholders on launch day, such as a dedicated channel with short, frequent notes. Avoid meeting pileups. A 10 minute standup every two hours is usually enough. When people understand the plan, they respect the process and stop peppering the team with side requests.
Monitoring that matters
Dashboards should show signal, not noise. During the first week, track organic sessions to your red routes, revenue or leads by hour, top error codes, and the ratio of branded to non branded queries. Watch crawl stats in Search Console, especially crawl requests by response code and purpose. If you see a spike in discovered, not indexed, audit your internal links and canonical tags, then re submit sitemaps.
Log level visibility helps. If you have access to raw logs, look for requests to legacy URLs that do not receive a 301, user agents that represent search engine crawlers getting throttled, and unusual spikes in 404s from specific referrers. Often, a single external link or partner integration drives a large share of bad traffic to old assets.
Recovery playbook for when traffic dips
Even careful migrations sometimes dip. If you lose more than 20 to 25 percent of non branded traffic after the first two weeks, pull the recovery plan.
First, verify technical basics. Status codes, redirects, canonicals, robots rules, and sitemaps. If all look clean, move to content and internal linking. Reinforce your canonical pages with fresh internal links from related content and high authority hubs. Update sitemaps to prioritize recently improved pages. Submit URL inspection for a sample of priority pages to nudge re crawling.
If a domain change is involved, expect a longer lag. Keep promoting the new domain through PR, newsletters, and partnerships. Update high value external links where you have relationships. If you trimmed content aggressively during a redesign, restore a subset of removed sections for your red routes, measure the impact, and then prune more deliberately over time.
Finally, check conversions. If you kept traffic but lost revenue, your issue is likely UX or tracking, not SEO. Heatmaps and session recordings can identify regressions in forms, CTAs, and navigation.
Tooling that speeds you up without blinding you
Use a crawler capable of JavaScript rendering where needed, and keep snapshots of pre and post launch crawls. Search Console remains the best single source for indexation signals. Pair it with log analysis or at least edge analytics from your CDN. For performance, integrate Lab tests in CI, and use RUM to capture field data after launch.
Simple scripts help too. A small script to validate one hop redirects across all legacy URLs has saved me days. Another script that compares title and h1 parity between old and new sites can prevent accidental keyword drift. Do not over automate novelty, automate the boring checks that you will forget at 2 a.m.
Common pitfalls I still see
Teams remove thin pages and expect rankings to consolidate, but the new topology starves related pages of internal links, so consolidation never occurs. Solve by maintaining navigational pathways and adding context links inside content.
Sitemaps go live too early with staging URLs, or too late after discovery has already lagged. Time them to the launch and sanity check the hostnames.
Everyone treats mobile and desktop the same, then wonders why mobile conversion rate fell despite similar traffic. Test mobile patterns, sticky CTAs, and input types.
Legal signs off on a consent banner that obscures the first heading on small screens. Your bounce rate rises on mobile organic. Adjust visual priority and placement.
A single third party script tanks your LCP on hero pages. Defer it, load it conditionally, or drop it. Your brand will not collapse without yet another slider.
Governance and ownership
The most useful document in a migration is a simple RACI. Who owns redirects, sitemaps, robots, analytics, DNS, CDN, and backouts. List names, not teams. Include backups. Post it where everyone can see it. When something breaks, you want a short path to the person who can fix it, not a scavenger hunt.
Post launch, assign stewardship for ongoing hygiene. Redirect files accrete cruft. Sitemaps drift. New content templates appear without SEO review. Create a cadence for audits every quarter. Make it someone’s job.
What a calm launch looks like
If you walked into a calm launch, you would see a war room with a small group, each with a narrow focus. The redirect owner runs the crawl diff and confirms matches. The analytics lead watches live events and revenue, and checks consent behavior. The SEO lead monitors indexing signals and fetches. The engineer with CDN access handles purges and header tweaks. The product owner communicates status upstream and makes the call when trade offs emerge.
There is chatter, but not panic. Someone notices a spike in 404s from a retired blog category. The mapping table missed a few slugs with special characters. The fix is small, the edge rules update in minutes, and the spike subsides. Traffic holds near forecast. The team leaves tired but intact.
That calm is not luck. It is the outcome of unglamorous preparation guided by experience. At (un)Common Logic, we joke that our best migration stories are boring. The charts slope gently, the dashboards stay green, and a month later you have to remind people that the biggest technical project of the quarter already happened.
If your next migration is on the horizon, treat this checklist like a contract with yourself. Clarify what you are changing and why, map your routes with care, put redirects at the edge, preserve the content that works, verify analytics before you ship, and rehearse. Do those, and you are in the quiet majority who ship with confidence and keep moving.