BigCommerce to Magento Migration – Step-by-Step Guide & Services

BigCommerce is a strong platform. We have built successful stores on it. But there is a point where certain businesses outgrow what BigCommerce can do – not because it is a bad platform, but because the business has evolved past what a SaaS-controlled architecture allows.

We have migrated complex ecommerce operations from BigCommerce to Magento. Each one had a specific reason for leaving. None of them migrated because they read a comparison article that said Magento was “better.” They migrated because they hit real, documented constraints that could not be solved within BigCommerce’s architecture.

This guide walks through the entire migration process – when it makes sense, what it involves, how to preserve your SEO equity, and how to avoid the mistakes that derail these projects.

When BigCommerce to Magento migration makes sense

Not every frustration with BigCommerce justifies migration. Some problems are solvable with apps, API integrations, or creative workarounds. Migration is justified when you have hit structural limits that no amount of configuration can fix.

Your B2B requirements exceed BigCommerce’s B2B Edition. BigCommerce has invested significantly in B2B capabilities – company accounts, price lists, quote management, and purchase orders are all available. But when you need multi-level organizational hierarchies with role-based permissions across dozens of buying accounts, custom approval workflows with conditional routing logic, or customer-specific catalog visibility at the category level, you are beyond what BigCommerce’s B2B features support natively. Adobe Commerce’s B2B module was built for this complexity from the ground up.

You need multi-store with shared backend infrastructure. BigCommerce handles multiple storefronts through its multi-storefront feature, but the implementation has limits. When you need five or more storefronts sharing one product catalog with store-specific pricing, shared inventory with per-store allocation rules, and centralized order management across all stores, Magento’s website/store/store view hierarchy provides deeper native control.

Your catalog data model is too complex for BigCommerce’s product structure. BigCommerce products support variants, modifiers, and custom fields. But when you need attribute sets that differ by product type (where electronics have completely different data requirements than apparel), configurable products with complex option dependency rules, or custom product types with unique business logic, Magento’s EAV data model handles this natively.

Your checkout needs custom server-side logic. BigCommerce’s checkout is extensible through its Checkout SDK, but you cannot add server-side validation, custom payment workflows, or conditional logic that requires database queries during checkout. If your business requires insurance verification, compliance checks, split-shipment logic at checkout, or custom tax calculations that BigCommerce’s tax engine does not support, Magento’s open checkout architecture removes that constraint.

Your integration requirements need deep backend access. BigCommerce’s APIs are comprehensive for a SaaS platform. But when your ERP integration requires real-time bidirectional sync with custom business rule validation at every step, event-driven workflows that trigger complex server-side processing, or direct database access for reporting and analytics, Magento’s open architecture gives you complete control.

For a broader comparison of these two platforms, see our Magento vs BigCommerce analysis.

When you should NOT migrate

Migration is expensive, risky, and disruptive. We have talked businesses out of it when the reasons did not justify the cost.

Do not migrate for features that BigCommerce apps solve. Before committing to migration, exhaustively evaluate whether your requirement can be met within BigCommerce’s ecosystem. A $200/month app is vastly cheaper than a $100,000+ migration project.

Do not migrate because of developer preferences. If your development team prefers PHP or wants more control, that is understandable. But it is not a business reason to put your operation through a platform migration. The platform should serve the business, not the developers.

Do not migrate during peak season. This sounds obvious, but we have seen businesses start migration projects in September targeting a November launch for the holiday season. Migration timelines always expand. Do not put your peak revenue at risk.

Do not migrate without a clear technical owner. Magento requires ongoing technical management – server maintenance, security patches, performance optimization, extension updates. If you do not have an in-house technical team or a committed agency partner, you will struggle with Magento’s operational demands after migration.

Consider Shopware as an alternative. Depending on your requirements, Shopware 6 may be a better fit than Magento. If your primary driver is B2B flexibility with a more modern codebase, Shopware’s API-first architecture and rule-based configuration deserve evaluation.

Migration scope – what actually needs to move

Understanding the full scope of migration prevents surprise halfway through the project. Here is everything that needs to transfer.

Product catalog

Your entire product catalog needs to be restructured for Magento’s data model:

• Simple products map relatively cleanly, but attribute sets in Magento work differently than BigCommerce’s custom fields
• Products with variants need to be converted to Magento’s configurable product model, which uses associated simple products rather than variant options
• Product images need to be downloaded, reorganized, and re-uploaded with proper attribute assignments (base, small, thumbnail, swatch)
• Categories need to be rebuilt in Magento’s category tree, which supports nesting, display settings, and category-specific attributes
• Product relationships (related products, up-sells, cross-sells) need to be recreated
• Custom fields and metafields need to be mapped to Magento’s attribute system with proper input types, scoping, and attribute sets

Common issue: BigCommerce allows up to 600 variants per product. Magento’s configurable product system has no hard limit but handles the relationship differently. Products with complex variant matrices need careful planning to avoid performance issues.

Customer data

• Customer accounts migrate, but passwords do not. BigCommerce and Magento use different hashing algorithms. Every customer will need to reset their password. Plan a communication strategy for this.
• Customer groups need to be recreated and mapped. BigCommerce’s customer groups and Magento’s customer groups serve similar purposes but with different configuration options.
• Saved addresses transfer through the migration process.
• Order history imports as reference data. Customers can view their historical orders, but those orders will not process through Magento’s order management system.
• Wishlists and saved carts may or may not be worth migrating depending on your customer behavior data.

Content

• CMS pages need to be recreated in Magento’s content system. BigCommerce pages built with the Page Builder widget system do not transfer – they need to be rebuilt using Magento’s Page Builder (Adobe Commerce) or CMS blocks.
• Blog posts require a blog extension for Magento (it does not have native blogging). Amasty Blog, Magefan Blog, or a headless CMS approach are common choices.
• Banners and promotional content need to be recreated.
• Email templates need to be rebuilt in Magento’s email template system.

Integrations

Every third-party integration needs an equivalent on Magento:

BigCommerce Integration Type	Magento Equivalent
Native payment gateways	Payment gateway extensions
Shipping apps	Shipping extensions + custom modules
Tax automation (Avalara, TaxJar)	Same providers, different extensions
Email marketing (Klaviyo, etc.)	Same providers, Magento-specific integrations
ERP connectors	Custom integration or middleware (often the primary migration driver)
Reviews (Yotpo, Judge.me)	Same providers, Magento extensions
Search (Searchspring, Algolia)	Same or similar providers
Analytics	Same tools, different integration method

Data migration details

Data migration is the most technically demanding phase. Do it wrong and you corrupt your catalog, lose customer relationships, or break your order history.

Export from BigCommerce

Use BigCommerce’s V3 API for data export – not CSV exports. The API provides complete data including metafields, custom fields, and relationships that CSV exports truncate or omit.

Products: /v3/catalog/products (with ?include=variants,images,custom_fields,bulk_pricing_rules)
Customers: /v3/customers (with ?include=addresses,attributes)
Orders: /v2/orders (includes line items, shipping addresses, coupons)
Categories: /v3/catalog/categories (with ?include=url)
Brands: /v3/catalog/brands
Pages: /v3/content/pages
Redirects: /v3/storefront/redirects

Export everything to structured JSON files. Do not try to transform data during export – extract it cleanly first, then transform.

Transform for Magento

The transformation step is where most migration problems occur. Key transformations:

Product type mapping. BigCommerce products with variants become Magento configurable products with associated simples. Each variant becomes its own simple product, linked to the configurable parent through configurable attributes. This can multiply your SKU count significantly.

Attribute mapping. BigCommerce custom fields map to Magento product attributes. But Magento attributes require explicit configuration – input type (text, dropdown, multiselect, etc.), scope (global, website, store view), whether they are used in layered navigation, and which attribute set they belong to. Plan this mapping carefully before import.

Category structure. BigCommerce categories map to Magento’s category tree. Ensure URL keys, meta data, and display settings transfer correctly. Magento categories have more configuration options – you will need to set default sort order, available sort options, and layered navigation filter settings.

Price mapping. BigCommerce pricing (base price, sale price, cost price, MAP, retail price) maps to Magento’s price attributes. If you use customer group pricing or tier pricing, those need separate transformation.

Import into Magento

Run migration on staging first. Always.

Use Magento’s built-in import system for bulk data, or a migration extension (Cart2Cart, LitExtension) for automated migration. For complex catalogs, custom import scripts using Magento’s repository APIs give you the most control.

Validate after import:

• Product count matches
• All images display correctly
• Category assignments are accurate
• Pricing is correct across customer groups
• Configurable products show correct options
• Search returns expected results
• Layered navigation filters work

Run the full migration on staging at least twice. Each run reveals edge cases – special characters in product names, missing required attributes, broken image references, or data type mismatches. Fix these before the production migration.

Functionality rebuild

Every feature on your BigCommerce store needs an equivalent on Magento. This is typically the longest phase.

Theme and frontend. Your BigCommerce Stencil theme does not transfer. You need a new Magento theme – either a custom theme built on Magento’s Luma base, a purchased theme modified for your brand, or a headless frontend using PWA Studio or a JavaScript framework. Budget accordingly.

Checkout customizations. Any BigCommerce checkout modifications – custom fields, conditional logic, modified payment flow – need to be rebuilt as Magento checkout customizations. This typically requires a Magento developer experienced with checkout modification, which is one of the more complex areas of the platform.

Promotions and pricing rules. BigCommerce promotions need to be recreated as Magento catalog price rules and cart price rules. Magento’s promotion engine is more powerful but more complex. If you have a large number of active promotions, budget time for testing each one.

Automation and workflows. Any automated processes – abandoned cart emails, post-purchase sequences, inventory alerts – need to be recreated using Magento’s native capabilities or equivalent extensions.

SEO preservation

SEO preservation is the single most important technical aspect of migration. Get this wrong and you lose organic traffic that took years to build.

URL mapping and redirects

Create a complete URL map before migration. Every URL on your BigCommerce store needs to either have an equivalent on Magento or a 301 redirect to the correct destination.

BigCommerce URL structure and Magento URL structure are different by default:

Content Type	BigCommerce URL	Magento URL
Product	/product-name/	/product-name.html (default)
Category	/category-name/	/category-name.html (default)
CMS Page	/page-name/	/page-name
Blog Post	/blog/post-name/	Varies by blog extension

Configure Magento URL suffixes to match BigCommerce. You can set product and category URL suffixes in Magento to eliminate the .html extension. Do this before importing products so URL keys generate correctly.

Map every URL. Export all BigCommerce URLs (products, categories, pages, blog posts). Map each one to its Magento equivalent. For any URLs that change, create 301 redirects.

Handle BigCommerce’s redirect system. BigCommerce may have its own 301 redirects configured. These need to be carried over – the final destination of each redirect chain should point to the correct Magento URL.

Meta data transfer

Transfer all SEO metadata:

• Page titles (title tags)
• Meta descriptions
• Canonical URLs
• Open Graph tags
• Custom meta robots directives

Do not rely on auto-generated metadata. Transfer the exact metadata from BigCommerce, then optimize on Magento after migration is stable.

Sitemap and indexing

• Generate and submit a new XML sitemap immediately after launch
• Monitor Google Search Console for crawl errors daily for the first two weeks
• Use the URL Inspection tool to verify key pages are indexed correctly
• Watch for soft 404s – pages that return 200 but display error content

Structured data

If your BigCommerce store uses structured data (Product schema, BreadcrumbList, Organization), verify that your Magento theme generates equivalent markup. Missing structured data can cause rich snippet loss in search results.

For a complete breakdown of SEO best practices on Magento, see our Magento SEO guide.

Integration reconfiguration

Every integration needs to be reconnected on Magento. This is not as simple as re-entering API keys – each integration works differently on a different platform.

Payment gateways. Set up payment gateways natively in Magento or through extensions. Test every payment method – credit card, PayPal, Apple Pay, purchase orders – in staging before launch. Process test transactions through the complete flow including refunds.

Shipping. Configure shipping methods, zones, rates, and rules. If you use a shipping platform (ShipStation, ShipBob, EasyPost), install the Magento-specific integration and verify rate calculations and label generation.

ERP integration. This is often the primary migration driver and the most complex integration to rebuild. If your BigCommerce-ERP integration was handling order sync, inventory updates, pricing, and customer data, the Magento equivalent needs to handle all the same data flows – often with different API structures and webhook formats. Budget significant time for ERP integration testing.

Marketing tools. Email marketing platforms (Klaviyo, Mailchimp, Omnisend), SMS marketing, loyalty programs, and review platforms all need Magento-specific integrations. Most major platforms have Magento extensions, but configuration and data sync verification takes time.

Analytics. Google Analytics 4, Google Tag Manager, and any other tracking needs to be reconfigured. Verify that ecommerce tracking (purchase events, add-to-cart events, product impressions) fires correctly on Magento. Data layer structures differ between platforms.

Timeline and budget

Migration timelines depend on catalog size, customization complexity, and integration requirements. Here are realistic ranges based on our experience.

Timeline by complexity

Complexity	Catalog Size	Integrations	Custom Features	Timeline
Simple	Under 1,000 SKUs	3-5 standard	Minimal	8-12 weeks
Moderate	1,000-10,000 SKUs	5-10 including ERP	Some custom	12-20 weeks
Complex	10,000-100,000 SKUs	10+ with deep ERP	Significant custom	20-36 weeks
Enterprise	100,000+ SKUs	Complex multi-system	Heavy custom	36-52+ weeks

Budget ranges

Component	Simple	Moderate	Complex
Discovery and planning	$3,000-$5,000	$5,000-$15,000	$15,000-$30,000
Data migration	$5,000-$10,000	$10,000-$25,000	$25,000-$60,000
Theme/frontend	$10,000-$20,000	$20,000-$50,000	$50,000-$150,000
Integration rebuild	$5,000-$15,000	$15,000-$40,000	$40,000-$100,000+
Testing and QA	$3,000-$5,000	$5,000-$15,000	$15,000-$40,000
SEO migration	$2,000-$5,000	$5,000-$10,000	$10,000-$25,000
Total	$28,000-$60,000	$60,000-$155,000	$155,000-$405,000+

Ongoing costs. Magento has higher ongoing costs than BigCommerce. Budget for hosting ($200-$2,000+/month), security patches (quarterly), performance monitoring, and development support. Adobe Commerce licensing adds $22,000-$125,000+/year depending on revenue tier.

Step-by-step migration phases

Phase 1: Discovery and planning (2-4 weeks)

• Audit current BigCommerce store completely – catalog, customers, orders, integrations, customizations, content
• Document every business requirement that Magento must satisfy
• Create detailed URL mapping document
• Define Magento architecture – hosting, caching, search, CDN
• Plan attribute sets and product type mapping
• Identify Magento extensions needed to replace BigCommerce apps
• Create project timeline with milestones and responsibilities

Phase 2: Magento environment setup (1-2 weeks)

• Provision staging and production hosting infrastructure
• Install and configure Magento (Open Source or Adobe Commerce)
• Configure base store settings – tax, shipping, payment, currency, locale
• Install required extensions
• Set up development and deployment workflows
• Configure URL structure to minimize redirect requirements

Phase 3: Theme development (3-8 weeks, parallel with Phase 4)

• Design or adapt storefront design for Magento
• Build theme – homepage, category pages, product pages, CMS pages, checkout
• Implement responsive design and cross-browser testing
• Configure Page Builder blocks and templates (Adobe Commerce)
• Optimize frontend performance – image lazy loading, critical CSS, JavaScript bundling

Phase 4: Data migration (2-4 weeks, parallel with Phase 3)

• Build data extraction scripts for BigCommerce API
• Build data transformation layer
• Build import scripts or configure migration tool
• Run first migration on staging
• Validate all data – products, customers, orders, categories
• Fix edge cases and data quality issues
• Run second migration on staging
• Final validation

Phase 5: Integration rebuild (2-6 weeks)

• Set up and configure each integration on Magento
• Test each integration independently
• Test integrations together (integration conflicts are common)
• Verify data flows – orders to ERP, inventory updates, pricing sync, customer data
• Load test critical integration pathways

Phase 6: Testing and QA (2-4 weeks)

• Functional testing – every page type, every feature, every workflow
• Payment testing – all payment methods, refunds, partial payments
• Performance testing – page load times, concurrent user handling, search performance
• SEO testing – redirects, meta data, canonical tags, structured data, sitemap
• Mobile testing – responsive layout, touch interactions, mobile checkout
• Security testing – PCI compliance, admin access controls, API security
• User acceptance testing with stakeholders

Phase 7: Pre-launch preparation (1 week)

• Final data migration rehearsal with timing documentation
• DNS change preparation
• CDN configuration
• SSL certificate setup
• Monitoring and alerting configuration
• Rollback plan documentation
• Customer communication preparation (password reset, new features)
• Team training on Magento admin

Phase 8: Launch (1-3 days)

• Final data migration (products, customers, recent orders)
• DNS cutover
• SSL verification
• Redirect testing (spot-check critical URLs)
• Payment processing verification with live transactions
• Integration verification (live data flowing correctly)
• Monitoring – error rates, page load times, conversion tracking

Phase 9: Post-launch stabilization (2-4 weeks)

• Daily monitoring of Search Console for crawl errors and indexing issues
• Daily review of error logs and exception reports
• Customer feedback monitoring and rapid response
• Performance optimization based on real traffic patterns
• Integration fine-tuning based on live data volumes

Post-migration priorities

The first 30 days after migration determine whether the project is a success or a headache.

SEO monitoring. Check Google Search Console daily. Watch for spikes in crawl errors, drops in indexed pages, or increases in 404 responses. If you see ranking drops, verify redirects for the affected pages immediately. Some ranking fluctuation is normal during migration – Google needs to recrawl and reprocess your site. Sustained drops indicate a redirect or content problem.

Performance optimization. Real traffic patterns will reveal performance issues that staging testing did not catch. Monitor server response times, database query performance, and full page load times. Common post-migration performance issues include unoptimized images, missing full-page cache configuration, slow third-party scripts, and database queries that perform differently at production data volumes.

Customer support preparation. Expect increased customer service contacts during the first two weeks. Common issues include password reset confusion, changed navigation or checkout flow, missing order history, and integration-related problems. Prepare your support team with migration-specific documentation.

Analytics verification. Verify that all tracking is working correctly with real data. Check ecommerce conversion tracking, event tracking, and attribution data against actual orders. Analytics discrepancies found early are easy to fix – found months later, you have a gap in your data.

Common migration mistakes

These are mistakes we have seen repeatedly across migration projects. Avoid all of them.

Underestimating URL migration. The most common SEO disaster. Every URL change without a proper redirect is a potential ranking loss. Map every URL. Test every redirect. Check for redirect chains (multiple hops). Verify redirects with actual crawl data, not just spot checks.

Ignoring customer password migration. You cannot migrate passwords between BigCommerce and Magento. If you do not proactively communicate this to customers and provide a seamless password reset flow, you will lose customers who think their account was deleted. Send the password reset email before or immediately at launch.

Launching with broken integrations. Test every integration with live-equivalent data volumes, not just a handful of test orders. An ERP integration that works with 5 test orders may fail when processing 500 real orders per day. Run volume tests.

Skipping the staging migration rehearsal. Running your first complete data migration on launch day is reckless. Run the full migration on staging at least twice. Time it. Document problems. Fix them. Your production migration should be a rehearsed, predictable process.

Not budgeting for post-launch development. The migration project does not end at launch. Budget 20-30% of your migration budget for post-launch fixes, optimizations, and feature additions that only become apparent with real traffic and real customers.

Choosing Magento without the team to support it. Magento requires ongoing technical maintenance – security patches, performance tuning, extension updates, server management. If you do not have an in-house team or a committed agency partner for ongoing support, you will struggle after the migration team moves on.

Treating migration as a 1:1 feature port. The goal is not to recreate your BigCommerce store on Magento. The goal is to build the best possible store on Magento, informed by what worked on BigCommerce. Take the opportunity to improve workflows, simplify features that were over-engineered, and take advantage of Magento capabilities that BigCommerce did not offer.

Frequently asked questions

How long does a BigCommerce to Magento migration take?

Typical migrations take 12-24 weeks from project kickoff to launch, depending on catalog complexity, integration requirements, and custom feature scope. Simple stores with under 1,000 SKUs and minimal integrations can complete in 8-12 weeks. Complex enterprises with large catalogs and deep ERP integrations should plan for 6-12 months.

Will I lose my Google rankings during migration?

You should not lose rankings if URL migration and redirects are handled correctly. Implement proper 301 redirects for every URL change, transfer all metadata, and submit an updated sitemap. Some temporary ranking fluctuation is normal as Google recrawls and reprocesses your site – this typically stabilizes within 2-6 weeks. The most common cause of ranking loss is missing or incorrect redirects.

Can I migrate my customer passwords from BigCommerce to Magento?

No. BigCommerce and Magento use different password hashing algorithms, and neither platform exposes raw password data. Every customer will need to reset their password on the new platform. Plan a proactive communication campaign – send an email before launch explaining the change and providing a simple password reset link. Some Magento extensions can handle “lazy migration” where customers are prompted to reset on first login.

Should I choose Magento Open Source or Adobe Commerce?

Magento Open Source is free to use and provides the core ecommerce functionality. Adobe Commerce adds B2B features (company accounts, shared catalogs, negotiable quotes, purchase orders), cloud hosting, Page Builder, customer segmentation, and enterprise support. If you are migrating for B2B capabilities, Adobe Commerce is likely the right choice. If your needs are primarily B2C with custom development, Open Source with targeted extensions may be more cost-effective.

How much does BigCommerce to Magento migration cost?

Total project costs typically range from $30,000 for simple stores to $400,000+ for complex enterprise migrations. This includes discovery, data migration, theme development, integration rebuild, and testing. Ongoing costs after migration include hosting ($200-$2,000+/month), Adobe Commerce licensing ($22,000-$125,000+/year if applicable), and development support. See the detailed budget breakdown earlier in this guide.

Can I run BigCommerce and Magento simultaneously during migration?

Yes, and we recommend it. Keep your BigCommerce store live and fully operational while building and testing on Magento staging. Only cut over to Magento when the new store is fully tested and ready. During the cutover window, you will need to migrate any orders and customer data that were created on BigCommerce after your last data migration sync.

What happens to my BigCommerce apps and integrations?

Each BigCommerce app needs a Magento equivalent. Most major services (Klaviyo, Yotpo, ShipStation, Avalara) have Magento extensions. Some BigCommerce-specific apps may not have direct Magento equivalents – you will need to find alternative solutions or build custom functionality. Audit all apps and integrations during the discovery phase.

Is Magento harder to manage than BigCommerce?

Yes. Magento requires more technical management – server administration, security patches, performance optimization, and extension compatibility management. BigCommerce handles all of this as part of the SaaS platform. This is the fundamental tradeoff: you gain complete control and flexibility but take on the operational responsibility that comes with it. You need either an in-house technical team or a reliable agency partner for ongoing Magento management.

Should I consider Shopware instead of Magento?

Possibly. Shopware 6 offers a modern, API-first architecture with strong B2B capabilities and a more approachable codebase than Magento. If your primary migration drivers are B2B features and backend flexibility, Shopware deserves evaluation. It is particularly strong for businesses that want the customization of open source with a more modern development experience. See our Shopware B2B guide for a detailed look at its capabilities.

How do I handle multi-currency if I am using BigCommerce’s multi-currency feature?

Magento supports multi-currency natively through its store view architecture. Each store view can have its own currency with automatic conversion rates or manually set prices. If you need currency-specific pricing (not just converted), Magento’s website-level price scoping handles this. Configure currency settings and exchange rate sources during the environment setup phase.