Replatforming Migration Checklist: Before, During, and After Launch

This is a working checklist for a commerce replatform, ordered by phase. Each item names a task and the evidence that it is finished; if you cannot point to that evidence, the item is not done. For why these projects go wrong and how to frame one, read our replatforming playbook. If you are still choosing what to move to, start with the composable vs. monolithic decision guide.

The short answer

Measure before you move. A baseline captured on the old site is the only way to prove the new one is better, or to catch it quickly when it is not.
Treat URLs, data, and integrations as scope. Redirects, SEO metadata, and connected systems belong in the plan from day one, with owners and acceptance checks.
Plan the month after launch. Budget people and time for the first 30 days, when real traffic finds what testing missed.

Before you commit

Everything after launch is judged against what you capture here, so do this before you sign with a vendor or agency.

List the business outcomes the new platform must deliver, each with a metric and an owner, and get the list signed off before build work starts.
Save a dated baseline report of traffic, conversion rate, average order value, and revenue by channel and device from the current site.
Record Core Web Vitals (LCP, INP, and CLS) at the 75th percentile for mobile and desktop on your home, category, product, cart, and checkout templates.
Export every live URL from your sitemaps, server logs, CMS, and analytics into one inventory, including images and files that rank or are linked to.
List every integration (ERP, tax, reviews, email, search, payments, shipping) with its owner, its data direction, and how it will connect to the new platform.
Inventory the data to move (products and variants, customers, orders, reviews, content) with record counts you can reconcile against later.
Mark what you will not move, such as retired products, dead content, and unused apps, and record that decision next to each row in the inventory.

Build and migrate

This is where search equity and operations are kept or lost. Treat redirects, metadata, and tracking as build scope with owners, not launch-week cleanup.

Map every URL in the inventory to its final new URL until no row is blank and no destination is itself a redirect.
Implement the map as server-side permanent redirects (301 or 308) that go straight to the final page, without chains, meta refresh, or JavaScript redirects.
Carry over titles, meta descriptions, headings, structured data, and image alt text for every page that keeps its role, and spot-check a sample against the old site.
Give each new page a self-referencing canonical tag and point internal links, navigation, and any hreflang annotations at the new URLs.
Run trial data migrations and reconcile product, customer, order, and review counts against the inventory until they match or every gap is explained.
Connect each integration in staging and push one real transaction through it end to end, such as an order, a tax calculation, or an ERP sync.
Rebuild analytics and marketing tags to match the old setup event for event: page views, add to cart, each checkout step, and purchase.

Pre-launch testing

Test the journeys that make money and the URLs that bring traffic. A green test plan should be the condition for setting a launch date, not the other way round.

Crawl the staging site and confirm there are no broken links, no unintended noindex rules, and no pages missing a title or canonical.
Request every old URL in the redirect map and confirm each returns one permanent redirect to a page that loads.
Place test orders for every payment method, shipping method, discount type, and tax case, and confirm each one reaches fulfillment and finance.
Run the same journeys on the old site and on staging and confirm analytics records the same events, with none missing or counted twice.
Measure Core Web Vitals on the key templates against your baseline, and fix any regression or have its owner accept it in writing.
Walk the main journeys (browse, search, add to cart, checkout, account) on mobile and desktop, including keyboard-only and screen reader checks.
Write a rollback plan with a named decision maker and a clear trigger, and rehearse it once in staging.

Cutover

Launch day should be a rehearsed sequence, not an event. Keep it short, staffed, and boring.

Choose a launch window outside your peak trading periods and freeze catalog and content changes on the old site for the cutover.
Run a final delta migration of orders, customers, and inventory created since the last trial and reconcile the counts.
Remove any noindex rules or robots.txt blocks that were only there for development as soon as the new site is live.
Switch DNS or routing, then check your top URLs by traffic and revenue, and their redirects, from outside your own network.
Submit the new sitemap in Search Console and, if the domain changed, file a Change of Address request from the verified old property.
Keep development, merchandising, and customer service on call through launch day with a single channel for reporting issues.

First 30 days after launch

Real customers find what testing missed. Plan this month with people and budget, and compare everything with the baseline you captured at the start.

Check Search Console daily for crawl errors and not-found pages, and add a redirect for any old URL that appears there.
Compare traffic, conversion rate, and revenue with the baseline every week by channel and device, judging trends rather than single days.
Compare Core Web Vitals field data with the baseline as it comes in and fix the slowest templates first.
Reconcile orders across the platform, ERP, and finance daily until a full week passes with no mismatches.
Review support tickets and on-site search terms each week for patterns such as missing products, account problems, or failed payments.
Keep every redirect in place for at least a year, and note the earliest removal date in your runbook so nobody removes them sooner.
Hold a 30-day review against the outcomes you signed off at the start and agree what goes into the next phase.

The search items follow Google's published guidance on site moves and redirects, and the performance items use the Core Web Vitals definitions from web.dev; both are linked in the sources below. Google also notes that rankings can fluctuate temporarily during a move, which is why the post-launch checks compare weekly trends with your baseline.

What we have seen

These examples come from our published client stories. Both projects included redirect planning, data and integration migration, and post-launch support, which map to items in the checklist above.

Three brands, one migration. Black Forest Decor, Lone Star Western Decor, and Bella Coastal Decor moved from BigCommerce to Shopify "in just three months". The migration covered "products, customers, orders, reviews, content, SEO metadata, redirects, and third-party integrations", and the results include "SEO preservation through URL transition planning and redirect management" with the "Project delivered on time and on budget".
A large catalog with many connected systems. Custom Service Hardware moved from BigCommerce to Shopify Plus with "More than 67,000 products and 70,000+ SKUs migrated". The move involved "customer records, product data, content, reviews, shipping rules, tax configurations, and multiple third-party integrations", including Sage ERP through Certipro, Avalara tax, and Yotpo reviews, and the plan ran through "Quality assurance, launch support, and post-launch hypercare".

Next step

If you are planning a replatform, bring your current platform, your target launch window, and this checklist with the items you are unsure about marked. On a discovery call we will walk through the gaps with you and help you decide what has to be true before you set a launch date.