Ecommerce Replatforming Without Losing the Traffic
Replatforms lose organic revenue for a reason that has little to do with how good the new site is. The new platform generates its own URL structure, so most of your URLs change, and every URL that moves without a deliberate redirect takes its rankings and its inbound links with it.
This page covers what actually breaks when a catalog changes platforms, the checks that catch a drop before it costs you, and where the work is different depending on which platform you are leaving.
Why replatforms lose traffic when rebuilds do not
A redesign usually keeps its URLs. A replatform almost never does. Category paths, product paths, filter and facet parameters, pagination, and media URLs are all generated by the platform, so moving platforms rewrites them wholesale. On a catalog of any size that is not a list of exceptions, it is close to every URL you have.
Redirecting a single moved page is straightforward. A replatform is the case where most of your addresses change at once and every one of them has to resolve correctly on the first request. Ten broken URLs is an afternoon of work. A thousand needs its own owner and a repeatable process. Fifty thousand is large enough to shape the schedule of the whole project.
Scale is also why the work gets deferred. Redirect mapping is tedious, so it tends to slide toward the end of the schedule and get compressed into the week before launch, when there is no time left to act on what it uncovers. Starting while the URL structure is still being decided is what keeps the findings useful, because at that point they can still change the build.
Two things make this worse than it sounds:
What breaks, by platform pair
The mapping effort is not driven by catalog size alone. It is driven by how far apart the two URL structures are.
This is the hardest common case. Magento category nesting and URL suffixes have no direct Shopify equivalent, and Shopify enforces its own path prefixes for products and collections. Layered navigation URLs that accumulated links over the years generally cannot be reproduced at all, so they need a deliberate destination rather than a pattern rule.
Typically an enterprise catalog with long-lived URLs, heavy faceting, and locale or site-ID segments in the path. The mapping is less about product URLs, which are usually tractable, and more about deciding what happens to the very large tail of parameterized and localized URLs that search engines have indexed.
More forgiving, because the structures are closer and much of the catalog maps with pattern rules. The risk concentrates in blog and content URLs, which are frequently treated as an afterthought in an ecommerce migration despite often holding the strongest link profile on the domain.
The Shopify constraint worth knowing before you plan
Shopify's native URL redirects are one to one. There is no wildcard, and no pattern matching. A rule that would be a single line in an Apache config or a Cloudflare redirect rule becomes one row per URL in Shopify.
On a small catalog that is a detail. On a large one it changes the plan: the redirect file has to be generated programmatically and imported in bulk, which means the URL inventory and the mapping logic have to be clean enough to automate. A Shopify Plus agency we worked with generated 27,000 redirects for a single migration on exactly this basis. The specifics of what Shopify accepts, and what silently fails, are in our tested guide to Shopify URL redirects. If you genuinely need pattern rules, they belong in a layer in front of Shopify, such as your CDN or edge proxy.
Pre and post launch checks that actually catch a drop
These are the checks that find real problems, split by when they have to happen. Each one is specific enough to actually run, and to fail.
- A complete URL inventory built from crawl, analytics, Search Console, and server logs, not from the CMS export alone.
- That inventory reconciled against the new sitemap, so you can name every URL that has no destination.
- The redirect map tested against real response codes on staging, not reviewed as a spreadsheet.
- Staging confirmed blocked from indexing, and the removal of that block written into the launch runbook.
- A rollback plan that someone has actually read.
- Live redirect verification on real URLs, including the ones that were meant to be exceptions.
- The staging index block confirmed removed, on launch day, by request rather than by memory.
- Index coverage and crawl stats monitored for a full crawl cycle, not a week.
- Traffic and revenue compared at template level, so a collapsing page type is visible under flat totals.
- Server logs checked to confirm crawlers are reaching the new URLs and not looping through redirect chains.
Where the AI channel changes the calculation
Replatforming now carries a risk that did not exist a few years ago. AI crawlers such as GPTBot, ClaudeBot, and PerplexityBot read your pages on their own schedule to build what models know about your brand, and mid-conversation fetches pull live pages to answer questions. None of that traffic runs JavaScript, so none of it appears in GA4 or your platform's analytics.
The practical consequence: a migration can break AI visibility without showing anything in the reports the team is watching. If the new URLs are unreachable or the redirects chain badly, the models keep answering from what they learned about your old pages until they recrawl. Server-level capture is the only place that behavior is visible, which is why we monitor it through AI Channel Analytics across a cutover.
How WISLR works on a replatform
We come in on the SEO and redirect workstream, alongside whichever agency or internal team is doing the build. The engagement is usually three phases: mapping before the URL structure is locked, verification through launch week, and monitoring across the recrawl window when the real result becomes visible.
If you want to scope the work yourself first, the replatform planner will generate the sequence for your specific platform pair, catalog size, and timeline, and the launch window risk tool will tell you what a bad week costs in the month you are aiming at.
Replatforming this year?
If you are moving off Magento or Salesforce Commerce Cloud, we can tell you quickly whether your mapping plan holds up at your catalog size. The earlier that happens, the more of what we find can still change the build.
Talk to us about your migration