eCommerce Platform Migration: How To Replatform Without Losing Revenue

An eCommerce platform migration starts as a software project, but the risk is rarely just software. The real risk is losing the map that already tells customers, search engines, ad platforms, analytics tools, and internal teams where revenue lives.

Every valuable page and keyword has to have a verified home on the new site and a verified redirect to get people there. That rule should sit above the theme, the app list, the import tool, and the launch calendar.

The most damaging migration failures usually come from that map breaking. A store can look better, run faster, and still lose money if hundreds or thousands of product and category URLs fall out of Google’s index, redirect to the wrong place, or resolve as soft 404s. OuterBox has seen a site launch without redirects and lose 80% of revenue. That is not a benchmark to expect. It is the kind of preventable failure that makes redirect planning the spine of the whole migration.

This guide treats an eCommerce platform migration as an SEO-first operating plan. Development, catalog data, analytics, paid media, merchandising, and customer communication all matter, but they need to attach to the redirect, canonical, category, and facet map before launch.

What An eCommerce Platform Migration Really Changes

An eCommerce platform migration, or replatforming project, moves a store from one commerce system to another. That might mean a move from a custom platform to Shopify Plus, from Magento or Adobe Commerce to BigCommerce, from WooCommerce to a more managed commerce stack, or from a legacy homegrown build to NetSuite SuiteCommerce or a headless architecture.

The visible change is the new storefront. The deeper change is the system of records behind the storefront:

• Product data, variants, attributes, inventory, pricing, and category relationships.
• Customer, order, review, subscription, loyalty, tax, and shipping data.
• URL structure, redirects, canonicals, breadcrumbs, internal links, XML sitemaps, and robots rules.
• Product structured data, Merchant Center feeds, ad pixels, email/SMS events, GA4, Search Console, and server-side tracking.
• Checkout, payment, fraud, fulfillment, ERP, PIM, CRM, and customer-service workflows.

That is why a migration is not the same as a redesign. A redesign can change presentation. A platform migration changes the machinery that supports traffic, orders, reporting, merchandising, and marketing.

Google’s site move guidance is blunt about the search side: map old URLs to new URLs, update internal links and canonicals, use server-side permanent redirects where possible, avoid redirect chains, submit new sitemaps, and monitor the move. For eCommerce, that same discipline has to extend into catalog data, feeds, checkout, and analytics because those systems decide whether the new store can still sell.

When Replatforming Is Worth The Risk

Replatforming is worth considering when the current platform is holding back the business in ways maintenance cannot fix. Common triggers include slow development cycles, unstable extensions, poor checkout flexibility, weak B2B capabilities, international limits, difficult merchandising, fragile integrations, or platform costs that keep rising without improving the customer experience.

It is not worth doing just because the current store looks dated. If the problem is mostly design, navigation, page templates, page speed, or merchandising, a focused eCommerce web design or web development project may solve the issue with less risk. If rankings, crawl paths, and revenue-page structure are the main concern, pull eCommerce SEO into the decision before platform requirements harden.

A platform migration deserves the higher-risk path when the old platform cannot support the business model. Examples include a growing catalog that needs better attribute management, a B2B buyer portal that needs contract pricing and account permissions, a checkout that cannot support modern payment and shipping rules, or a marketing team that cannot test and publish without developer bottlenecks.

Do not frame the decision as “new platform good, old platform bad.” Ask whether the current platform can support the next 3 to 5 years of catalog, checkout, SEO, analytics, paid media, and operations requirements without constant workarounds. If not, build the migration around the revenue the current platform already has.

Build The SEO-First Migration Map Before Development Runs Ahead

The safest migration plan starts with the old site’s revenue and search footprint. Before development gets too far, create a map that answers one question for every valuable URL and keyword: where does this live on the new site, and how will users and crawlers get there?

That map should start with exports from GA4, Google Search Console, crawl data, server logs if available, backlink tools, paid landing-page reports, and the current XML sitemaps. Pull the pages that already bring traffic, revenue, assisted conversions, backlinks, impressions, or paid spend. Include category pages, product pages, buying guides, brand pages, collection pages, filtered pages that are intentionally indexable, and old content that still earns links.

Then classify each URL:

• Preserve: the same page type exists on the new site and needs a one-to-one destination.
• Consolidate: several weak or duplicate pages should point to a stronger new page.
• Replace: the old intent still matters, but the destination needs new copy, taxonomy, or template logic.
• Retire: the page has no value, no replacement, and no reason to keep ranking.
• Investigate: the page appears in GSC, logs, backlinks, or old sitemaps but not in the CMS export.

The last bucket is where many eCommerce migrations break. Large stores often have old faceted URLs, parameter pages, discontinued product URLs, image URLs, manufacturer pages, PDF spec sheets, blog URLs, or legacy mobile URLs that never show up in a neat product export. They can still hold rankings, links, or revenue paths.

For high-value pages, redirect planning is not a spreadsheet afterthought. It is a launch dependency.

Use A Five-Ledger Migration Map

A checklist can help, but a migration needs something stronger than a task list. Build five ledgers and make each one reconcile before launch.

The value of this model is that it forces each team to work from the same source of truth. The SEO team cannot approve launch if the URL map is unfinished. Development cannot treat product import as done if variant attributes broke the category filters. Paid media cannot relaunch campaigns if Merchant Center is rejecting products. Analytics cannot call the project clean if orders fire without revenue data.

Start With The Redirect And URL Plan

Redirects are the part of an eCommerce platform migration that people underestimate until the revenue graph proves otherwise.

The goal is not to redirect every old URL to the homepage or the nearest parent category. The goal is to preserve intent. A product URL should point to the same product when possible. If the product is discontinued, it should point to the best replacement, the parent category, or a helpful alternative page depending on demand and user expectations. A category URL should point to the new matching category, not a generic shop page. A buying guide should point to the new version of that guide or a closely matched resource.

For stores with hundreds or thousands of URLs, build the redirect map in layers:

1. Priority pages with traffic, revenue, rankings, paid spend, and backlinks.
2. Indexable category, subcategory, brand, and collection pages.
3. Product URLs with sales history, backlinks, or impressions.
4. Content, guide, blog, comparison, and support URLs.
5. Legacy parameter, filtered, m-dot, HTTP, trailing-slash, uppercase, and historical platform URL patterns.

Google recommends server-side permanent redirects where possible, updated internal links, updated canonicals, and avoiding redirect chains during a URL-changing site move. In practice, that means your QA should test both the spreadsheet logic and the deployed behavior. A redirect map that looks correct in Excel can still fail through cache rules, regex order, app limitations, duplicate paths, uppercase/lowercase mismatches, or old sitemap jobs.

If the redirect map has not been crawled, the migration is not ready.

Move Catalog Data With Its Business Context Intact

Catalog migration is more than moving products. A CSV import can make the new admin look full while still losing the relationships that make the store usable.

Before migration, identify which product fields are operational, which are merchandising fields, and which are search signals. Titles, handles, SKUs, variants, options, attributes, categories, price rules, inventory states, image alt text, product descriptions, review counts, schema fields, and related-product logic may come from different systems. If those fields land in the wrong place, the store can pass a quick visual check and still fail customers.

This is especially important for stores with:

• Thousands of products with technical specifications.
• Configurable products, kits, bundles, subscriptions, or personalization.
• B2B account pricing, quote workflows, or approval rules.
• Product variants that create separate URLs or canonical conflicts.
• Filter and facet systems that can generate indexable pages.
• Reviews, Q&A, and user-generated content that support conversion and organic visibility.

The anonymized Boat/RV case study shows why this work matters. OuterBox helped a boat and RV accessories retailer switch platforms while preserving historical product, customer, and order data. The project also included a 301 redirect module, AJAX product filtering, Smart Search, checkout redesign, SEO, and CRO work. The published case study reports 244% organic traffic growth and 196% organic revenue growth from the broader program, with checkout integration contributing a 103% conversion lift.

The lesson is not that a platform migration alone creates those results. The lesson is that data import, redirects, filtering, search, checkout, and SEO have to work together.

Preserve The Search Signals That Help Google Understand The Store

When the new platform goes live, Google has to understand what changed and what stayed the same. The more signals you change at once, the more disciplined the migration needs to be. This is where technical SEO belongs in the build, not as a post-launch cleanup task.

Preserve or deliberately rebuild:

• Title tags and meta descriptions for valuable pages.
• Canonical rules for products, variants, categories, and filtered pages.
• Product, BreadcrumbList, and Organization structured data.
• XML sitemap rules and sitemap index files.
• Robots.txt and noindex rules, especially if staging rules were used.
• Internal links in navigation, category copy, related products, blog content, and breadcrumbs.
• Category descriptions and buying-guide content that helped pages rank.
• Product image URLs or redirects where image search and shopping surfaces matter.

Google’s Product structured data guidance explains that merchants can provide product information through structured data, Merchant Center feeds, or both. That matters during migration because product data inconsistencies can create search and shopping issues even when the storefront appears normal.

For example, a product page may render the right title and image but lose review markup, availability, brand, GTIN, shipping, return, or variant details. A category page may load products with JavaScript that search engines can render eventually, but the initial crawl may not expose the same internal links and content as the old platform. A canonical template may accidentally point product variants to the wrong parent. A faceted page that used to rank may disappear because the new filter system blocks or canonicalizes it differently.

These are not polish issues. They are how the new platform tells search engines what each page is and why it deserves to keep ranking.

Reconnect Feeds, Analytics, Ads, And Lifecycle Marketing

An eCommerce platform migration can look successful on launch day and still break the systems that bring buyers back.

Merchant Center is one of the first places to check. Google’s checkout requirements and best practices call for consistency across feed data, landing pages, and checkout details such as currency, shipping, and product availability. If the feed says one thing, the product page says another, and checkout calculates a third result, ads can underperform or products can be disapproved.

Google Shopping campaign management, email, SMS, analytics, and affiliate tracking need the same attention. Test the events that matter before launch and after launch:

• Product view.
• Add to cart.
• Begin checkout.
• Purchase with revenue, tax, shipping, coupon, and item data.
• Lead or quote request for B2B stores.
• Account creation.
• Email/SMS signup.
• Product feed refresh.
• Remarketing audience membership.

Do not assume that a tag container surviving the migration means measurement survived. Platform changes can alter data layers, checkout domains, payment redirects, consent behavior, server-side events, and order confirmation pages.

Before launch, run test orders by payment type, shipping method, coupon state, customer type, and product type. After launch, compare platform orders against GA4, ad platforms, Merchant Center, CRM, ERP, and email/SMS events. A dedicated analytics owner should reconcile each mismatch.

Launch Outside The Danger Window And Test Like Revenue Depends On It

The launch date should respect the store’s revenue calendar. Avoid peak selling periods, major promotions, inventory drops, and seasonal windows where a bad migration would be hardest to recover from.

Most eCommerce teams need some type of code freeze before launch. That does not mean nothing changes. It means the launch candidate becomes stable enough for crawl QA, redirect QA, checkout QA, feed QA, analytics QA, and stakeholder review. If the redirect map, checkout, product import, or analytics events are still changing daily, the store is not in a launch candidate state.

Run a staging crawl before launch and compare it against the old crawl. Look for:

• Important pages missing from the new site.
• Noindex tags left over from staging.
• Canonicals pointing to staging, old URLs, or wrong templates.
• 404s, redirect chains, loops, and soft 404s.
• Missing title tags or duplicated metadata.
• Broken breadcrumbs and internal links.
• Missing category copy.
• Product structured data errors.
• Product pages blocked by robots rules.
• JavaScript-rendered content that changes crawl visibility.

Wine Enthusiast is the clearest OuterBox example of why this coordination matters. WineExpress.com moved from a homegrown platform to NetSuite SuiteCommerce Advanced while also moving to HTTPS, converting from m-dot to responsive, and overhauling architecture. The work included search-demand-informed architecture, URL mapping, redirect planning, optimized content, XML sitemaps, metadata, robots.txt, canonicals, breadcrumbs, user-generated reviews, QA, and post-launch support. The published Wine Enthusiast platform migration case study reports a 59% organic traffic lift, 60% organic revenue lift, and 12% increase in total ranking keywords from that multi-component project.

Again, the point is not that every migration grows immediately. The point is that SEO, development, UX, catalog data, and QA cannot operate as separate launch lanes.

Monitor The First 90 Days With Owners And Thresholds

The work does not end when the DNS changes or the new platform starts taking orders. The first 90 days should have owners, dashboards, and thresholds.

Track daily during the first week:

• Orders and revenue by channel.
• 404s and redirect failures.
• Checkout errors.
• Search Console crawl and indexing signals.
• Merchant Center diagnostics.
• Paid campaign landing-page and feed issues.
• GA4 event and revenue parity.
• Top category and product organic sessions.
• Server errors and page speed problems.

Track weekly after the first week:

• Organic traffic and revenue by page type.
• Ranking movement for priority categories and content.
• Indexed pages and excluded pages.
• Redirect hits and high-volume old URLs.
• Product disapprovals and feed warnings.
• Conversion rate by device and channel.
• Top internal-search terms and no-result searches.

Set thresholds before launch. For example, decide who responds if organic revenue drops beyond a defined percentage, if Merchant Center disapprovals spike, if checkout errors exceed a set number, or if a priority category falls out of the index. Without thresholds, everyone watches the dashboard and nobody owns the fix.

The 90-day window is also when you clean up what the launch could not fully predict. Some old URLs will surface from backlinks, emails, browser bookmarks, old XML sitemaps, or third-party systems. Some products will expose edge-case variant or inventory behavior. Some templates will need metadata or internal-link improvements once crawl data comes in.

Post-launch monitoring is part of the migration.

Build The Migration Around The Pages That Already Earn Revenue

A new platform should make the store easier to run and easier to grow. It should not erase the page-level equity the old store already built.

Start with the redirect, canonical, category, and facet map. Attach catalog data, development, feeds, analytics, checkout, paid media, and communication to that map. Keep the valuable pages visible, give every important keyword a relevant destination, and verify the redirects before launch.

That is how an eCommerce platform migration moves from a risky platform change to a controlled revenue-preservation project.