BigCommerce → Shopify
Move catalog, customers, orders, subscriptions, discounts, inventory, taxes, shipping, storefront routes, apps, and financial evidence from BigCommerce into Shopify with an explicit exception ledger and evidence-based cutover.
Should you make this move?
Both platforms have a case. Compare what you gain with what you give up before scheduling the cutover.
BigCommerce
- Strong multi-channel and headless commerce capabilities avoid transaction fees
- Core catalog, order, customer, and promotion workflows are integrated
- Theme ecosystem and day-to-day editing can feel less approachable than simpler storefronts
- Deep customization usually increases extension, agency, or engineering costs
Shopify
- A polished hosted commerce platform has an unmatched app and partner ecosystem
- Core catalog, order, customer, and promotion workflows are integrated
- Transaction economics, app dependency, and checkout constraints reduce control
- Deep customization usually increases extension, agency, or engineering costs
Shopify: A polished hosted commerce platform has an unmatched app and partner ecosystem. This removes a major source-side concern: Theme ecosystem and day-to-day editing can feel less approachable than simpler storefronts.
What you lose: Strong multi-channel and headless commerce capabilities avoid transaction fees. What you inherit: Transaction economics, app dependency, and checkout constraints reduce control.
Jump to a section
Know the shape of the move.
This timeline assumes
- Up to 100,000 products, 500,000 customers, and one million orders
- Store, finance, support, fulfillment, SEO, and engineering owners approve the destination operating model.
- The source remains available through at least one full refund, fulfillment, payout, and renewal cycle.
- A complete test catalog and buyer cohort run before production data.
- The migration team records evidence for every blocking verification check.
What survives the move.
“Partial” and “manual” are not footnotes. They are work that must be scheduled and verified.
| Item | Outcome | Impact | What happens | Mitigation |
|---|---|---|---|---|
| Products, variants, images, customers, orders, discounts, and inventory | partial | critical | Core products, variants, images, customers, orders, discounts, and inventory can move, but BigCommerce and Shopify use different models, limits, identifiers, and import behavior. | Pilot every feature class, preserve source IDs, and reconcile accepted, transformed, rejected, and excluded items. |
| Storefront theme, checkout behavior, apps, subscriptions, multi-storefront rules, and financial history | manual | critical | BigCommerce presentation and application behavior do not become Shopify configuration through catalog and order imports. | Inventory every active dependency, approve its destination disposition, and test the replacement before source writes stop. |
| Products and variants | partial | critical | Core catalog data can move while option, bundle, custom-field, and digital-product models differ. | Reconcile every product and variant against an approved catalog map. |
| Images, files, and digital delivery | partial | critical | Exports may contain URLs rather than durable binaries or customer entitlements. | Copy originals, compare hashes, and test delivery as a buyer. |
| Customers and accounts | partial | critical | Profiles can move while passwords, account identity, consent, addresses, and tax details vary. | Use secure activation and never promise password transfer. |
| Orders, refunds, and transaction history | partial | critical | Historical orders may import without becoming editable payment transactions. | Preserve source IDs and reconcile gross, tax, discount, refund, and net totals. |
| Active subscriptions and payment methods | partial | critical | Recurring billing ownership requires provider cooperation or customer reauthorization. | Choose a documented takeover or managed re-subscription path and prevent double billing. |
| Discounts, coupons, and gift balances | partial | high | Eligibility, stacking, expiry, redemption, and stored balances use different models. | Map active rules and test boundary conditions. |
| Taxes, invoices, and merchant records | manual | critical | Merchant-of-record, registration, calculation, invoice, and filing responsibilities can change. | Obtain finance and legal approval before accepting destination sales. |
| Shipping, inventory, and fulfillment | partial | critical | Locations, stock states, backorders, rates, carriers, and fulfillment workflows differ. | Freeze stock movement briefly and reconcile every location. |
| Storefront, checkout, and URLs | lost | critical | Themes and checkout runtime do not transfer as store data, and route structures change. | Rebuild approved journeys and test one-hop redirects for every indexed route. |
| Reviews, memberships, licenses, and entitlements | partial | high | Platform-specific access and customer-library objects need separate migration. | Create an entitlement ledger and test representative buyers. |
Where each thing goes.
| Source | Destination | Method | Notes |
|---|---|---|---|
| BigCommerce product | Shopify product | transform | Preserve source ID, title, status, and URL. |
| Variant, option, or tier | Destination variant, option, or plan | transform | Map cardinality and price explicitly. |
| Image, file, or media | Destination media or delivery asset | transform | Copy and compare hashes. |
| Customer | Destination customer | transform | Preserve identity, consent, and source ID. |
| Order or sale | Destination historical order or ledger record | transform | Preserve amounts, currency, tax, discount, and status. |
| Subscription or membership | Destination subscription or entitlement | manual | Use supported billing transfer or customer reauthorization. |
| Coupon or discount | Destination discount | transform | Map eligibility, expiry, limits, and redemption. |
| Inventory location and quantity | Destination location and inventory | transform | Freeze and reconcile at cutover. |
| Public route | Destination route and redirect | manual | Preserve or redirect every indexed URL. |
Make the move recoverable.
Create the source-of-truth backup
Preserve BigCommerce data, configuration, and operating evidence before any destination write.
- Export BigCommerce products, variants, assets, customers, orders, subscriptions, discounts, inventory, taxes, payouts, and settings.
- Crawl storefront routes, metadata, checkout, account, fulfillment, support, and integration behavior.
- Record counts and signed financial totals by status, currency, tax, discount, refund, location, and billing state.
- Hash exports and downloadable assets.
Proof to capture: A signed manifest reconciles every scoped record class, runtime dependency, export file, count, and hash.
Catalog, customer, and order map
Preserve identity, commercial meaning, and financial totals.
- Inventory source values and exceptions.
- Define explicit destination mappings.
- Reject unmapped critical records.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
Storefront and operating cutover
Rebuild customer journeys, fulfillment, billing, URLs, and integrations.
- Normalize encoding, dates, identifiers, and blanks.
- Run a representative pilot.
- Reconcile accepted, rejected, and transformed rows.
Proof to capture: Save the input, output, command or tool settings, warnings, and final item counts.
The things most likely to hurt.
These are operating limits. Treat every “Stop if” condition as a blocked migration, not a suggestion.
Orders or inventory change during the final copy
Customers buy, refund, or fulfill while destination data is loading.
- Consequence
- Stock and financial ledgers diverge.
- Mitigation
- Freeze affected writers and apply a reconciled final delta.
Stop if: Any unexplained post-freeze commercial event exists.
Both stores sell or renew
Old checkout, subscriptions, or automations remain active.
- Consequence
- Customers are double charged or receive conflicting fulfillment.
- Mitigation
- Move one production owner at a time and monitor test buyers.
Stop if: Any buyer can complete duplicate production actions.
Routes work but checkout fails
Storefront pages render while tax, shipping, payment, delivery, or account paths fail.
- Consequence
- Revenue and customer trust are lost.
- Mitigation
- Run end-to-end orders for every critical market and product type.
Stop if: A blocking buyer journey fails.
Do the work in this order.
- Days 1–3 · inventory
Inventory and decisions
6–12 hours active2–3 days elapsedOwner review waiting- Inventory BigCommerce data, features, users, domains, and integrations.
- Approve scope, owners, mappings, and exclusions.
Depends on: BigCommerce and Shopify administrator access
Stop / go checkpointExport?
Go when: Every critical item has an owner and disposition.
Stop when: Consent, billing, access, or system ownership is unclear.
- Days 3–5 · backup
Backup and reconcile
5–10 hours active1–3 days elapsedExport processing waiting- Create immutable exports and configuration evidence.
- Reconcile counts, totals, and hashes.
Depends on: Approved inventory
Stop / go checkpointTransform?
Go when: Source totals and export manifests agree.
Stop when: Any critical dataset or configuration is absent.
- Days 5–12 · pilot
Map and pilot
10–35 hours active3–8 days elapsedDestination processing and review waiting- Configure Shopify and transform representative data.
- Run a pilot containing normal records and every critical edge case.
Depends on: Verified backup
Stop / go checkpointScale?
Go when: Pilot mappings, behavior, access, and evidence pass.
Stop when: Any critical check fails or produces unexplained variance.
- Days 10–20 · cutover
Final delta and switch
5–25 hours active1–5 days elapsedDNS, import, or sync propagation waiting- Freeze production writes in BigCommerce.
- Apply the final delta, switch ownership, and run blocking checks.
Depends on: Passed pilot and approved rollback
Stop / go checkpointOpen production?
Go when: Counts reconcile and one destination system owns production.
Stop when: A source writer remains active or a blocking check fails.
- Days 12–40 · observe
Observe and close
3–18 hours active3–10 days elapsedOperating-cycle evidence waiting- Monitor one complete operating cycle.
- Sign the verification report and close rollback only after stability.
Depends on: Verified cutover
Stop / go checkpointClose rollback?
Go when: No trigger occurs during the agreed observation period.
Stop when: Data, access, delivery, routing, or business results regress.
Cut over with a way back.
Cutover
Make Shopify the only production system without losing the final BigCommerce delta.
- Freeze production writes and scheduled actions in BigCommerce.
- Export, transform, and reconcile the final delta.
- Apply the approved delta to Shopify.
- Switch domains, forms, integrations, sending, or sync ownership as applicable.
- Run every blocking verification check and keep the source intact.
Proof to capture: Shopify owns production, totals reconcile, and every blocking check has durable evidence.
Rollback
Return production ownership to BigCommerce without losing destination-era changes.
- Stop new writes and scheduled actions in Shopify.
- Restore the prior BigCommerce routing, forms, integrations, sending, or sync ownership.
- Export the Shopify post-cutover delta.
- Review and apply safe destination-era changes to BigCommerce.
- Run the same blocking checks against the restored source.
Proof to capture: BigCommerce again owns production with current data and no duplicate destination action.
- Unexplained critical count or value variance
- Missing or exposed critical data
- Duplicate production action
- Failed access, routing, delivery, or integration check
- A critical feature has no safe destination replacement
Prove the migration worked.
Every blocking check must pass. Capture the evidence before cleanup begins.
| Pass | ID | Check | Method | Expected result | Evidence |
|---|---|---|---|---|---|
V-01Blocking | Product and variant reconciliation | Compare counts, fields, media, prices, status, and inventory. | Every scoped catalog object is accounted for. | Catalog ledger. | |
V-02Blocking | Identity and account activation | Compare profiles and exercise secure account access. | Approved customers can access only their data. | Customer report. | |
V-03Blocking | Commercial and financial history | Reconcile counts and signed totals by status, currency, tax, discount, and refund. | Every order and amount is accounted for. | Order ledger. | |
V-04Blocking | Subscriptions and entitlements | Test every lifecycle state through renewal or reauthorization. | One correct charge and entitlement owner. | Subscription report. | |
V-05Blocking | Location and fulfillment parity | Place, fulfill, cancel, return, and refund test orders. | Stock and fulfillment outcomes reconcile. | Fulfillment evidence. | |
V-06Blocking | Buyer journeys | Complete every product, payment, tax, shipping, and market path. | One valid order, receipt, delivery, and account result. | Test-order matrix. | |
V-07Blocking | Storefront and SEO | Crawl old and new routes, metadata, canonicals, and redirects. | Every indexed route resolves correctly. | Route diff. | |
V-08Blocking | Single store authority | Inspect checkout, inventory, subscriptions, integrations, and support. | Shopify alone accepts production orders. | Cutover checklist. |
Remove the scaffolding safely.
Safe after: One complete operating cycle, at least seven stable days, and owner sign-off on every blocking check.
- Create final BigCommerce exports and archive verification evidence.
- Revoke temporary credentials, API keys, webhooks, and elevated roles.
- Remove obsolete embeds, forms, jobs, integrations, and DNS records.
- Keep the source intact through the approved retention window.
- Cancel paid plans only after billing, legal, and recovery review.
- Schedule the next Shopify backup, access, and migration-playbook review.
When the plan met reality.
First-hand accounts are preferred. Vendor case studies are labeled, and every note below is an editorial paraphrase—follow the link for the full context.
Shopify’s 4ocean case study follows a retailer that first left Shopify for BigCommerce during rapid growth, then reversed the move after operational costs and complexity increased. 4ocean reports losing about 80% of organic traffic during the original BigCommerce migration and spending tens of thousands on custom development for routine commerce functions. Returning to Shopify was faster and restored direct control over everyday store operations.
- Model the ongoing staffing and custom-development cost of the destination instead of comparing platform subscription prices alone.
- Protect organic traffic with a complete URL and redirect inventory, especially when reversing an earlier replatforming project.
- A platform selected for enterprise scale increased dependence on specialist developers and pulled resources away from the company’s mission.
- The second migration was easier partly because the team already understood Shopify’s operating model and native capabilities.
Verify against the primary material.
Platform behavior changes. Check these sources and the review dates above before executing a production migration.
- BigCommerce: official migration documentationAccessed 2026-07-19
- Shopify: official migration documentationAccessed 2026-07-19