The Plus migration checklist we actually use

We've shipped Plus migrations off Magento, WooCommerce, BigCommerce, Salesforce Commerce Cloud, and legacy Shopify Lite. The work has a shape — every migration ends up running through a similar set of checks in a similar order, regardless of where you're moving from.

This is the checklist we actually use internally. Not the 100-item consultantware version that lives on Shopify Partner blogs. The lean one we run through before, during, and after every cutover.

Pre-cutover (4–8 weeks out)

Data

• [ ] Catalog parity: SKU count, variants, metafields, 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 applicable): mapped through Recharge or equivalent
• [ ] Tax configuration: every region tested against known invoices
• [ ] Currency + market settings: Plus Markets configured, regional pricing verified

URL parity

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

Integrations

• [ ] ERP connection in dry-run mode against staging
• [ ] 3PL webhooks configured for staging, idempotent retry tested
• [ ] ESP (Klaviyo/Attentive/etc.) — customer profiles synced via dual-write window
• [ ] Reviews data (Yotpo / Stamped) — exported, imported, verified counts
• [ ] 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, organization
• [ ] Meta inheritance: title and description rules carry from old templates
• [ ] hreflang for multi-region builds
• [ ] Robots.txt + sitemap.xml drafts reviewed
• [ ] Crawl budget assessed — large catalogs may need pagination strategy

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

This is where most agencies skip work that pays off massively 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" math
• [ ] Cart math — discounts stack the same way, gift cards apply the same way
• [ ] Checkout — same options in 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 doesn't match is a blocker. We do not cut over with known divergence.

Cutover runbook

Every cutover gets a written runbook. The runbook has:

• [ ] 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's notified, in what order, on what channel
• [ ] Maintenance window: agreed up front, communicated to ops + CX
• [ ] Health dashboard: real-time graph of order rate, error rate, conversion rate
• [ ] Roles: incident commander, comms lead, technical lead — written down

Cutover steps, in order:

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

Post-cutover (T+0 to T+30)

First 72 hours

• [ ] Order count vs forecast — within 5% per hour
• [ ] Error rate — Sentry, < baseline
• [ ] Search Console crawl — no spike in 4xx/5xx
• [ ] Customer service ticket volume — within forecasted range
• [ ] Payment processor — settlement reports clean

First two weeks

• [ ] Search Console: 301s being followed, no manual actions
• [ ] Organic traffic: tracked daily for 30 days, deviation flagged
• [ ] Performance: Lighthouse runs daily, regressions investigated within 24h
• [ ] Customer support: top 5 tickets reviewed, root-cause-fixed not band-aided

First 30 days

• [ ] Financial reconciliation: legacy stack reports vs new stack reports
• [ ] All 3PL / ERP / ESP integrations running without manual intervention
• [ ] On-call window with us closes
• [ ] Retainer kicks in (if applicable)

What this checklist doesn't cover

This isn't every item. It's the load-bearing items — the ones whose absence has caused real problems on real migrations we've shipped. The actual project-specific runbook adds another 30–50 items per engagement, depending on stack complexity.

If you're staring at a checklist with 200 items and most of them feel like padding, you're reading consultantware. The real work is in the 50 things that, if any one of them fails, you have a bad weekend.

What we'd add if your build is unusual

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

If you're staring down one of these, that's the discovery call.