Ecommerce platform migration: a step-by-step checklist for B2B companies

What is an ecommerce platform migration, and what actually moves?

An ecommerce platform migration is the move of a live online store from one commerce platform to another, together with the five things the store depends on: its data, its integrations, its URLs, its checkout and payment flows and, for B2B sellers, its pricing rules. The same project is often called ecommerce replatforming.

The seven steps below cover the order of work in a migration, not the choice of software. For that choice, read custom or off-the-shelf and what a new store costs to build and run.

Step 1. Decide: whether to migrate at all, and when not to migrate

Do not migrate your ecommerce platform if a configuration change, a single app or one integration removes the blocker. A migration puts data, search traffic and customer logins at risk in the same project, so it has to buy something a smaller project cannot. Write the blocker down in one sentence, then compare it with the signals below.

If the only problem is cost, count before you move: our guide to when Shopify stops paying off shows a 24-month method that works for any platform. When the stay-and-simplify signals describe your store, the cheaper project is to simplify the store you already have. Staying on the current platform is a full result of Step 1, not a failure of it.

Step 2. Inventory: what your current store really does

The inventory for an ecommerce platform migration has five lists, and every line on them gets one decision: keep, simplify or drop. The inventory describes what the store does today, including undocumented workarounds, and it comes before the platform choice because the target is judged against it.

Data: products, variants, customers, orders and content

Export every data set of the current store and count it: products, variants, images, categories, customers, orders and content pages. For each data set, name the system that owns it. When the ERP owns prices and stock and the store only displays them, that data is an integration to rebuild, not a data set to migrate. Treat data quality, such as duplicates and missing attributes, as its own line of scope.

Integrations: ERP, payments, shipping, tax, email and analytics

List integration flows, not app names. An integration flow has a direction, a trigger and a frequency, for example “paid orders go from the store to the ERP”. For every flow, note what happens when it fails and who notices. The flow list is the scope of the ERP integration work on the new platform.

URLs: every address that earns traffic or links

Collect every URL of the current store into one file before anyone designs the new URL structure. Google’s site move documentation tells site owners to prepare a mapping from current URLs to new ones and names the sources: sitemaps, server logs or analytics, and the links report in Search Console. The same documentation says image and file URLs have to be moved like any other content.

Checkout and payment flows

Write every way an order gets placed and paid as a test scenario: payment and shipping methods, tax rules, payment on invoice with terms, repeat orders, discount codes and quote requests. A checkout scenario names the customer type, the cart and the expected result, and it becomes an acceptance test of the trial migration in Step 5.

B2B price lists, customer groups and terms

List every price list, customer group, volume discount, payment term, credit limit and approval rule, and note where each one is maintained. Customer-specific price lists are data to migrate and reconcile, not settings to retype by hand. Company accounts with several buyers go on the same list.

Customer logins need a decision in the inventory too. Shopify’s customer CSV file has no password column, and Shopify states that passwords from another online store cannot be migrated with a CSV, so imported customers are invited to create new ones. Password portability differs by platform, so check both platforms’ documentation in the audit.

Step 3. Target: choose the platform against the inventory, not a feature list

Score every inventory line against each candidate platform with one of four marks: native, configuration, extension or impossible. A feature list says what a platform can do in general. The scored inventory says what a platform costs for your store, because every “extension” is build or subscription money and every “impossible” is a process you have to change.

A SaaS platform is the better migration target when your sales process fits its standard model: mostly B2C, one price list and few integrations. Before choosing an enterprise SaaS plan, read what Shopify Plus costs a B2B company. A store you own is the better target when price lists, approvals or ERP rules score “impossible” or pile up as extensions.

Licences belong in the target budget. Medusa is one example: its core is open source under the MIT licence, while role-based access control (RBAC) and single sign-on (SSO) have been Enterprise Edition features since 11 August 2026. Our guide covers what Medusa.js is and what its licence covers.

Step 4. SEO protection: redirect map, URL parity and a baseline

SEO protection in an ecommerce platform migration means three deliverables finished before launch: a one-to-one redirect map, a parity check and a dated baseline. All three depend on the URL inventory from Step 2, which is why SEO work cannot start in the last week.

Build the redirect map from the URL inventory

A redirect map pairs every old URL with the one new URL that replaces it. Google’s site move documentation recommends server-side permanent redirects (301 or 308), advises against redirect chains, and warns against sending many old URLs to one irrelevant page such as the home page, which Google may treat as a soft 404. Google also advises keeping redirects for as long as possible, generally at least 1 year.

A permanent redirect signals to Google that the new URL should be the canonical one, and a temporary redirect does not, according to Google’s redirect documentation. Pages dropped on purpose should return a 404 or 410 response, not a redirect to an unrelated page.

Shopify stores have an extra redirect decision. Shopify serves products and collections under the fixed paths /products and /collections, so a store leaving Shopify either keeps those paths on the new platform or redirects every one of them. A store moving onto Shopify can redirect only from URLs that no longer load a page, up to 100,000 URL redirects, or 20,000,000 on the Plus plan (source, as of 2026-10).

Keep URL parity where you can

URL parity means the new store keeps the paths, titles, meta descriptions, canonical tags, structured data, hreflang annotations, content and internal links of the old store wherever nothing forces a change. Google’s guidance for site moves is to change one thing at a time. A migration that changes platform, URLs, content and design in one release leaves no way to tell which change cost the traffic.

What to measure before and after the migration

Export a migration baseline before launch and read the same reports after it. A baseline is a dated export, not a memory of how the store used to perform.

Expect movement in search after an ecommerce platform migration. Google’s site move documentation says visibility may fluctuate temporarily during a move, and that a small to medium-sized site can take a few weeks for most pages to move to their new URLs, with larger sites taking longer. A baseline does not prevent a drop in traffic, but it shows whether the drop is normal fluctuation or a broken redirect.

Step 5. Trial migration: rehearse on a copy of real data

A trial migration is a full run of the data move on a copy of production data, repeated until the results match the source. A trial migration has six parts:

1. Map fields from the old data model to the new one, and clean the data that Step 2 flagged.
2. Run the full migration on a copy, with production volumes.
3. Reconcile counts of products, variants, customers, orders and price list lines.
4. Replay real orders on the new store and compare totals, tax and shipping.
5. Check prices as B2B customers: log in as sample accounts from each customer group.
6. Test integrations in the ERP’s and the payment provider’s test environments, including the paths where something fails.

Stop rehearsing when a trial migration finishes with no open differences. Each run also shows how long the final run takes, which sets the length of the change freeze in Step 6.

Step 6. Cutover: big bang, phased or a parallel run

A cutover has three options, and the right one depends on how much risk a single launch day carries for your sales.

For search, Google recommends moving all URLs of a small or medium site at the same time and allows large sites to move one section at a time, according to its site move documentation. Google also suggests timing a move for a period of lower traffic.

Every cutover runbook needs four things. A change freeze stops edits to products, prices and content on the old store. A final delta migration moves the orders and customers created since the last trial run. A rollback plan names the trigger, for example failed payments or a broken ERP sync, and the person who decides. The old store stays read-only until the rollback window closes.

Step 7. Day 1 to day 30: watch the first month after launch

The first 30 days after a migration launch are an observation window in which someone compares the new store with the baseline on a schedule. The 30 days are our convention, not an external rule: they cover the few weeks that, according to Google, most pages of a small or medium site need to move, and one monthly B2B invoicing cycle.

In the first week after a migration launch, check four things every day: orders in the store against orders in the ERP, not-found errors in the server logs, checkout completion per payment method, and customer messages about prices or logins. From the second week, compare indexing, organic traffic and conversion with the baseline weekly. The same Google documentation notes that Google crawls a site more heavily than usual after a move, so watch server capacity as well.

What goes wrong in an ecommerce migration?

Ecommerce migrations go wrong in a few repeatable ways, and each has an early signal you can look for before launch.

1. Old workarounds rebuilt one to one. Signal: nothing in the inventory is marked “drop” or “simplify”.
2. The redirect map made in the last week. Signal: the new URL structure is approved before the old URL list exists.
3. A B2B customer sees a different price than yesterday. Signal: prices were tested as an administrator, never as a logged-in customer.
4. Integrations tested only on the path without errors. Signal: nobody knows what happens to an order when the ERP is unavailable.
5. Customers cannot log in. Signal: the account activation email was never sent to a test group.
6. Order history is missing. Signal: customer service was not asked before it was cut from scope.
7. Analytics change together with the platform. Signal: no baseline export exists.
8. No rollback plan. Signal: the old store’s subscription or hosting ends on launch day.
9. Migration, redesign and a new ERP in one project. Signal: three projects share one launch date.

Ecommerce migration checklist: seven gates from decision to day 30

The ecommerce migration checklist below, which some teams call an ecommerce replatforming checklist, has seven gates, and a gate is closed only when its evidence exists as a file, a report or a recorded decision. Owners are roles, not names.

The redirect period in the last row comes from Google’s site move documentation.

How we run a platform migration at Evelumo

Evelumo has not published a migration case study yet, so here are the principles we work by, not results. Our ecommerce migration services move stores to Medusa.js, and the first conversation is about whether a migration is needed at all. A trial migration on a copy of your data comes before anything touches production, the redirect map is built together with the data model, and ERP, payments and shipping are tested on the new store before cutover day.

The store we can point to on Medusa is Alufix, a store built on Medusa.js with a Next.js storefront: a catalog, product variants, a cart and a checkout for consumers and companies. Alufix shows the scope of a Medusa store our team designed and built. Alufix is not a migration case study.

A new store on our foundation launches in 30 days, from €10,000 net, with our live e-commerce in 30 days offer. The 30 days and the price cover the new store. Moving data, redirects and integrations from an existing store is scoped and quoted separately, at a fixed price, after an audit of that store. Hosting and maintenance start from €100 net a month.