The reason most businesses stay on legacy sites longer than they should isn't inertia — it's fear. The last migration was painful. Or someone told them it would be. The site is generating revenue, it mostly works, and the cost of breaking something seems higher than the cost of staying put. That calculation is usually wrong, but it's understandable.
What makes migrations painful is almost never what people expect. It's rarely the platform change itself. It's the things nobody inventoried before starting: the hidden pages that got indexed and still drive traffic, the forms that go to an email address nobody manages anymore, the integrations that were duct-taped together five years ago and work in ways nobody fully understands. Here's how to find all of that before launch day.
The inventory phase: knowing what you actually have
Before any migration work begins, you need a complete picture of the site you're leaving. Crawl it with a tool like Screaming Frog and export every URL. Cross-reference that against your analytics data to find which pages get real traffic. You'll almost always find pages that are indexed and visited that don't appear in the CMS sitemap — old blog posts, campaign landing pages, PDF downloads, event pages from three years ago.
Every URL that gets meaningful traffic needs a redirect decision. The options are: redirect it to the closest equivalent on the new site, recreate the page, or accept the traffic loss. The third option is sometimes right — some old content genuinely isn't worth carrying forward — but it should be a deliberate decision, not an oversight. Unplanned 404s after migration are the main source of SEO damage and they're completely preventable.
- Full crawl of the existing site before any work starts — every URL, every status code
- Analytics overlay: which pages get traffic, which get conversions, which are truly dead
- Inventory of all forms, integrations, and third-party scripts on the current site
- Identify all backlinks to the domain — these inform redirect priority decisions
- Document every URL that will change, and map it to its destination on the new site
Content migration: what to carry over and what to leave behind
Not all content migrates automatically, and not all content should. A migration is a good opportunity to audit what you actually have: content that's outdated, redundant, or below your current quality standard doesn't need to come along. Fewer, better pages generally outperform a larger site with a wide quality range, both for SEO and for the experience of visitors who find them.
For content that does migrate, the format often changes. What lived as a page in one CMS may need to be restructured for a different one. Images need to be re-exported or re-optimized. Metadata — page titles, meta descriptions, alt text — should be reviewed, not copied blindly. This is also where you find content that was good but never had proper SEO treatment applied, and where a migration can become an upgrade rather than just a transfer.
A migration is the only moment where you have legitimate reason to touch every piece of content on the site. Use it.
The redirect strategy: protecting your SEO equity
Redirects are the mechanism by which your accumulated SEO authority transfers to the new site. A proper 301 redirect tells search engines that a URL has permanently moved, and that the ranking signals associated with the old URL should be attributed to the new one. Doing this correctly takes time and attention — but skipping it means starting the new site's SEO from scratch, which no business wants.
The redirect map should be built from the URL inventory before the new site is launched, not added reactively after you notice traffic dropping. Large sites may have hundreds of redirects to configure. The redirect logic for a platform migration (say, from Squarespace to a custom Next.js build) needs to be implemented at the server or CDN level, not through client-side JavaScript, to work correctly for search crawlers.
- 301 redirects for all URLs that have meaningful traffic or backlinks
- Redirect chains should be collapsed — A → B → C should become A → C directly
- Validate every redirect before go-live using an automated check against the URL map
- Resubmit the XML sitemap to Google Search Console immediately after launch
- Monitor for 404 errors in Search Console for at least sixty days post-launch
Launch day and the first thirty days
Go-live should not be a surprise for anyone. Internal teams need to know the date so they can update any email signatures, business listings, or marketing materials that reference specific URLs. Support teams need to know what's changed so they're not blindsided by questions about functionality that moved or disappeared.
The thirty days after launch are when you discover what you missed. Build in capacity to respond to it rather than hoping it won't happen. Monitor Search Console daily for crawl errors and index coverage changes. Check analytics for unexpected traffic drops to specific sections. Have a staging environment still available so you can verify fixes before deploying them to production. A migration that lands cleanly after three weeks of active monitoring is a success. Most of the time, that's exactly how it goes.