An ecommerce migration carries a kind of risk that a typical content-site migration doesn't. On a blog or a marketing site, a lost ranking during a migration means lost traffic — frustrating, but recoverable over time. On an ecommerce site, the pages at stake are often actively converting and generating revenue right now, so a broken redirect or a dropped ranking during migration isn't just a traffic problem. It's lost sales, starting the day it happens, and compounding for every day the issue goes unnoticed.
That distinction changes how an ecommerce migration should be planned. Prioritisation can't be based on site structure, page count, or which pages happen to be easiest to migrate first — it has to be based on which pages actually make the business money. This checklist walks through how to identify those pages, handle the ecommerce-specific edge cases that content-site checklists don't cover, and monitor the metric that matters most: revenue, not just rankings.
Prioritise by revenue, not by convenience or alphabetical order. Your highest-revenue product and category pages should get the most rigorous redirect mapping and manual QA — treating every page with equal priority wastes limited migration-window attention on pages that don't matter as much.
Identify Your Highest-Value Pages First
Before any migration work begins, export traffic and revenue data ranked by page from your analytics platform. Pull at least 12 months of data if seasonality affects your catalogue, and rank every product and category page by the revenue it has actually generated — not by traffic alone, since a high-traffic page with a poor conversion rate may matter less than a lower-traffic page that converts exceptionally well.
This ranked list — not the site's navigation structure or file organisation — should determine which pages get the most careful redirect mapping, manual testing, and post-launch monitoring. Your top 20-50 revenue-driving pages deserve individual attention: manually verify their redirect, their content, their schema markup, and their internal linking on the new platform before launch, rather than trusting a bulk redirect rule to have handled them correctly.
Handling Discontinued and Out-of-Season Products
Every ecommerce catalogue has products that won't exist on the new platform — discontinued lines, seasonal items, or SKUs that have simply been retired. Decide in advance where each of these should redirect: to a close alternative product, to the parent category, or to a deliberate 410 if there's no real equivalent and the page has negligible existing traffic. What you should avoid is letting these default to the homepage simply because the migration is moving fast and nobody made an explicit decision.
This deserves the same care it would get outside of a migration context — the decision framework for out-of-stock and discontinued pages doesn't change just because a platform move happens to be underway at the same time. If anything, migrations are when this framework matters most, because the volume of pages needing a decision is much higher than it would be in day-to-day catalogue management, and it's easy to let dozens of edge cases slip through unreviewed.
Reviews and User-Generated Content
Reviews frequently don't migrate automatically between platforms, especially when moving between systems that store review data in incompatible formats or use different third-party review apps entirely. Losing them can mean losing more than social proof — it can mean losing the review-rich snippets that were driving click-through rate in search results, which is a ranking-adjacent loss that doesn't show up directly in a rankings report but shows up clearly in organic CTR.
Plan a dedicated review migration process as part of the project scope from the start, or budget realistic time to rebuild review volume on high-value pages after launch, rather than discovering this gap after the new site is already live. Check early whether your review platform offers a native export/import path to the new system, since this is far easier to solve before development than to patch afterward.
Category and Filter Page Structure
Faceted and filtered URLs — size, colour, price-range, and other attribute combinations — often change entirely during a platform move, sometimes disappearing altogether or being restructured with a completely different URL pattern on the new platform. Trying to map every one of these individually is rarely worth the effort.
Prioritise redirecting canonical category pages correctly, since these are usually the actual entry points for browsing traffic and hold the bulk of any accumulated ranking value. Don't attempt to redirect every filter combination one by one — most filtered URLs carry minimal independent ranking value on their own, and the time spent mapping them individually is better spent on manual QA for your top revenue pages instead.
Post-Migration Revenue Monitoring
Track revenue per top page, not just traffic, for at least 4-6 weeks after migration. A page can retain its traffic and even its ranking position while conversion quietly drops, if something on the new platform — page speed, a changed checkout flow, missing trust signals like reviews or security badges — shifted in ways that don't show up in a standard rankings report. Rankings tell you whether Google still trusts the page; revenue tells you whether customers still trust it.
Confirm GA4 ecommerce tracking is correctly reconfigured on the new platform immediately at launch, ideally as part of pre-launch QA rather than after. Revenue attribution breaking silently — purchase events firing incorrectly, or not firing at all — is one of the most common post-migration blind spots, and it can mask real problems for weeks if nobody is actively checking that the numbers reconcile with the payment processor.
| Page Type | Migration Priority | Key Risk |
|---|---|---|
| Top-revenue product pages | Highest — manual QA on every one | Direct, immediate revenue loss if broken |
| Category/collection pages | High — redirect to closest equivalent | Passes authority to browsing entry points |
| Discontinued products | Medium — deliberate redirect decision per product | Defaulting to homepage looks like a soft 404 |
| Filtered/faceted URLs | Low — redirect canonical versions only | Low individual value, not worth full mapping effort |
Common Mistakes
- Treating every product page as equal priority regardless of actual revenue contribution, which spreads limited QA time too thin across pages that don't matter equally.
- Forgetting that reviews need a dedicated migration plan. Review data is often the first thing lost and the last thing noticed.
- Redirecting every filter combination instead of focusing effort on canonical category URLs, which wastes time that should go toward higher-impact pages.
- Not verifying GA4 ecommerce tracking survived the platform change, leaving revenue attribution broken and invisible for weeks after launch.