The Plus migration checklist we run

We have moved stores to Shopify from Magento, WooCommerce, BigCommerce, Salesforce Commerce Cloud, Square, Squarespace, Wix and older Shopify setups. The work has a shape. Every migration runs through a similar set of checks in a similar order, whatever you are moving from.

This is the checklist we use internally. It is shorter than the 100-item versions on Shopify Partner blogs because it only holds the items whose absence has hurt us.

Pre-cutover (4 to 8 weeks out)

Data

• [ ] Catalog parity: SKU count, variants, metafields and inventory locations match
• [ ] Customer migration plan: passwords reset gracefully, magic-link transition for first sign-in
• [ ] Order history imported and visible in admin (last 24 months minimum)
• [ ] Subscription data (if any) mapped through Recharge or equivalent
• [ ] Tax configuration: every region tested against known invoices
• [ ] Currency and market settings: Plus Markets configured, regional pricing verified

URL parity

• [ ] Legacy URLs scraped into a site map (Screaming Frog or equivalent)
• [ ] 301 map drafted and dry-run tested
• [ ] Canonical strategy decided: subfolder, subdomain or domain swap
• [ ] Search Console verified for the new property
• [ ] Sitemap.xml regeneration scheduled for the cutover hour

Integrations

• [ ] ERP connection in dry-run mode against staging
• [ ] 3PL webhooks configured for staging, idempotent retry tested
• [ ] ESP (Klaviyo, Attentive or similar): customer profiles synced through a dual-write window
• [ ] Reviews data (Yotpo, Stamped): exported, imported, counts verified
• [ ] Loyalty data: exported, imported, point balances verified
• [ ] Payment processor: Plus connection tested with $1 transactions in staging

SEO

• [ ] Structured data plan: review markup, product, breadcrumb, organisation
• [ ] Meta inheritance: title and description rules carried from the old templates
• [ ] hreflang for multi-region builds
• [ ] Robots.txt and sitemap.xml drafts reviewed
• [ ] Crawl budget assessed; large catalogs may need a pagination strategy

Two-stack parallel run (1 to 2 weeks before cutover)

This is the step most agencies skip, and it is the one that pays off most at cutover. We mirror live traffic against the staging build and diff:

• [ ] Pricing: every line item, every tax line, every shipping option
• [ ] Inventory: locations, allocations, available-to-promise maths
• [ ] Cart maths: discounts stack the same way, gift cards apply the same way
• [ ] Checkout: same options in the same order, same totals
• [ ] Order confirmation: same email content, same fields populated
• [ ] Webhook delivery: every event we expect arrives in the new stack

Anything that does not match is a blocker. We do not cut over with known divergence.

Cutover runbook

Every cutover gets a written runbook containing:

• [ ] Decision tree: at each gate, what would cause a rollback
• [ ] Rollback rehearsal: we run the rollback in staging on the Tuesday before
• [ ] Communication plan: who is notified, in what order, on which channel
• [ ] Maintenance window: agreed up front, communicated to ops and CX
• [ ] Health dashboard: real-time order rate, error rate and conversion rate
• [ ] Roles, written down: incident commander, comms lead, technical lead

Cutover steps, in order:

1. Freeze writes on the legacy stack (orders queued, not lost)
2. Final delta sync of anything changed during the freeze
3. DNS swap (TTL lowered earlier in the day)
4. Watch the health dashboard for 90 minutes
5. Unfreeze: the legacy stack drains its queue into the new stack through the integration
6. Sentry and RUM monitoring for the next 72 hours

Post-cutover (day 0 to day 30)

First 72 hours

• [ ] Order count against forecast, within 5% per hour
• [ ] Error rate in Sentry below baseline
• [ ] Search Console crawl with no spike in 4xx or 5xx
• [ ] Customer service ticket volume within the forecast range
• [ ] Payment processor settlement reports clean

First two weeks

• [ ] Search Console: 301s followed, no manual actions
• [ ] Organic traffic tracked daily for 30 days, deviations flagged
• [ ] Performance: Lighthouse runs daily, regressions investigated within 24 hours
• [ ] Customer support: top five tickets reviewed and root-caused, not patched

First 30 days

• [ ] Financial reconciliation: legacy stack reports against new stack reports
• [ ] All 3PL, ERP and ESP integrations running without manual intervention
• [ ] Our on-call window closes
• [ ] Plan starts, if you are taking one

What this checklist leaves out

This is not every item. It is the load-bearing ones, whose absence has caused real problems on migrations we have shipped. The project-specific runbook adds another 30 to 50 items per engagement depending on the stack.

If you are looking at a checklist with 200 items and most of them feel like padding, it is padding. The real work is in the 50 things that give you a bad weekend if any one of them fails.

What we add for unusual builds

• B2B migrations: a separate checklist for wholesale price lists, net terms and approval flows
• Headless or Hydrogen: 30 or more items around Storefront API rate limits, edge caching and ISR
• Multi-store: coordination items for the order in which stores cut over
• High-traffic launches: a load test against the new stack before cutover

If one of these is yours, that is what the discovery call is for.