Website Migrations: What Happens Before the Switch

This is Part 1 of a two-part series on how we approach migrations. Here, we cover everything that happens before launch: why businesses migrate, why it's risky, and the preparation work that makes the difference. Part 2 will pick up the moment the site goes live.

“The biggest mistake businesses make is thinking a migration is just a launch task. The important work happens before anything goes live. If SEO is only brought in at the end, you’re usually managing risk that could have been avoided weeks or months earlier.” 

- Daniel Emery, Senior SEO Specialist

There's rarely one single reason. Usually it's a few pressures that have been building for a while, and eventually the case for moving becomes impossible to ignore. The most common triggers we see:

The current setup just can't keep up. Maybe the product catalogue has grown beyond what the platform can handle, integrations are held together with duct tape, or licensing costs have quietly crept up to the point where moving makes financial sense. Magento to Shopify is a classic one, which we worked on with Cake Decorating Central. The appeal of a cleaner, more manageable platform is real, but the URL structure changes significantly in the move, and that's where things get tricky from an SEO perspective.

This one catches businesses off guard more than any other. What starts as a visual refresh turns into a restructured navigation, rewritten URLs, consolidated pages, and an overhauled information architecture. If we're not involved early, those decisions get made without any understanding of their SEO implications, and we end up untangling the mess afterward.

A URL is more than just an address. It carries years of accumulated signals, like backlinks from other sites, crawl history, ranking associations, and internal link equity. When that URL changes and search engines can't follow the trail to the new location, that equity disappears. It doesn't transfer automatically, and it doesn't wait for you to catch up.

The most common thing we hear from clients coming into a migration is "we'll just set up redirects". Redirects are essential, but they're one piece of a much larger puzzle. Get them wrong through chains, loops, missing mappings, or incorrect implementation, and you can send search engines in circles or lose the connection between old and new entirely.

Baby Bunting found this out the hard way when they launched a new ecommerce site in 2019. They ran into serious technical problems, and were forced to roll back to the old site in November of that year. In the weeks before the rollback, online sales growth had slumped to 7% year on year. In the four weeks after returning to the old site, it recovered to 21%. The CEO called it "a distraction to the business" in a call with investors. The additional cost in customer support alone ran into hundreds of thousands of dollars. And the relaunch? Pushed back by close to a year, because there are only a handful of windows in the retail calendar where a migration can happen without disrupting peak trading.

What typically goes wrong when a migration isn't properly managed: pages drop out of the index, rankings fall, backlinks point to dead URLs, internal linking breaks down, and tracking goes dark at exactly the moment you need it most.

That risk scales with the size of the change, not the size of the site. Moving from WordPress to a headless CMS carries significantly more risk than a redesign on the same platform. The more that changes, including URL structure, platform, domain, and content architecture, the more there is to protect.

"Redirects matter, but they’re not the migration strategy. You need to understand which URLs carry rankings, backlinks, traffic, internal link equity, and indexation value before you decide what moves, what changes, and what gets consolidated.

It’s also not just about which pages are added or removed. A migration can change the wider information architecture, internal linking, and page relationships in ways that affect the visibility of content that technically hasn’t changed at all."

- Daniel Emery, Senior SEO Specialist

The ideal scenario: a client tells us they're planning a migration, and we're in the room before any technical decisions have been made. That gives us an opportunity to review the proposed URL structure before it's built, flag issues in the information architecture while they're still easy to fix, and make sure SEO requirements are baked into the development brief from the start. Those are the projects that go smoothly.

The reality is that we're often brought in later than that. Sometimes mid-build. Sometimes the week before launch, when there's no room to make meaningful structural changes and we're focused entirely on limiting the damage. And sometimes after the fact, when a business has already migrated and is trying to work out why traffic has dropped. Even in these cases, we have enough experience to dive in and get to work, fast.

Migrations are never just an SEO task. The work touches developers, designers, content teams, and the client's own internal stakeholders, and all of them need to be across the same priorities. When they're not, things fall apart in the gaps between teams.

We've seen it happen: a developer makes a routing decision without realising it affects canonical logic, a designer restructures the navigation without knowing it breaks the internal linking strategy, a content team migrates pages without understanding which ones carry the most SEO equity. None of these people are doing anything wrong individually. They just didn't have the full picture.

That's why we run regular WIPs with the full project team from the start: SEO, developers, designers, and the client together. It's the only way to make sure decisions get made with all the right information.

What we need from a client to run a migration well is access to all relevant systems from day one, a realistic timeline with proper staging milestones, and a point of contact who can make decisions when priorities conflict...Because they will.

The Chemist Warehouse migration is a good example of what this coordination looks like at scale. An 18-month transition from legacy systems to a modern composable commerce stack built on Commercetools, one of the largest ecommerce platform migrations in Australia. We were embedded directly alongside the development partner with weekly syncs across both teams, making sure SEO requirements were built into every technical decision as it was made, not bolted on afterward. Zero disruption to organic traffic through the entire transition.

This is where most of the work lives, and where the quality of the outcome is largely determined. It's also the element most clients don't see, which is part of why migrations go wrong when businesses try to manage them without specialist SEO involvement.

"A good migration should feel boring from the outside. Rankings hold, traffic stays stable, tracking works, and there’s no scramble after launch. That only happens when the planning is detailed enough that most problems are caught in staging, not discovered in Google after the site is live."

- Daniel Emery, Senior SEO Specialist

The most important principle in migration work: nothing goes live without SEO sign-off.

Not as a formality. As a genuine gate. We work through every item on the checklist, confirm it's been implemented correctly in staging, and only then give the green light. The alternative, launching and fixing issues afterward, sounds pragmatic. In practice, it means ranking losses are already happening while you're still diagnosing the problem.

Search engines move fast. A site can lose significant ground in the days between launch and identifying what went wrong. The time spent on pre-launch review is always cheaper than the recovery work that follows a migration that went live before it was ready.

The preparation work is extensive, deliberate, and non-negotiable. But it's only half the story.

The moment a site goes live, a different kind of work begins: monitoring, validation, and fast response to anything that doesn't go to plan. In Part 2, we cover what we're watching for immediately after launch, what goes wrong even in well-prepared migrations, and why the post-migration period needs just as much attention as everything that came before it.