Shopify Replatforming Playbook: cutover and 90-day stabilization

Why brands replatform to Shopify

A replatform changes the storefront, data model, operational workflows, integrations and often the URL structure at the same time. That makes it a business program with measurable acceptance gates, not a theme project.

The brands we replatform to Shopify or Shopify Plus usually share three signals: their current platform is taxing engineering velocity (every release ships behind a feature flag because the system is fragile), checkout is a known revenue leak the team can't fix in the current platform, and the merchandising team wants ownership of changes without filing a ticket.

If you have only one of those, optimize what you've got. If you have all three, this guide is for you.

What this Shopify replatforming playbook owns

This playbook owns cross-platform program governance: workstreams, decision rights, evidence, cutover, rollback and the first 90 days after launch. It applies whether the destination is standard Shopify or Shopify Plus.

It does not decide whether Shopify Plus is justified or estimate Plus-specific platform and implementation costs. Use the Shopify Plus migration guide for that planning intent, the generic Shopify migration guide for the how-to checklist and the timeline guide for duration and sequencing.

The four migration shapes we run

Not every migration looks the same. Mapping yours to one of these four shapes determines budget, timeline, and risk surface.

Shape 1, Magento / Adobe Commerce → Shopify or Shopify Plus

Usually a 14–22 week build. The hard parts: catalog complexity (configurable products → variant models), multi-store hierarchies, and decades of URL structure. SEO is the headline risk.

Shape 2, BigCommerce → Shopify or Shopify Plus

Often the smoothest. APIs are clean and product/customer/order shapes map closely. 8–14 weeks. The hard parts: B2B price lists, customer groups, and any Stencil-specific theme logic.

Shape 3, WooCommerce → Shopify or Shopify Plus

Data is the headline. WooCommerce stores accumulate a decade of meta keys, plugin tables and inconsistent product taxonomy. Plan a 4-week data audit before estimating the build.

Shape 4, Custom stack (Rails, Node, headless CMS) → Shopify or Hydrogen

These are the most expensive. The team usually has strong opinions and the migration needs to preserve a specific editorial or personalization layer. We almost always end up on Hydrogen + Plus rather than Liquid.

URL & SEO strategy: the 301 plan that preserves rankings

Shopify uses prescribed route families such as /products/ and /collections/, so a cross-platform move often changes URLs. Google documents that site moves can produce temporary ranking fluctuations while old and new URLs are recrawled; medium-sized sites can take weeks and larger sites longer. A complete URL inventory and direct redirects reduce avoidable loss, but they do not guarantee unchanged rankings. See Google's site-move guidance.

The non-negotiables

• Crawl your current site with Screaming Frog and export every indexed URL with its rank, traffic, and backlink count.
• Build a 1:1 mapping spreadsheet from old URL → new Shopify URL. Every URL with traffic or backlinks must have a target.
• Implement redirects in Shopify's URL Redirects table (or Cloudflare Workers in front of it) before DNS cutover.
• Avoid redirect chains. Old → new in one hop, never two.

Things that bite

Faceted collection URLs, blog tag pages, internationalized URLs and search result pages all need policy. Decide which to redirect, which to canonical, and which to let 404. Document it before the cutover, not after.

Data migration: products, customers, orders, subscriptions

The migration spreadsheet has more rows than the build does. We typically move 6 data shapes and each one has gotchas.

Products & variants

Shopify now supports up to 2,048 variants per product, while the product model still requires deliberate option, taxonomy and integration design. Confirm every connected app and API supports the expanded model before mapping configurable products. See the official Shopify changelog.

Customers

Customer CSV imports do not migrate passwords because password hashes from another platform cannot be used in Shopify. Decide whether to activate classic accounts or use passwordless customer accounts, and plan communication and consent handling before launch. See Shopify's customer import documentation.

Orders

Historical orders can be imported via the Bulk Operations API for reference. But you usually don't want refunds, returns or subscription renewals running against the imported records, keep historicals read-only.

Subscriptions

Recharge, Skio and Stay AI all have migration paths but each requires a vault re-tokenization. Schedule with your processor 6 weeks ahead.

Metafields & custom data

This is where the slow week disappears. Custom data on the old platform rarely has a clean Shopify equivalent. Map it to metafields with namespaces you control, not the app's namespace.

App and integrations inventory: cut, replace, keep

Every store we migrate has at least one app that exists because someone, 4 years ago, needed something for one campaign. The migration is the right moment to cut.

The audit

List every app, every webhook, and every API consumer. For each, capture the business owner, the underlying job-to-be-done, and the monthly cost. Then sort into three columns: Keep (essential, has Shopify equivalent), Replace (Shopify has a native or better option), Cut (no longer needed).

Common cuts

Custom recommendation engines (Shopify has Search & Discovery), legacy review apps (consolidate to one), legacy CRO tools that don't support new checkout. Most stores cut 20–30% of their app stack at migration.

Common keeps

Klaviyo, Gorgias, the subscription processor, and the ERP/3PL integration. Plan these connections during the build, not after.

Program governance and acceptance gates

Every critical workstream needs one accountable decision owner, one evidence artifact and a written condition for closing the gate. A RACI without evidence is only a contact list.

Minimum governance record

• Data: reconciliation totals, exception log and business owner sign-off.
• SEO: old-to-new URL map, pre/post-launch crawl and Search Console owner.
• Commerce: payment, tax, shipping, discount, refund and notification scenarios with results.
• Integrations: replayable payloads, failure handling, monitoring and reconciliation owner.
• Cutover: timed runbook, go/no-go authority, rollback trigger and communication channel.

A phase closes only when its named evidence exists and the accountable owner accepts residual risk. Calendar dates alone do not close gates.

The cutover: staging, freeze windows, DNS, rollback

Cutover is the only step the executive team will remember. Plan it like a launch, not a deploy.

Timeline

• T-14 days: feature freeze on the old platform. No new content, no new products, no new code.
• T-7 days: final data sync rehearsal. Time it. Document every step.
• T-3 days: marketing pause on paid traffic to high-traffic landing pages.
• T-0: cutover window in lowest traffic period (usually 2–6am store time on Tuesday).
• T+24h: 24-hour war room. Engineering, marketing, support and the agency on shared Slack.

Rollback

Keep the old platform warm for 14 days. Set TTLs low. If something catastrophic surfaces in the first 48 hours, you want to be able to revert.

Post-launch: monitoring, performance, the 30/60/90

The brands that come out of replatform happy aren't the ones that nailed launch day, they're the ones that nailed week 4.

Days 0–30

Monitor everything. Track conversion rate, AOV, revenue per session, organic traffic and Core Web Vitals against the pre-launch baseline. Catch regressions in days, not weeks.

Days 30–60

Ship the items you knowingly punted from launch scope. Most stores have a list of 8–15 "phase 2" items. Convert that into a 60-day backlog.

Days 60–90

Start the optimization layer after the operation is stable. Prioritize one measurable improvement at a time so changes in conversion, performance or support volume can be attributed.

Budget controls for enterprise Shopify replatforming

A responsible budget is built from verified scope, not a universal platform-to-platform range. Separate one-time implementation, recurring platform and app fees, internal team allocation, contingency and post-launch ownership.

Scope controls

Price the catalog and data model, storefront templates, integrations, Markets, subscriptions, B2B, SEO exposure, content volume, accessibility, analytics, QA and cutover independently. Record assumptions, exclusions and the change-control method.

Internal capacity

Name business owners who can resolve catalog, operations, finance, legal, marketing and support questions inside the delivery cadence. Unavailable decision owners are a schedule dependency and should appear in the risk register.

Platform-specific cost

Shopify Plus commercial terms and implementation scope are separate decisions. For current platform pricing and Plus-specific cost drivers, use the Shopify Plus migration guide and verify the official Shopify Plus pricing page.