The ecommerce replatforming checklist: what to settle before, during and after moving day.

An ecommerce replatforming checklist lists every decision, export, mapping and test that has to be done, and signed off by a named owner, before a store moves to a new platform, plus the checks that run for a month after launch. The table below is the whole checklist. The sections after it explain each item and link the vendor rule behind it.

This ecommerce platform migration checklist is for merchants moving between Shopify, BigCommerce, WooCommerce, Adobe Commerce, Magento Open Source and headless builds. The checklists we read for this topic stop at choosing a platform or at launch day. The expensive failures arrive later: old URLs that answer 404, customers locked out of their accounts, saved cards left behind, a sync that drops orders without an error, and answer engines that can no longer reach the store.

Last reviewed October 19, 2026. Every vendor rule below links the vendor's own page. For how we run these steps ourselves, see our ecommerce migration services.

The ecommerce replatforming checklist at a glance#

The checklist runs in nine phases, from the contract to the first month after launch. Every item has an owner, a stage of the project and a done-when test: the evidence that closes it. Owners are roles, not names, so the table fits an in-house team or an agency alike. Where a row cites a source, the rule comes from that vendor's own page, and the Sources list below dates each one.

Three readings stand out. The rows due before you sign are the cheapest to settle and the most expensive to skip: export rights, redirect limits and the integration inventory can each change which platform makes sense. Accounts and payments hold the items customers notice first, because a lost login or a missing card shows up at checkout. And the last phase runs for a month after launch, because that's when the 404s, the card declines and the missing AI citations surface.

Copy the rows into your own tracker; the table works as an ecommerce migration checklist on its own.

Before you sign: should you replatform at all?#

Good e-commerce platform migration planning starts with a memo, not a demo. Write the problem down in a paragraph: a checkout you can't change, B2B pricing the platform can't express, a version that stopped getting security fixes, a bill that grows faster than the store. Then list every option, including the two nobody pitches: upgrade in place, or replace the one extension that hurts. A replatform should beat both on paper before anyone books a demo.

Three inputs settle most memos:

• Requirements and gaps. List what the store must do on day one (catalog structure, customer-specific pricing, quotes, multi-store, checkout rules, integrations) and mark each one native, app, custom or missing on every platform you're weighing. The missing column decides more than the feature list does.
• Total cost of ownership. Compare staying and moving over the same number of years: plan or license, apps and extensions, hosting, payment fees, the build and the upkeep after it. Our guide to what an ecommerce website costs collects the market's published figures with their sources. For a Magento store weighing a stay, the Magento cost guide does the same, layer by layer.
• Who sits on your side of the table. Vendors demo their platform on its best day. Someone who has run several platforms should sit with you before the shortlist, which is the job of a fractional head of ecommerce.

If the memo says stay and the store runs an older Magento 2 release, an upgrade in place keeps its URLs and data where they are. If it says move, the build is ecommerce development work, and the rest of this checklist keeps the move from costing you customers.

Your data: export rights, inventory and field mapping#

Start with ownership. Before you sign the new contract, read the data-export and notice terms in the current platform's and agency's agreements: the format the data leaves in, who holds the database and the code, and how much notice a handover needs. Those terms are cheap to learn before signature and expensive to learn in cutover week.

Then take a full export and write down what it leaves out:

• Shopify. Order exports above 50 orders arrive by email, "Authorization data isn't included in your exported transaction history", and the discount codes skip automatic discounts. The customer export has no password column.
• Adobe Commerce and Magento Open Source. Self-hosted installs (Magento Open Source, Adobe Commerce on-premises) keep the database in your hands; on Adobe's hosted offerings, read the export terms as you would on any hosted platform. Adobe's Data Migration Tool leaves four kinds of data for manual migration: media, storefront design, admin user accounts, and access control lists, which means re-creating the "credentials for web service APIs (SOAP, XML-RPC, and REST)" by hand. As of October 19, 2026, the tool's newest release is 2.4.8.1, a hotfix for 2.4.8, and there is no 2.4.9 release, so a Magento 1 move lands on 2.4.8 and upgrades from there.
• WooCommerce. Products export to CSV; customers and orders come out through the REST API, as our WooCommerce migration notes explain.

The field map comes next, and it's a signed document, not a spreadsheet tab nobody owns. Every source field gets a destination or a written reason it's dropped, and the merchandising lead signs it before the first staging import. Shopify's customer CSV shows why it matters: it has columns for one address, the default address, plus email, SMS and WhatsApp consent columns, so extra addresses need another route and marketing consent gets mapped, not guessed. The file must be 15 MB or smaller, so a large customer list goes in as several files.

Import in the order the target documents. Shopify's is products, then customers, then historical orders, so each order finds its products and its customer. Switch off staff new-order notifications first, or everyone who gets them "will receive a new order email for each imported order".

Then reconcile before anyone signs off: count each entity on both stores (products, variants, categories, customers, orders, reviews, gift cards) and reconcile order totals and tax. A green import log proves the job ran, not that the data arrived. Our migration page lists the reconciliation checks we run before a cutover goes ahead.

URL inventory and the redirect map#

Google's site-move guide comes down to four rules for redirects:

1. Map every old URL. "It's important to map your old site's URLs to the URLs for the new site."
2. Redirect on the server, permanently. Google recommends "a permanent server-side redirect whenever possible" in its redirects guide, where 301 and 308 both count as permanent. A JavaScript redirect is one Google "might never see" if rendering fails.
3. Keep them. "Keep the redirects for as long as possible, generally at least 1 year."
4. No catch-all. "Don't redirect many old URLs to one irrelevant single URL destination, such as the home page of the new site." Google may treat those as soft 404s.

The inventory is the slow part. Old URLs live in sitemaps, server logs, analytics, Search Console, backlink reports and a crawl of the old store, and the ones that appear only in logs and backlinks are the ones a migration tool never sees. The result you need: one row per old URL, one destination per row, every row tested on staging before launch day. We publish how we map and test redirects, step by step. Our record: tens of thousands of redirects mapped for a zero-downtime replatform.

Then check the map against the platform you're moving to:

• Shopify. A redirect fires "only from broken URLs": if anything still loads at the old path, it does nothing, while hidden and draft products return 404 and so qualify (URL redirects). As of October 19, 2026, the cap is 100,000 redirects below Plus and 20,000,000 on Plus. URLs with query strings "might not work as expected", which bites faceted URLs from Magento or WooCommerce, and /products, /collections and /collections/all can't be redirected. Shopify's migration guide has you set redirects up before the domain transfer.
• BigCommerce. It creates 301s by itself "only for storefront channels", when a storefront URL changes inside BigCommerce. URLs from another platform go in as your own map, through the Redirects API.
• Adobe Commerce (on-premises or on Cloud) and Magento Open Source. Rewrites live under Marketing > SEO & Search > URL Rewrites, typed "Permanent (301)" or "Temporary (302)" (Adobe); use Permanent. With automatic redirects on, a changed product URL key needs no manual rewrite, but URLs from your old platform need rewrites of their own.
• WooCommerce. WordPress core only rescues slugs WordPress itself changed: wp_old_slug_redirect runs on a 404 and skips hierarchical post types. URLs from another platform need rules you add on the server or in code.
• Headless Next.js. The storefront code owns redirects, canonicals and markup, so they ship and get tested like any release. Keep every permanent redirect a 301 or 308. Our headless commerce page covers when that trade pays off.

That's why the redirect-limits row sits in the before-you-sign phase: a catalog with a long URL history can outgrow a cap, and a plan picked before the count is picked blind.

Customer accounts and passwords: what survives each move#

Passwords are where a replatform reaches every returning customer at once. What survives depends on the route:

• Onto Shopify. Shopify states that "you can't migrate customer passwords from another online store using a CSV" (importing customers). On its customer accounts, sign-in is passwordless by default: customers "enter their email address and receive a one-time 6-digit verification code", and "A password isn't required to sign in" (sign-in options). Our Magento to Shopify migration page covers that route end to end.
• Shopify Plus with your own identity provider. The exception: Plus can replace Shopify's sign-in with an OpenID Connect provider of your choosing. Whether old passwords survive then depends on what that provider can import, so prove it with real accounts on staging.
• Magento 1 to Magento 2. Most passwords survive: Adobe's Data Migration Tool carries the hashes across, and Magento 2 upgrades each one at the customer's next storefront sign-in. Two exceptions: passwords last set on Magento 1.9.4.3 or 1.9.4.4 are bcrypt or SHA-512 hashes that only the tool's login plugin can check, and hashes in any other format, which some third-party extensions write, won't validate, so those customers reset. Getting from 2.4.8 to the current release is a Magento upgrade.
• Onto WooCommerce. WordPress's check_password filter lets a login plugin accept an old store's hash the first time a customer signs in. WordPress itself has hashed passwords with bcrypt by default since version 6.8.
• Onto BigCommerce. We found no documented way to import password hashes into BigCommerce, so plan a reset.
• Off Shopify. The customer export has no password column, so every customer sets a new password on the new platform.

Two items close this phase. First, staging proves the plan: sign in with test accounts of every hash type before anyone tells a customer their password still works. Second, the customer email is written and approved in cutover week. It says what changed and why, how to sign in now (a reset link or a one-time code) and where to get help. Send it once the new store is live, so every link in it works. Our migration page covers passwords, order history and gift cards route by route.

Payments, saved cards, subscriptions, gift cards and tax#

Saved cards never travel in your export files. Either the old processor transfers them to the new one, under a request the account owner makes, or the new platform attaches them by their gateway identifiers. Stripe's data migration docs put the first route plainly: "Never send sensitive credit card details or customer information directly to Stripe," and you "must complete a Data migration request before you migrate."

On that route, the old processor sets the pace. "Many processors require the account owner to request a data transfer", the previous processor "might take a few days or several weeks to transfer the final data to Stripe", and Stripe "typically imports data within 10 business days of receiving the correct data". Until the import completes, existing customers are still charged on the old processor, and "If customers update their payment information with your previous processor in the window between transferring the data and completing the import, those changes are lost."

The second route runs on Shopify: cards stored in a gateway such as Stripe, Authorize.Net or Braintree can be attached to customers by their gateway identifiers through customerPaymentMethodRemoteCreate, which needs the write_customers and write_customer_payment_methods scopes. Subscriptions renew on those stored cards, so the card plan and the subscription plan are one plan, agreed with both providers before the first staging import: which route the cards take, which provider charges each renewal, from which date, and what happens to a card that didn't move.

Three more items move as data, and each gets reconciled:

• Gift cards. Shopify's gift card input takes an initial amount, so each card can be recreated with its remaining balance. A code you supply must be 8 to 20 characters, letters and numbers only, so old codes outside that rule get new ones, and their owners get told.
• Store credit. Export each customer's balance, recreate it, and reconcile the total against the old store.
• Tax exemptions. Shopify's customer CSV has a Tax Exempt column where "you can enter only yes or no". Certificate numbers and region-specific exemptions need a home of their own, and test orders prove the rates in every region you collect in.

Two rules finish the phase. A new payment page needs a new script inventory: PCI DSS requirements 6.4.3 and 11.6.1 "focus on ensuring that payment page scripts are properly authorized, checked for integrity, and monitored for tampering", along with "security-impacting HTTP headers", in the words of the PCI Security Standards Council. Build that list from the new page, not the old one. And anyone moving onto Shopify Plus rebuilds checkout customizations as Shopify Functions: "As of June 30, 2026, Shopify Scripts has been deprecated," and any Scripts still published "have been deactivated and no longer work" (Shopify).

Integrations and the ERP cutover#

Every system connected to the old store has to learn a new address, a new data model and new credentials. Build the inventory before you sign, because it changes which platform fits: the ERP that owns prices, the warehouse that owns stock, tax and shipping engines, payment gateways, marketplace listings, and distributor and product feeds. For each connection, record what it sends, in which direction, how often, and what breaks when it stops.

Then rebuild each one against the new platform with keys of its own. On a Magento move, Adobe's tool leaves access control lists, API credentials included, for manual migration, so every integration gets a new key anyway. Make that the rule on every platform: nothing on the new store runs on a credential copied from the old one.

The ERP cutover is a sequence, not a switch:

• Run the rebuilt sync beside the old one, on the same orders, stock and prices.
• Compare the outputs record by record, and write down every difference you accept.
• Decide which system holds the truth during the content freeze, so the ERP doesn't overwrite a price someone just corrected.
• On launch day, point Merchant Center and marketplace feeds at the new product URLs, so shoppers land on the final page, not a redirect.

That sequence is the core of our ERP integration work. B2B stores add company accounts, customer-specific price lists and quotes to the inventory, and our B2B ecommerce page covers what trade buyers expect to find on the new platform.

The SEO baseline: measure before you move#

Replatforming SEO starts before the move, with numbers to compare against after it. Google tells site owners to expect temporary fluctuation during a move (more on that under the first 30 days), so without a baseline nobody can tell a dip from a loss.

Save four things before the first staging import:

• Search Console. Search Console keeps a limited history; export it before the move. Many reports have an export button for both the chart and the table. The Search Console API "exposes a maximum of 50K rows of data per day per search type", so on a large catalog it cuts off the longest tail. Pull it one day at a time, per search type, and page through each day 25,000 rows at a time, as Google's guide shows.
• Analytics. On standard GA4 properties, event data retention is 2 or 14 months, and "The data retention setting only affects explorations and funnel reports" (Analytics Help). Standard reports are unaffected; explorations reach back only as far as the setting. Export the explorations your baseline relies on.
• A crawl of the old store. Every URL with its status code, title, canonical, structured data and internal links. The launch-day crawl gets checked against it.
• The pages that earn the most. Top pages by revenue and by inbound links. They head the redirect test list and the post-launch watch list.

The new sitemaps belong here too, because a sitemap is a claim about what changed. Google "uses the <lastmod> value if it's consistently and verifiably (for example by comparing to the last modification of the page) accurate", and it "ignores <priority> and <changefreq> values" (sitemap guide). One sitemap holds at most 50,000 URLs or 50MB uncompressed. Set lastmod from each page's last significant update, and don't spend time tuning tags Google ignores.

Ecommerce replatforming SEO goes past redirects: content and internal-link parity, structured data, and the Search Console watch after launch. Our ecommerce SEO team covers both sides of the move.

AI search visibility through a replatform#

AI search visibility, which the industry calls GEO or AEO, rests on three things a move can break without one error in the new admin: whether answer engines can reach the new store, whether they can read it, and whether the URLs they already cite still lead somewhere. We treat it as part of our SEO and AI search work, and six checks carry it through a replatform.

Allow the AI search crawlers#

AI companies run separate agents for training, for search and for fetches a user asks for. Blocking a training token such as GPTBot, ClaudeBot, Google-Extended or Applebot-Extended keeps your pages out of training (and, for Google-Extended, out of Gemini's grounding). It doesn't remove the store from that company's search answers. Blocking the search agent does.

• OpenAI. GPTBot crawls content "that may be used in training our generative AI foundation models". OAI-SearchBot "is used to surface websites in search results in ChatGPT's search features", and sites that opt out don't appear in ChatGPT search answers, though they can still show as navigational links. ChatGPT-User makes visits a user asks for, and robots.txt rules may not apply to it (OpenAI).
• Anthropic. ClaudeBot collects training data. Blocking Claude-SearchBot "may reduce your site's visibility and accuracy in user search results", and the bots respect robots.txt (Anthropic).
• Perplexity. PerplexityBot surfaces and links sites in results and isn't used for training; allow it "To ensure your site appears in search results". Perplexity-User fetches for users, and "this fetcher generally ignores robots.txt rules" (Perplexity).
• Google. Googlebot covers Google Search, AI Overviews and AI Mode included. Google-Extended governs Gemini training and grounding, and "does not impact a site's inclusion in Google Search nor is it used as a ranking signal in Google Search" (Google).
• Apple. Applebot powers Spotlight, Siri and Safari search. "Applebot-Extended does not crawl webpages", and pages that disallow it "can still be included in search results" (Apple).
• Microsoft. Bingbot is "Microsoft's web crawler used for indexing websites for Bing Search", as Vercel's verified-bot directory describes it.

Our recommendation: allow every search agent and every user-triggered fetcher, and make the training tokens a business decision, taken once and in writing by whoever owns the content. Since user-triggered fetchers may ignore it, robots.txt is no privacy control.

Check the new host's bot settings, not just robots.txt#

The CDN or host in front of the new store can turn an agent away before robots.txt is read, and the store's admin shows nothing.

• Cloudflare announced on July 1, 2025 that it was "changing the default to block AI crawlers unless they pay creators for their content" (Cloudflare). Check the AI bot policy on the zone the new store uses, under Security Settings > Configure AI bot policies, where "Allow (do not block)" lets agents through (Cloudflare docs).
• Vercel's bot protection "automatically excludes verified bots, such as Google's crawler", and lists OAI-SearchBot and PerplexityBot as verified. Its separate AI bots ruleset covers bots that crawl "for training data, search purposes, or user-generated fetches", and as of October 19, 2026, "The ruleset is inactive by default" (Vercel). Set it to deny, and the search and user agents go with the trainers.
• Shopify "generates a default robots.txt file that works for most stores", and a robots.txt.liquid template can change it, though the "rendered template output doesn't always match Shopify's generated file exactly" (Shopify). Before you publish a custom template, save a copy of the live /robots.txt, as Shopify advises, and compare the rendered file with it after every change.

To test, request robots.txt and a product page with each agent's user-agent string from outside your network, then read the firewall or bot log. A user-agent test checks your rules, not the real crawler, so the log has the last word. OpenAI and Perplexity publish IP lists for allow rules, such as openai.com/searchbot.json and perplexity.com/perplexitybot.json.

Carry the structured data over#

New templates mean new structured data. Carry over Organization, BreadcrumbList and Product with its offers. For merchant listings, Google requires name, image, offers, price and priceCurrency, and recommends availability, shippingDetails and hasMerchantReturnPolicy (merchant listings). FAQ markup belongs only on questions the page shows: "Don't mark up content that is not visible to readers of the page," and "Your structured data must be a true representation of the page content" (structured data guidelines).

Validate the markup on staging, template by template, before cutover, and compare it with what each page shows. A price in the markup that differs from the price on the page is a mismatch to fix, not a rounding error.

Redirect the URLs that AI answers cite#

An AI answer that cites your store links a specific URL, and after the move the redirect is the only bridge an old citation has to the new page. Take the URLs that AI answers cite today from your baseline and put them at the top of the redirect test list, beside the top pages by revenue and links. Point each redirect straight at the canonical URL. Google's redirects guide says temporary redirects aren't used "as a signal that the redirect target should be canonical", so a permanent redirect to the canonical page keeps every signal pointing one way.

Sitemap, IndexNow and llms.txt on day one#

On launch day, three things tell crawlers and agents about the new store:

• The sitemap. Bing says sitemaps "remain a foundational signal for ensuring comprehensive URL coverage across your site", that lastmod "should reflect the true last modification time of the page content, not the sitemap file itself", and that "Optional sitemap tags like changefreq and priority are ignored by Bing" (Bing). Submit the new sitemap in Search Console and Bing Webmaster Tools.
• IndexNow. Bing pairs sitemaps with IndexNow. One POST takes up to 10,000 URLs, and "submitted URLs will be automatically shared with all other participating search engines". A 202 means the key is still being validated, not that the URLs were refused, and a 200 "only indicates that the search engine has received your URL" (IndexNow). The key file sits at the site root unless keyLocation names another spot on the host, so recreate it on the new host.
• llms.txt. "A proposal to standardise on using an /llms.txt file to provide information to help agents use a website" (llmstxt.org). It's optional, and its H1 is the only required section. Google's guidance, quoted below, says its AI features need no such file. If you publish one, our own llms.txt file is a worked example: a summary, then one line per page, each with its date.

Record an AI citation baseline, then re-check it#

The AI baseline is manual, and cheap. Before the move:

• Run the brand query and each top product's buying question in ChatGPT search, Perplexity, Copilot and Google's AI Mode.
• Record the date, the answer, whether the store is cited, and which URL.
• Run each query three times, because answers vary from run to run, and screenshot every run.

Repeat the same queries in the first 30 days after launch and compare them citation by citation. A citation that now points at the new URL is the result you want. One that vanished sends you to the host's bot rules, the redirect map and the markup, in that order.

Google's guidance sets the bar: "You don't need to create new machine readable files, AI text files, or markup to appear in these features," and a page has to be "indexed and eligible to be shown in Google Search with a snippet" (Google). No one can promise a citation. This phase exists so the move doesn't cost you the ones you have.

Cutover and rollback#

Cutover week is the staging rehearsal, run once for real. Four items carry it:

• Content freeze. Catalog, price and content edits stop on the old store; orders don't. Adobe's Magento migration guide draws the same line: "Do not make changes in the Magento 1 Admin, except for order management" (Adobe). Tell everyone with admin access, apps and agencies included.
• Delta sync. Everything that changed since the main import (orders, customers, stock, reviews) moves across in a final pass, and the counts get reconciled again.
• DNS. Lower the TTL on the records you're moving well before the switch. Resolvers keep the old value for as long as the old TTL allows, so lowering it on the day doesn't speed up the switch. On Shopify, set up the redirects before you transfer the domain, and disconnect the domain from the old platform first to avoid SSL certificate errors (Shopify).
• Change of Address. Only for a domain change. "You only need this tool when moving from one domain or subdomain to another," says Google. A same-domain replatform skips it.

The rollback plan is written and signed before launch day, and it settles three things:

• What triggers it. Conditions you can check, set in advance: checkout failures, payment errors, a stalled sync, old URLs that don't resolve.
• Who calls it. One role, with a named deputy, known to everyone on the launch call.
• Where orders go. How orders placed on the new store reach fulfillment, the ERP and the customer if you roll back mid-day.

On launch day, place a test order through every payment method and refund it, then crawl every old URL against the live site and compare the results with the map. Our migration page shows how we cut over without stopping sales.

The first 30 days after launch#

The first month is when the problems that passed every test show up. Google sets the expectation: "Expect temporary fluctuation in site ranking during the move," and "a small to medium-sized website can take a few weeks for most pages to move, and larger sites take longer" (Google). The watch list:

• Search Console. New 404s and crawl errors, daily at first. Warnings on the old sitemap are expected: "Search Console may show warnings for the sitemap that contains the old URLs," and Google calls them normal. Don't clear them by deleting redirects.
• The baseline pages. Positions, clicks and revenue for the pages on your baseline list, each against its own history.
• Redirects. They stay "for as long as possible, generally at least 1 year". Record them as permanent infrastructure, not launch scaffolding.
• Imported cards. Watch renewal declines on migrated cards and pace the retries: retrying numerous cards "(such as after a migration) can appear suspicious to issuers", per Stripe. Then confirm the old processor "canceled all automatic billing of your customers".
• Syncs and orders. Daily reconciliation between the store, the ERP and fulfillment, until it comes back clean day after day.
• AI answers. Re-run the baseline queries, three runs each, and log every citation against the old list.

When the numbers settle, the last row of the ecommerce replatforming checklist is done, and so is the move.

Replatforming checklist questions

Sources