E-commerce platform migration checklist

Moving a live store is not a theme swap. Catalogs, URLs, customer accounts, payment tokens and warehouse connections all have to land together. This checklist is for teams leaving Shopify, Magento, WooCommerce or a custom stack — or moving toward headless commerce — and want a cutover they can rehearse. Kode Builder uses the same sequence on custom e-commerce builds: freeze what must not break, migrate data with proof, then switch traffic with a rollback path.

1. Goals, Scope and Freeze Rules

Name why you are leaving the current platform and what “done” means. Unbounded replatforms never finish.

• Migration drivers ranked (cost, checkout limits, B2B rules, performance, ownership)
• Target architecture chosen: hosted platform, custom, or headless hybrid
• In-scope channels listed (web, app, marketplace sync, POS)
• Feature parity vs intentional drop list agreed with merchandising and ops
• Content freeze window defined (no catalog or CMS edits during final sync)
• Legal and tax contexts listed (GST, shipping origin, restricted SKUs)
• Downtime budget and preferred cutover window agreed with stakeholders
• Success checks written (checkout works, top URLs 200, orders reach warehouse)

2. Catalog, Customers and Order History

Data quality on the old platform becomes production bugs on the new one. Inventory and IDs first.

• Product, variant, SKU and inventory model mapped to the new catalog
• Images, videos and alt text exported; broken media listed for fix or drop
• Collections, categories, tags and merchandising rules documented
• Price lists, discounts, gift cards and loyalty balances inventoried
• Customer accounts plan: migrate, reset passwords, or guest-only at launch
• Open orders, subscriptions and partial fulfillments handled explicitly
• Historical orders: migrate, archive, or keep read-only on the old platform
• Row counts and sample checksums recorded after each trial import

3. SEO, URLs and Redirects

Rankings follow URLs. A missing 301 map is the most expensive silent failure in a store move.

• Current URL inventory exported (products, collections, blogs, landing pages)
• New URL scheme designed (trailing slashes, locale prefixes, filters)
• One-to-one 301 map drafted; leftover URLs have a policy (homepage vs 410)
• Canonical tags, hreflang and pagination rules defined on the new stack
• Structured data planned (Product, Offer, Breadcrumb, FAQ where used)
• Sitemap and robots.txt prepared for launch; Search Console property ready
• Redirects tested in staging for top organic landing pages
• Tracking preserved: GA4, ads pixels, server-side events if used

4. Integrations: ERP, WMS, 3PL and Apps

Apps you uninstall on Shopify do not magically reappear. Rebuild only the connections that still earn their keep. Compare platform vs custom trade-offs in Shopify vs custom e-commerce.

• ERP / accounting sync mapped (SKU, inventory, invoices, tax codes)
• WMS or 3PL order/ASN/tracking contracts documented
• CRM, helpdesk and email platform connections listed
• Marketplace or social selling feeds (if any) retargeted to the new catalog
• App replacement list: keep, rebuild, or drop with a workaround
• Webhook and API credentials issued in sandbox and production
• Idempotency and duplicate-order protection agreed with ops
• Partner allowlists updated for new IPs or callback URLs

5. Payments, Tax and Fraud

Checkout is the revenue path. Tokens, webhooks and settlement reports must work before you advertise the new store.

• Payment providers chosen (cards, UPI, wallets, BNPL, COD) with live keys
• Saved cards / vault migration assessed (often not portable — plan UX)
• Tax engine or GST rules verified for shipping origin and destination
• Refunds, partial captures and failed-payment retries tested
• Webhook handlers verified (paid, failed, disputed) with replay tests
• Fraud / 3-D Secure / risk rules ported or redesigned
• Settlement and payout reports assigned to finance
• PCI scope understood (hosted fields vs your servers touching PAN)

6. Testing and Staging Proof

Do not cut over on hope. Prove browse, cart, pay, fulfill and email on a staging catalog that looks like production.

• Staging environment uses production-like data (masked where required)
• Critical journeys scripted: search, PDP, cart, checkout, account, reorder
• Mobile and desktop checked for layout, tap targets and payment sheets
• Performance budget reviewed on real product pages (images, third-party JS)
• Promo codes, gift cards and edge SKUs (preorder, out of stock) tested
• Transactional email and SMS templates approved
• Accessibility pass on key templates (forms, contrast, focus)
• Load or soak test considered if a campaign lands on launch week

7. Cutover Runbook

Write ordered steps with owners. The night of the move is too late to invent DNS TTL policy.

• DNS records and current TTLs documented; TTL lowered ahead of the window
• Final delta sync plan for products, inventory and customers
• Old store put in maintenance or “read-only checkout” as designed
• Redirect layer live before or with DNS switch
• Smoke tests after DNS: homepage, top SKUs, checkout sandbox then live
• Rollback trigger defined (who decides, how traffic returns, data risk)
• Internal and customer comms drafted (status page, email, support macros)
• On-call roster covering engineering, ops and payments for the window

8. Post-Launch Hypercare

The first days catch inventory drift, missing redirects and payment webhook gaps. Staff them on purpose.

• Hypercare period staffed (orders, inventory, SEO, payments watched daily)
• 404 and redirect logs reviewed; map updated for missed URLs
• Search Console and analytics compared to pre-migration baselines
• Inventory and fulfillment exceptions queued with a named owner
• Chargebacks and failed webhooks triaged with finance
• Old platform decommission plan: data export, app cancellation, DNS leftovers
• Runbooks updated for deploy, refunds and incident response
• Retrospective captured before the next catalog or channel expansion