Migrate from BigCommerce to Magento Open Source

Migrate from BigCommerce to Magento Open Source: what the move involves

If your renewal, lock-in or data residency concern is pushing you toward Magento Open Source, the first thing to know is that the catalog moves through the Catalog API, while faceted search, B2B pricing and multi-storefront must be rebuilt or configured on Magento rather than carried over as-is. The Catalog API covers products, categories, brands, bulk pricing rules, variants, images, custom fields and metafields, so extraction is a scripted job. The harder work is mapping what those fields mean inside Magento's attribute model, catalog price rules and store views, and deciding which BigCommerce storefront behaviors you keep.

In most projects the work sits with an in-house platform team that owns the store after launch, often with an implementation partner for the migration, extension selection and hosting build. Your team should expect to own the decisions on attribute design, tier pricing for B2B accounts, and how each storefront maps to a store view and website. Plan for the effort to come from three places: data extraction and validation, rebuilding the features BigCommerce provided through apps or built-in settings, and the storefront and checkout work. Ask any partner to show a written scope that names each of these, since the effort varies widely with catalog size and the number of extensions you need.

Magento Open Source is software you run, patch and host yourself. Adobe's release schedule shows the 2.4.x line receives full patches once a year in May and security patches at least annually for supported lines, and Adobe's lifecycle policy gives each 2.4.x release three years of standard support, so you must plan regular upgrades onto supported versions. The stack has specific requirements (PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, nginx and Varnish for self-managed installs), and Adobe supports only listed combinations. Confirm the current versions on Adobe's system requirements page before you size infrastructure, and confirm with your team who will own patching and PCI DSS scope on the hosting side.

Which BigCommerce capabilities map cleanly to Magento Open Source

This table compares the main BigCommerce capabilities with what Magento Open Source provides in its core, and marks each as clean, needs rework or gap. Use it to decide which features you can move as-is, which need custom development or extensions, and which need a decision about Adobe Commerce or a third-party alternative. Confirm each row against your own requirements and the extensions you plan to use before you commit.

Capability	Magento Open Source fit	What to confirm or plan
Catalog products and variants	Clean	Confirm that your variant structure fits Magento configurable and simple products, and map SKUs before extraction
Categories and brands	Clean	Brands are not a core entity, so plan an attribute or extension for brand pages and filters
Images	Needs rework	Download images from public URLs and re-import them; check file names and alt text during mapping
Custom fields and metafields	Needs rework	Map each field to a Magento product attribute with the correct input type and scope
Bulk pricing rules	Needs rework	Core catalog price rules and tier pricing differ from BigCommerce rules; test discounts against your existing scenarios
Customers and customer groups	Clean	Import accounts and groups, then plan a password reset path because hashes may not transfer
Orders and order history	Needs rework	Historical orders usually move as reference data rather than as fully editable Magento orders; confirm with your team
Multi-storefront and multi-currency	Needs rework	Store views and websites cover many cases, but multi-currency setup and per-market catalogs need careful configuration
Faceted search	Needs rework	Layered navigation needs OpenSearch tuning and attribute configuration; confirm the filtering behavior you need
B2B features such as company accounts and quotes	Gap	Core Open Source covers basic ecommerce only; company accounts and requisition features need extensions or Adobe Commerce
Checkout	Needs rework	Checkout is customizable, but payment, tax and shipping integrations must be rebuilt and tested
Apps and integrations	Gap	Each BigCommerce app needs a matching extension, a custom build or a retired process; inventory them first

What data moves, and which integrations you rebuild

BigCommerce data can be pulled programmatically, but only some of it arrives in Magento Open Source as-is. Catalog data moves through the API, while customers, orders, images and every connected service need a deliberate path and a rebuild plan.

Catalog data through the Catalog API

The Catalog API covers products, categories, brands, variants, custom fields, metafields and bulk pricing rules, which gives you a programmatic extraction path. Map each BigCommerce object to a Magento product type, attribute set, category tree or tier price before writing any import script. Bulk pricing rules rarely map one to one, so confirm with your merchandising team how each rule should behave in Magento before you build it. Run a test extraction of a few categories first to check field coverage.

Plan rate limits on extraction

Catalog API calls count against the rate limits set by your BigCommerce plan, so a large catalog with variants and images can take many paged requests. Build the extractor to read limit headers, back off when told to, and checkpoint progress so a failed run resumes instead of restarting. Confirm current limits for your plan in BigCommerce's documentation and in your own account, because they can change. Schedule a full extraction during a low-traffic window and keep the source store live until the final delta run.

Product images must be re-hosted

Image files are not carried over by a data export, so you need to download each image from its source URL and store it in your Magento media directory. Keep a mapping file from BigCommerce image IDs to new file paths so product galleries, thumbnails and any external links can be checked after import. Plan storage for the full image set on your own servers or object storage, and confirm that your image processing and CDN choices handle the resized variants Magento generates. Verify a sample of products against the live store before cutover.

Customers and orders from exports

Customer and order records usually come from BigCommerce exports or API calls, and they need field mapping into Magento's customer and sales order structures. Password hashes generally cannot be moved between platforms, so plan a password reset or account claim flow for returning shoppers. Keep historical orders in a read-only archive if your finance or returns teams need them, and confirm with your legal team how long personal data must be retained and where it is stored.

Payment, tax and shipping integrations

Payment gateways, tax calculation, shipping carriers and ERP connections do not transfer from BigCommerce. Each one must be rebuilt as a Magento payment method module, tax or shipping integration, or middleware connector, and each needs its own test plan, credentials and PCI DSS scope review. Ask each provider whether they publish a Magento extension and whether it is maintained for the Magento version you will run. Treat these as separate workstreams with their own owners and sign-off.

Apps and custom checkout logic

Each BigCommerce app and every custom script must be inventoried, then either replaced by a Magento extension or rebuilt as a custom module. Document what each app does, which data it reads and writes, and which storefront pages it touches. Custom checkout logic and webhooks need the most attention because they affect order integrity. Use the Magento versions and PHP requirements in the release documentation to select extensions that match your target line, and keep a registry of the decisions for audit evidence.

Migration sequence from inventory to decommission

This sequence moves a BigCommerce store to Magento Open Source in controlled stages, so each change is tested before it reaches customers. Each step ends with a named artifact that the next step depends on, and BigCommerce stays live until the new store has been verified in production.

Inventory apps, integrations and data
List every BigCommerce app, custom script, webhook, payment gateway, shipping rate source, ERP or CRM connection and feed that touches the store. For each item, record the business owner, what data it reads or writes, and whether Magento Open Source needs an extension, a custom module or a replacement service. Include catalog size, customer groups, B2B company accounts, bulk pricing rules, custom fields and metafields, multi-storefront setups and the URL structure you must preserve. The output is an inventory register with a disposition (keep, replace, retire) for each entry, signed off by the merchant and the technical owner.
Extract a catalog sample and pilot the import
Use the BigCommerce Catalog API to pull products, variants, categories, brands, images, bulk pricing rules, custom fields and metafields for a representative subset of the catalog. Write the extraction scripts so they page through results and respect the plan's rate limits, and store raw JSON so it can be replayed. Import the sample into a staging Magento Open Source instance running the same PHP, MySQL or MariaDB, OpenSearch and Redis versions planned for production. The output is a pilot import log listing every record that failed, with the error reason, and a list of the Magento attributes each source field was mapped to.
Map data and reconcile counts
Write the data mapping document that links each BigCommerce object to its Magento equivalent: product types, configurable options, tier and catalog price rules for bulk pricing, customer groups, company accounts for B2B, categories and URL keys. Run a full extraction into staging and reconcile counts and totals per object type against the source, including product counts, prices, stock, customer records and open orders. Store images separately, since image URLs must be downloaded and re-associated. The output is a mapping document and a reconciliation report with each discrepancy either fixed or accepted in writing.
Build the storefront, checkout and integrations on staging
Install and configure the extensions selected in the inventory, apply the theme, configure payment and shipping methods, and connect the ERP, CRM and fulfillment integrations to the staging instance. Test checkout end to end for guest, registered, B2B and multi-storefront scenarios, and check full-page cache behavior, since self-managed installations use Varnish and cloud installations use Fastly. Verify Content Security Policy headers on payment pages. The output is a test report with each scenario, the expected result, the actual result and the defect ticket for any failure, plus a go or no-go recommendation from the technical lead.
Run a parallel period with both stores live
Keep BigCommerce open for customers while Magento runs in staging or a restricted preview, and repeat the extraction on a schedule so changes made in BigCommerce are carried into Magento. Compare orders, inventory and pricing between the two stores each cycle, and confirm that payment and fulfillment connections behave identically. Do not send live traffic to Magento until the reconciliation shows no unexplained differences. The output is a parallel-run log that records each sync, each difference and its resolution, and a dated sign-off from the merchant to proceed.
Cut over DNS and redirects
Prepare a redirect map from every indexed BigCommerce URL to its Magento equivalent, and test a sample of those redirects on staging. Lower DNS time-to-live values in advance, freeze catalog and customer changes during the final extraction, run the last delta sync, and point traffic to the Magento store. Monitor error logs, redirect hits, payment transactions and search console reports immediately after the switch. The output is a signed-off cutover runbook listing each step, its owner and its rollback action, and a post-cutover checklist that records the results of each check.
Decommission BigCommerce after verification
Keep the BigCommerce store in read-only form and export final order, customer and catalog archives for record keeping and compliance retention. Revoke API tokens, remove webhooks and app connections, cancel payment gateway links that are no longer used, and confirm with the BigCommerce plan terms what happens to the account at closure. Keep the archive and the reconciliation reports available for the retention period your policies require. The output is a decommissioning record that lists each revoked credential, each cancelled service and the location of the archived data, approved by the owner of the store.

What the self-hosted Magento stack requires

Start by choosing the Magento Open Source release line, because the requirements and support window depend on it. Adobe's 2.4.9 system requirements list PHP 8.5, MySQL 8.4 or MariaDB 12.3 (recommended) or 11.8, OpenSearch 3, Redis or Valkey 9, RabbitMQ 4.3, Composer 2.10 and nginx 1.30, all on Linux x86-64. Adobe supports only the listed combinations, so a component one version off from the table is outside support even if the store appears to run. Build the server image from that matrix, not from a generic LAMP guide. For 2.4.8, the 2.4.8-p5 requirements list PHP 8.4 or 8.3, MySQL 8.4 or MariaDB 11.4 or 11.8, OpenSearch 3, Redis or Valkey 8.1, RabbitMQ 4.3, Composer 2.10, nginx 1.30 and Varnish 8.

Confirm the support window before you commit to a line. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability. The end of regular support for 2.4.9 is May 31, 2029, and for 2.4.8 it is May 31, 2028. Check the current dates in the lifecycle policy before signing off, because the migration project will run for months and a line that ends support during go-live forces a second upgrade. Adobe's release schedule describes annual full patches for the 2.4.x LTS line in May, so plan a recurring upgrade window and budget for it.

Decide early how full-page caching will work. Adobe documents Varnish as the full-page cache accelerator for self-managed installations, which means your team or your partner must configure, tune and patch it. Cloud-hosted Adobe Commerce uses Fastly instead, so the caching design differs if you later move to that edition. Also check Content Security Policy behavior: Magento Open Source supports CSP headers from 2.3.5, and from 2.4.7 CSP runs in restrict mode by default on storefront and admin payment pages. Any third-party payment or analytics script that was loaded freely on BigCommerce must be listed in the policy, or it will be blocked at checkout. Test that path on the target release before launch.

What drives cost and duration in this migration

This table lists the factors that move cost and effort when moving a BigCommerce store to self-hosted Magento Open Source, with a note on how to contain each one. Read each row as a question to answer before you accept a quote, and use the last column to see what to request in writing. No fees or durations are given because the scope of each store decides them.

Driver	Why it moves cost or effort	How to keep it down and what to request in a quote
Catalog size and variant count	Each product, variant, image and custom field must be extracted through the Catalog API, transformed and imported into Magento's attribute and configurable product model. Variant-heavy catalogs multiply mapping and validation work.	Clean up duplicate SKUs and unused options before extraction. Ask the quote to state product, variant and image counts and how image files are transferred.
Bulk pricing rules	BigCommerce bulk pricing rules must be translated into Magento catalog price rules, tier prices or customer group prices. Rules with overlapping conditions need manual testing against sample carts.	Inventory every rule and retire inactive ones first. Request a written mapping table showing each BigCommerce rule and its Magento equivalent, plus a test plan for overlaps.
B2B account structures	Company hierarchies, shared carts, approval flows and customer-specific price lists are not a one-to-one match for a stock Magento install. Adobe Commerce ships B2B features that Magento Open Source does not include, so custom modules or third-party extensions may be needed.	Confirm which B2B functions the store uses today. Ask the quote to list each one, state whether it is built, extended or bought, and name who maintains it after launch.
Number of storefronts	Each storefront or store view adds theme work, catalog scope settings, pricing scope, tax and shipping configuration, and separate SEO checks. Multi-storefront setups multiply testing.	Limit storefronts to genuinely distinct brands or markets. Request a list of storefronts, currencies, languages and the scope of each price list.
Custom fields and metafields to map	BigCommerce custom fields and metafields need target attributes in Magento. Free text fields, data types and attribute sets that do not match cause rework during import and in the storefront.	Build a field inventory with owner, data type and whether the field drives search, filters or checkout. Ask the quote to show the attribute map before import begins.
Extension selection	Each extension adds licensing, installation, compatibility checks against the current Magento release and ongoing patching. Replacing BigCommerce apps with Magento extensions is often where scope grows.	Map each BigCommerce app to a required, replaceable or unneeded status. Ask for the list of extensions, their license terms, the Magento versions they support and who handles updates.
Hosting architecture	A self-managed Magento stack has PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ, nginx and Varnish in self-managed installations. Adobe publishes the supported combinations, and each extra service adds hosting, monitoring and backup responsibility.	Use the combinations listed in Adobe's system requirements for your target release and avoid unsupported versions. Request a diagram of the environments, the backup and restore approach and who operates each service.
PCI DSS scope and payment integration	Self-hosting makes your organization responsible for the parts of the environment that handle cardholder data, and the scope depends on how payments are integrated. Hosted payment fields can reduce scope compared with server-side card handling.	Decide the payment model before design starts. Ask the quote to state how cardholder data flows, which PCI DSS requirements the work touches and what evidence will be delivered to your assessor.
Upgrade cadence	Magento Open Source releases move along Adobe's support lifecycle, so each minor line has a finite support window. Each upgrade retests extensions, theme code and custom modules, and the cost recurs for the life of the store.	Pick a supported release line with a known end-of-support date. Ask for a written upgrade plan covering patch cadence, test environments, extension compatibility checks and who performs each upgrade.

What usually goes wrong and how to prevent it

Most failed BigCommerce to Magento Open Source migrations break in the same few places: URLs, images, pricing, extensions, payments and patching. Each card below names one failure point and the check that prevents it before cutover.

Lost SEO URLs without redirects

Magento generates its own URL rewrites, so product and category paths from BigCommerce will not survive unless you map them. Export the existing URL list from BigCommerce, create a matching URL key for every product and category, and generate a 301 redirect for each old path. Crawl the old site and confirm every indexed URL returns a single redirect to a live page before you switch DNS.

Incomplete image transfer

CSV exports on comparable platforms do not carry product images, so image files must be fetched separately. Confirm in the BigCommerce Catalog API whether image records return the URLs you need, then test a sample of products with multiple images and variant-specific photos. Plan for missing or renamed files, and verify image counts per SKU in Magento after import.

Bulk pricing rules that do not map

BigCommerce bulk pricing rules are quantity-based tiers that may not translate directly to Magento tier prices, catalog price rules or customer group pricing. Document each rule, decide which Magento mechanism replaces it, and test cart totals for quantities at each tier boundary. Expect some rules to need custom code or a pricing extension, and confirm that choice in writing before build starts.

Extension gaps for B2B and multi-storefront

B2B features such as company accounts, quotes, negotiated pricing and multi-storefront setups are often delivered by BigCommerce apps or built-in settings, while Magento Open Source relies on extensions or custom development. List every B2B and multi-site feature in use, then confirm which Magento Open Source options cover it and which need Adobe Commerce or custom work. Do not assume parity until a test store proves it.

Untested payment and tax flows

Payment gateways, tax rules and shipping methods are the parts customers notice first when they fail. Test each gateway in sandbox mode with the same cart types used in production, including refunds, partial captures, multiple tax zones and discounts. Confirm with your payment provider which integration module is supported on the Magento version you choose, and keep card data handling within the provider's hosted fields where possible.

Patch neglect after go-live

Magento Open Source is software you run and patch yourself, and each 2.4.x line has a fixed support window. Choose a supported release line at the start, record its end-of-support date, and schedule patch reviews into operations from day one. Track PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey and nginx versions against the system requirements for your chosen release, because unsupported components are a common source of security gaps.

How the migration differs by starting point

In an illustrative single-storefront case, the merchant runs one currency, one storefront and a catalog where most products have few variants and simple prices. The migration is mostly a data move: extract products, categories, images and customers through the Catalog API, then load them into Magento Open Source. The main decisions are about hosting and which search and caching services to run, not about the data model.

Catalog extraction: Confirm the number of products and variants, then decide whether a script or the export route is enough for the volume.
Theme rebuild: Expect a new Magento theme rather than a copy of the BigCommerce theme, which is the largest visual task.
Search and cache: Plan OpenSearch and Varnish for a self-managed installation, since these are not optional extras for a production store.
Redirects: Map every old BigCommerce URL to its new Magento URL to protect search rankings.
Scope of work: Ask for a written scope that lists which of these items are included in a fixed-scope engagement.

Before committing, confirm that the storefront needs no B2B or multi-store features that would change the design.

How to run both stores in parallel and cut over safely

The safest cutover keeps BigCommerce live as the system of record until Magento Open Source has reconciled product counts, prices, customer logins and order history. Start by agreeing on a reconciliation sheet with the team: for each entity type, record the count in BigCommerce, the count in Magento, and the list of exceptions. Pay particular attention to bulk pricing rules, which BigCommerce stores against product and customer group, because Magento's tier prices, catalog price rules and customer group pricing do not map one to one. Sample real orders and log in with real customer accounts on the staging instance to confirm that password hashes, addresses and group assignments came across correctly. Confirm the exact sync approach (one-time reimport, scheduled delta extraction through the Catalog API, or a mix) with your implementation partner and your own engineers before the first import run, because it determines how much rework the overlap window creates.

During the overlap, decide who may change data in each system and write that rule down. The usual pattern is that the catalog and prices are edited in one system only, with any change in the other treated as a defect. Orders placed in BigCommerce after the last extraction must be carried into Magento before go-live, so plan a final delta run that covers orders, customers and inventory changed since the previous pass. Test the delta job against a copy of production data, and confirm how it handles deleted products, since a deleted product can still appear in search indexes or sitemaps.

On cutover day, freeze the catalog in BigCommerce before the final extraction so that no price or stock change happens between the last sync and the DNS or routing switch. Put 301 redirects in place for every URL that changed structure, and check them against the URL list exported from BigCommerce, not only against the top sellers. After the switch, monitor Magento's search index status, the Elasticsearch or OpenSearch cluster health, checkout completion, payment gateway callbacks and error logs for the first business cycle. Keep the BigCommerce store readable and its payment integration disabled for a period your team agrees in advance, so that a rollback remains possible and any late order can be recovered.

Questions merchants ask before moving to Magento Open Source

What does a migration from BigCommerce to Magento Open Source cost?

The cost is driven by the work, not by a license fee for the core software. The main components are the catalog extraction and transformation, mapping bulk pricing rules and custom fields to Magento's model, the theme rebuild, extension selection and configuration, hosting and infrastructure, the payment and search integrations, testing, and cutover. Some of this is one-time (migration, theme, data mapping) and some recurs (hosting, extension subscriptions, patching, support). Ask any provider for a quote that separates these lines, names who performs each task, and states which extensions are assumed. Your own BigCommerce plan fees stop at cutover, but you take on hosting and maintenance costs that BigCommerce carried for you.

How long does a BigCommerce to Magento Open Source migration take?

The timeline depends on drivers you can measure before work starts: the number of products, variants and images, how many bulk pricing rules and custom fields need mapping, how many BigCommerce apps must be replaced, whether B2B company accounts and multi-storefront setups are in scope, and how much of the theme is rebuilt. Customer and order history volume and the number of integrations with ERP, tax or fulfillment systems also matter. Ask for a written plan with phases and a parallel-run period before cutover, and confirm which items the provider counts as in scope.

What does the merchant team need to provide?

The work needs a named business owner who can decide on catalog structure, pricing rules, tax and shipping logic, and which customer groups are kept. Your technical team needs API access to BigCommerce, admin rights for the new environment, access to DNS and certificates, and a point of contact for payment and shipping providers. Merchandising staff must check imported product data and redirect mappings. Plan for these people to be available during testing, not only at kickoff.

Can our own team do the migration without a partner?

A capable in-house team can run a migration if it has PHP and Magento experience, has operated a Linux stack with MySQL or MariaDB, OpenSearch, Redis or Valkey, RabbitMQ and a full-page cache, and can own the upgrade cycle. Key risks are the catalog extraction through the Catalog API within your plan's rate limits, price rule mapping, SEO redirects and payment compliance. Many teams split the work: they handle data and business decisions while an implementation partner handles the platform build and hardening. Decide this based on the skills you have, not on cost alone.

Is Magento Open Source free to license, and what do OSL-3.0 terms mean?

Magento Open Source source files are licensed under the Open Software License 3.0 (OSL-3.0), with AFL 3.0 also included in the distribution, so there is no license fee for the core software. OSL-3.0 lets you use, modify and run the code, but it carries obligations if you distribute modified versions, and you should have counsel review them for your case. Extensions are licensed separately by their authors, so check each extension's license and whether it carries a subscription. Contributors must sign the Adobe Contributor License Agreement before submitting code.

How does Adobe Commerce differ from Magento Open Source?

Adobe Commerce is the paid, full-featured edition of Magento, while Magento Open Source is the free core. Adobe positions Adobe Commerce with cloud hosting and AI merchandising, and it is sold through Adobe rather than under an open license alone. In practice, Magento Open Source leaves more to you: hosting, caching design, and the feature set you add through extensions. Confirm with Adobe which features you need and whether they are in the open-source edition, because some capabilities differ between the two. Mage-OS is a community distribution you can also evaluate.

Who applies security patches to a self-hosted Magento store?

You do. With Magento Open Source running in your own infrastructure, your team or your provider applies Adobe's security patches, minor releases and the annual LTS patch line. Adobe's lifecycle policy gives each 2.4.x release three years of standard support from general availability, and Adobe states that security patches are released at least annually for all supported lines. Set a patch calendar, test patches in staging, and confirm that your PHP, OpenSearch, database and cache versions remain on Adobe's supported list. Ask any provider for their patch and support scope in writing.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from BigCommerce to Magento Open Source, we start with a written scope that names the catalog, customer, order and feature parity work in your store, then build and test the new store against it.

How we scope

Inventory BigCommerce products, variants, bulk pricing rules, custom fields and metafields before any build starts.
Agree in writing which faceted search, B2B pricing and multi-storefront features must match, and which will change.
Confirm the Magento Open Source release line, PHP, MySQL or MariaDB, OpenSearch, Redis or Valkey and hosting target with you.

How we build

Extract the catalog through the Catalog API within your plan's rate limits, then map records into Magento attributes and price rules.
Select and review each extension for maintenance status, license terms and fit, and document any custom code you own.
Test catalog import, checkout, redirects for existing URLs and cache behavior on a staging environment before cutover.

How we hand over

Deliver architecture notes, configuration records, runbooks for indexing, cache and queue services, and the migration log.
Document the mapping from each BigCommerce feature to its Magento equivalent, including items that were dropped or rebuilt.
Walk your operations and engineering teams through patching, backups and the release schedule so they can run the store.

How we support

Offer ongoing support, upgrades and continuous security testing as a retainer after go-live.
Plan Magento patch and minor upgrades against Adobe's published lifecycle dates, with testing in staging first.
Prepare system and configuration evidence for compliance assessments, while independent auditors issue any reports or certifications.

Migrate from BigCommerce to Magento Open Source