There are millions of ways to do a website migration wrong. There is really only one way to do it right. I've been involved in over a hundred of them — directly hands-on or overseeing and supervising — and that number hasn't changed the fundamental truth of it one bit.
The platforms have varied enormously. Shopify to Visualsoft. Visualsoft to Shopify. WordPress to Magento. Magento back to WordPress. Then Wix. Then WooCommerce with various integrations and fiddly bits. Drupal. A few other things that don't have neat names. You name it, I've been through it — and in almost every case, the technical platform was never really the issue.
The house move analogy is the most useful one I've found. You're not starting again — you're relocating. The furniture still needs to fit, the post still needs to arrive, and the neighbours (in this case, Google) still need to know where you've gone. Skip any of those steps and you'll be dealing with the consequences long after moving day.
What actually goes wrong
Most migration problems fall into a handful of categories that repeat themselves regardless of platform. Redirects that aren't mapped — or mapped incorrectly, sending link equity into loops or dead ends. Content that doesn't make it across at all. Canonical tags that point at the wrong version of a page. Noindex directives applied too broadly in the rush to get things live. Tracking that breaks at launch and leaves you blind to what's happening for weeks afterwards.
That last one is particularly damaging. If you can't see what's happening in GA4 and GSC immediately after launch, you can't distinguish between normal post-migration turbulence and an actual problem. By the time the data starts looking wrong, weeks may have passed and the damage is compounding.
Platform migrations are rarely planned far enough in advance. Whether it's a commercial decision, a contract ending or a platform that no longer fits the business, the trigger usually arrives before the preparation does. The temptation is to move fast — to get onto a new platform as quickly as possible and worry about the SEO implications afterwards. That instinct is understandable and almost always costly.
The one thing that matters above everything else
Redirect mapping. Every single URL that exists on the old site needs to be mapped to its equivalent on the new one before a single page goes live. Not afterwards. Not mostly. Every one.
This sounds obvious. It is obvious. And it still gets skipped, rushed or handed to someone without the context to do it properly on almost every migration I've seen go wrong. The redirect map is the removal van. Without it, your organic equity — built over months or years — stays at the old address while your new site sits empty.
URL slugs — decide before you build
One thing that often gets missed until it's too late: URL slugs on the new platform need to be decided before the build starts, not after. They're determined by how products, categories and content are set up in the backend — and once the site is live, changing them creates a whole new redirect mapping problem.
On a Wiggle migration I worked on, this was a significant decision point early in the process. The product taxonomy in the new backend directly determined what the URLs would look like. Get that right at the start and the redirect map is clean. Get it wrong and you're mapping to URLs that will themselves need changing again.
Content needs a home — the right one
Content structure is its own migration challenge and deserves its own conversation. You can't put the lounge furniture in the bathroom. Moving content from one platform to another isn't just a copy-paste exercise — it's a chance to audit what exists, where it lives, whether it's in the right place, and whether it's doing the job it was built to do.
Content that made sense in the old architecture may not map cleanly to the new one. Categories that worked in one platform's taxonomy may need rethinking entirely. This is the opportunity — not the obstacle. A migration done properly is also a content audit, a structural review and a chance to fix things that were wrong on the old site but never got addressed.
Beyond redirects and content: tracking needs to be confirmed working before launch, not checked afterwards. Crawls need to be run on both the old site before migration and the new site immediately after. GSC needs to be monitoring from day one.
Recovery is possible — but it takes time
If a migration has already gone wrong, the situation is recoverable. I've worked through the aftermath of several — including cases where the damage wasn't discovered for months. Recovery requires the same methodical approach as the migration should have had in the first place: crawl the current state, identify what's broken, map and implement fixes in priority order, monitor through the recovery period.
What it doesn't require is panic or a complete rebuild. The organic equity is usually still there — it's just been misrouted or obscured. The work is finding it and pointing it in the right direction.
If you're facing a platform migration or dealing with the aftermath of one that didn't go as planned, the Archaeology page has more detail on what migration and recovery work actually involves — or get in touch directly.