Migrate from BigCommerce to Shopware: what the move involves
If your BigCommerce renewal, pricing change or data residency requirement is forcing a decision, be clear about the work first: moving to Shopware 6 is a catalog, customer, app and theme rebuild, run as a parallel run where the old store stays live until the new one has been checked against it. Plan for the store to operate in both places for a period, rather than planning a single cutover weekend. Most teams do this work with an internal platform or e-commerce team working alongside an implementation partner. The internal team owns the business rules, product data, tax and shipping decisions and sign-off, while the partner usually handles the export scripts, the Shopware installation, plugin selection, theme work and testing. Effort and risk concentrate in three places: mapping BigCommerce apps and custom checkout logic to Shopware plugins, rebuilding the storefront theme, and reconciling order and customer data so that logins and open orders behave correctly on day one. Ask any partner to show a written scope listing each of these items. Shopware 6 is licensed under the MIT License, and its pricing page says it can run as SaaS, as PaaS on managed infrastructure or self-hosted, so self-hosting is one of several deployment choices rather than the only route. Before you commit, confirm with Shopware which plan applies to your gross merchandise value, because the free Community Edition does not cover shops above the threshold described on its pricing page. Also confirm that the plugins you need exist and are maintained for the Shopware line you intend to run.
Which BigCommerce capabilities map to Shopware, and what needs rework
This table maps common BigCommerce capabilities to their closest Shopware 6 equivalents and marks each row as clean, needs rework or gap. Read it as a planning checklist: a clean row still needs a test, and every B2B and plugin row must be confirmed against the current Shopware plugin store and the Shopware pricing page before you assume parity.
| Capability | Shopware 6 position | Status |
|---|---|---|
| Products and variants | Shopware supports products with variant options and property groups. Map BigCommerce SKUs, options and variant combinations during import and test complex matrices. | Needs rework |
| Categories and navigation | Category trees and menus can be rebuilt in the admin. Keep the BigCommerce category paths in a redirect map so URLs and rankings carry over. | Clean |
| Customers and addresses | Customer accounts and addresses import through CSV or the Admin API. Password hashes generally cannot be moved, so plan password reset emails for existing customers. | Needs rework |
| Bulk pricing rules | Shopware handles quantity-based pricing through product prices and rules. Rebuild each BigCommerce bulk rule and check it against the rule logic before go-live. | Needs rework |
| Storefront theme | BigCommerce themes use Stencil templates and do not carry over. Shopware themes are built on its Storefront, so the design and templates are rebuilt. | Gap |
| Checkout logic | Shopware provides its own checkout flow. Custom checkout steps, scripts and fields from BigCommerce must be rebuilt as Shopware plugins or configuration. | Needs rework |
| Apps and integrations | BigCommerce apps have no direct equivalent. Confirm coverage for each app in the Shopware plugin store, and budget custom development for anything missing. | Gap |
| Payments | Shopware Payments is included in the Community Edition with community support only. Confirm each gateway you use is supported before you move. | Needs rework |
| Multi-currency and tax | Shopware supports multiple currencies and tax rules per sales channel. Confirm the currency and tax configuration matches your BigCommerce setup. | Clean |
| B2B features | Shopware offers B2B functionality on its paid plans, including quotes and approvals on Evolve. Confirm which B2B features you need, such as company accounts and price lists, against the Shopware pricing page. | Gap |
What exports carry over and what you rebuild
BigCommerce data can usually be moved out through its export paths and the Catalog API, but the data is the easy part. Store behavior that lived in apps, custom fields and integrations has to be mapped and rebuilt on the Shopware side before you can switch traffic over.
Catalog data through the Catalog API
The Catalog API covers products, categories, brands, bulk pricing rules, variants, images, custom fields and metafields, so it is the programmatic route for pulling a full catalog. Export each object type separately and keep the BigCommerce product IDs and SKUs as a reference column, because category trees, variant option sets and redirects all depend on them. Confirm your plan's rate limits before a large pull, since a full catalog extraction can run for a long time.
Images need an explicit transfer plan
Product images do not travel inside a standard product file in a way you can assume. Decide whether images are downloaded from their BigCommerce URLs and re-uploaded into Shopware media, or referenced from the old host during cutover. Keep the BigCommerce store live until every image is confirmed in Shopware, and check alt text and sort order separately.
Custom fields and metafields need a mapping
Custom fields and metafields have no automatic equivalent in Shopware. Build a table that maps each BigCommerce field to a Shopware custom field set, property group or product attribute, and record the data type for each one. Fields that drive filters, pricing or product display need a test on the storefront, not just a row count check.
Customers and orders with clear scope
Customer records, addresses and order history can be exported and imported, but password hashes and payment tokens are generally not portable between platforms. Plan for customers to reset passwords, and keep historical orders in an archive for finance and returns. Ask Shopware and your payment provider which account and token data can be moved and which must be re-collected.
App data becomes Shopware plugins
Each BigCommerce app stores its own data and runs its own logic, such as reviews, shipping rules or loyalty points. Inventory every installed app, record what data it holds and what it does for shoppers, then assign each one to a Shopware plugin, an existing extension or an external service. Data owned by an app usually has to be exported from the app vendor or rebuilt, so ask vendors for their export options early.
Integrations and checkout logic to re-test
ERP, shipping, tax and payment integrations are typically wired to BigCommerce webhooks or APIs, which will stop firing once the store moves. List every integration and its trigger, then build a replacement and test it against both the old and new stores in parallel. Checkout rules, tax calculation and discount logic deserve the most test cases because errors there reach revenue directly.
How the catalog and customers move into Shopware 6
The extract, transform, import flow is the core of this section, and the order matters: pull the catalog out of BigCommerce first, reshape it to Shopware's data model second, and load products before customers so that customer records can reference a stable product set. Extraction can run through the Catalog API, which manages products, categories, brands, variants, images, custom fields and metafields, so it gives you a programmatic path for the full catalog. Plan the pull around your plan's API rate limits and confirm those limits in your own BigCommerce account before scheduling a large run. For smaller catalogs, a CSV export may be enough, but you should check which fields it carries before you rely on it.
The transform step is where most of the mapping decisions sit. Decide how BigCommerce variants and custom fields will become Shopware properties and options, and document the rule for each one: which values form a property group, which attributes are only display content, and which custom fields need to become product custom fields. Map bulk pricing rules deliberately, because they do not carry over as a single setting. Import products first, then customers, and keep customer identifiers in a reference table so orders and addresses can be linked later. Customer exports from BigCommerce should be checked for password handling, since most platforms require a reset flow rather than a password hash transfer; confirm this with your Shopware implementation partner before the import.
Verification is a separate phase, not a side effect of the import. Compare product counts, variant counts, category counts and customer counts against the source, and sample prices for each currency and customer group. Image migration and URL preservation are separate checks: confirm that every image has loaded from its source location and that every indexed product and category URL resolves to a matching page or a redirect. Keep the BigCommerce store live and unchanged until images and redirects are confirmed, because those are the items most likely to fail quietly after cutover.
The migration sequence, step by step
This sequence moves a BigCommerce store to Shopware 6 in controlled stages, so each change is inventoried, tested on staging and reconciled before customers see the new store.
Inventory apps, data and integrations
Your commerce lead and developer list every BigCommerce app, custom script, payment gateway, shipping rule, tax setting, webhook and third-party feed the store depends on, along with the data each one reads or writes. Record which Shopware 6 plugin, native feature or custom build will cover each item, and note anything with no equivalent so it can be scoped as custom work. Confirm current plugin availability in the Shopware marketplace and check the plan requirements on the Shopware pricing page. The step is done when you hold an app inventory that marks every item as replaced, rebuilt or retired, and each owner has signed off on it.
Build the field mapping spreadsheet
Map each BigCommerce field to its Shopware 6 counterpart, covering products, variants, option sets, categories, brands, customer groups, custom fields, metafields and SEO URLs. Use the BigCommerce Catalog API documentation to confirm which objects you can extract programmatically, and decide where custom fields become Shopware custom fields or properties. Agree the mapping with the people who own the catalog and pricing, because mismatched variant or tax logic is the most common source of errors later. The output is a mapping spreadsheet with a named owner for every row and an open-questions column that is empty before the pilot.
Run a pilot import on a staging store
Install Shopware 6 on a staging environment in your own infrastructure or managed hosting, then import a representative subset: a few products with variants, images, categories, one customer group and a sample of customers. Use the CSV export from BigCommerce for the structured data and review image handling separately, because image URLs must remain reachable during the import. Check the results in the admin and on the storefront, and log every rejected row with its cause. The step is done when the pilot records import with no unexplained errors and the mapping spreadsheet has been updated with every correction.
Import the full catalog and build the validated staging store
Repeat the import with the complete catalog, customers and open content, then rebuild the theme, checkout, payment and shipping configuration on staging. Test the flows that carry revenue: product search and filters, variant selection, price and tax calculation, cart, checkout, order confirmation emails, account login and password reset. Have the business owner test a scripted list of orders end to end. The output is a validated staging store with a signed test log, which is the reference you will reconcile against during cutover.
Run a parallel period and reconcile
Keep the BigCommerce store live while the Shopware store runs on staging or a limited preview, and compare counts and values between them: SKUs, stock levels, prices, customer records, open orders and tax totals. Investigate every difference and classify it as a data fix, a configuration fix or an accepted change. Shopify's own guidance to keep the original store live until images and data have imported is a useful pattern here, even though this migration uses BigCommerce as the source. The output is a reconciliation report with each discrepancy closed or accepted by a named owner.
Build the redirect map and cut over
Create a redirect map that links every indexed BigCommerce product, category, brand and content URL to its Shopware 6 destination, and test the redirects on staging before go-live. Schedule the cutover with a final delta export of orders and customers, freeze catalog changes on the old store, point DNS or the storefront to Shopware, and run the smoke-test list again on production. Monitor logs, payment callbacks and search console errors after launch. The step is done when the redirect map resolves on production, the smoke tests pass and the final delta has been reconciled.
Decommission the old store and record the outcome
Once the business has confirmed that orders, customer accounts and reporting are running correctly on Shopware, plan the BigCommerce shutdown with your contract owner. Export a final archive of orders, customers, tax records and product data for retention purposes, and confirm with your finance and legal teams which records must be kept and for how long. Revoke API credentials, webhooks and app connections. Write a decommission record that lists what was archived, where it is stored, who approved the shutdown and the date the subscription ended. Ask your BigCommerce account team to confirm the terms of data access after cancellation before you rely on any archive.
How the move differs by store size and starting point
A small catalog with few BigCommerce apps is usually the simplest starting point. The product list can often be exported through BigCommerce's built-in export tools, and the main effort goes into the theme, the checkout setup and a short list of plugin replacements. Shopware's Community Edition includes a visual page builder, product management and Shopware Payments, with community support only, so a store that uses only these features may need little paid tooling at the outset.
- Export scope: Confirm which product, customer and order files you can export without the Catalog API.
- Plugin mapping: List each installed BigCommerce app and check whether a Shopware plugin covers the same job.
- Theme work: Decide whether to rebuild the storefront or adapt a Shopware theme to your current design.
- Support needs: Community support is the only support included in the free edition, so decide who will fix issues after launch.
- Revenue watch: Track gross merchandise value over the preceding 365 days, since growth can change your license tier.
Confirm your current annual gross merchandise value and the list of active apps before you estimate scope.
A large catalog needs a programmatic extraction path. BigCommerce's Catalog API manages products, categories, brands, bulk pricing rules, variants, images, custom fields and metafields, so it provides a route for pulling catalog data when built-in exports are not enough. Extraction work includes mapping variants and custom fields to Shopware properties, handling image URLs, and running test imports before the production cutover.
- Rate limits: Plan your extraction windows around the API limits that apply to your BigCommerce plan.
- Variant mapping: Map option sets and variants to Shopware property groups and product variants before importing.
- Image handling: Images may need to be fetched from public URLs and re-attached, so schedule time for verification.
- Repeat runs: Plan at least one full test import and a delta import for changes made during the move.
- Tooling ownership: Decide whether your team or a partner writes and maintains the extraction scripts.
Ask for a sample extraction of your largest category so you can measure the mapping effort before committing to a full scope.
B2B-heavy stores often rely on negotiated pricing, company accounts, quotes and approval flows. Shopware's pricing page lists Evolve at 2,400 euros per month with B2B quotes and approvals and a 4-hour response time, which is the tier the page associates with these features. Stores that need these capabilities should compare them against the Community Edition and confirm which features each plan includes before assuming parity with BigCommerce.
- Customer groups: Map BigCommerce customer groups and company accounts to Shopware customer groups and permissions.
- Negotiated pricing: Map BigCommerce bulk pricing rules and price lists to the pricing model you choose in Shopware.
- Approval flows: Confirm whether quote and approval workflows are included in the tier you select.
- Support response: Compare the response times stated for each tier with your operational needs.
- Tier cost: Ask for the monthly plan fee alongside implementation, hosting and plugin costs.
Confirm in writing which B2B features each Shopware tier covers before you accept a scope that depends on them.
Shopware's Community Edition is free only for shops linked to an account whose gross merchandise value stays at or below 1 million euros over the preceding 365 days. Shops above that level need a paid plan. Shopware states that plan pricing depends on gross merchandise value and other individual factors, so the tier you need depends on your figures, not only on the threshold.
- Threshold check: Measure gross merchandise value over the preceding 365 days, not the calendar year.
- Growth planning: Stores close to the threshold should budget for a paid plan before launch.
- Plan tiers: Rise is listed at 600 euros per month with AI-assisted content and 8-hour support response, Evolve at 2,400 euros per month, and Beyond at custom pricing with 1-hour 24/7 support.
- Hosting choice: Shopware can run as SaaS, on managed PaaS or self-hosted, and the choice affects who operates the platform.
- Quote request: Ask Shopware for written confirmation of the tier that applies to your gross merchandise value.
Check the pricing page and your own 365-day figures before you finalize the migration budget.
What drives the cost and duration of the move
This table lists the factors that most change the effort and budget of moving a BigCommerce store to Shopware 6. Read each row as a driver: what raises the work, why it matters, and what you can do to keep it down before you request a quote.
| Driver | Why it changes cost or effort | How to keep it down |
|---|---|---|
| Installed BigCommerce apps | Each app often stands for a feature you must replace with a Shopware plugin, a custom build or a process change, and each needs its own configuration and testing. | Inventory every app, mark which ones are still used, and drop unused apps before the move. Ask each plugin vendor what Shopware version it supports. |
| Catalog size and variant depth | More products and option combinations mean longer extraction, more mapping rules and more checks on prices, stock and images. | Clean up inactive products and unused variants first. Confirm how the Catalog API rate limits on your plan affect extraction time. |
| Product images | Images are not included in a standard product export, so they must be fetched and re-linked, and the original store must stay live until that finishes. | Keep the source store running until images are imported and verified. Ask the team to test a sample set before the full run. |
| Custom checkout logic | Checkout rules built in code or scripts must be re-specified and rebuilt in Shopware, and each rule needs payment and tax testing. | List every checkout rule and script, and remove the ones the business no longer needs before rebuilding. |
| B2B pricing and approvals | Customer group prices, bulk pricing rules and quote or approval flows map to Shopware features or plugins that may require a paid plan tier. | Document the price lists and approval paths your customers actually use, and confirm which of them are covered by Shopware's B2B features on your chosen plan. |
| Theme complexity | A heavily customized BigCommerce theme usually has to be rebuilt as a Shopware storefront theme, which is often the largest design and front-end task. | Start from a simpler design, reuse existing templates where they fit, and limit custom components to what the business needs. |
| SEO URL count | Each changed URL needs a redirect plan, and a large number of pages increases mapping and testing work. | Export the current URLs, decide which ones must keep their paths, and build redirect rules from that list before launch. |
| ERP, payment and shipping integrations | Each connected system needs its own data mapping, credentials, test cycles and sign-off, and some may need to be rebuilt. | List every connected system, its owner and its data flows. Ask for integration tests against a staging environment. |
| Shopware hosting choice and plan tier | SaaS, PaaS and self-hosted options carry different responsibilities for hosting, upgrades and security. The plan tier depends on gross merchandise value and other factors stated by Shopware, and the Community Edition has a revenue threshold. | Confirm your gross merchandise value over the preceding 365 days against the 1 million euro Community Edition limit. Ask Shopware for current plan pricing and what each hosting option includes. |
What usually goes wrong and how to prevent it
Most BigCommerce to Shopware migrations fail at the edges: features that lived in apps, URLs that were never mapped, and assumptions about data that an export does not carry. The cards below cover the failure, why it matters for this move, and the check that catches it before cutover.
Missed app functionality
BigCommerce apps often handled tax, reviews, shipping rules, loyalty points or subscriptions, and none of that moves with the catalog. Before choosing Shopware plugins, list every installed app from the BigCommerce admin and record what each one writes to the storefront or to orders. Mark each item as covered by a Shopware plugin, covered by custom code, or dropped by decision. Confirm each replacement in a staging store before cutover, not after launch.
Broken redirects and lost search equity
Product and category URLs on BigCommerce will not match Shopware routes unless you map them. Build a table of old URLs from the catalog export and the storefront crawl, then map each to its new Shopware path. Redirects should return permanent status codes, and the old URLs should stay live until search engines have re-crawled the new ones. Check Search Console coverage and top landing pages for several weeks after go-live.
Image gaps in CSV exports
Product CSV exports do not include the image files themselves, so a store can import every product and still show empty listings. Pull images from the BigCommerce Catalog API or the storefront asset URLs, then attach them in Shopware with stable file names. Compare image counts per SKU between the two stores. Keep the BigCommerce store running until that comparison is clean.
Customer password and account reset issues
Customer exports carry profile and address data, but password hashes are not something you should assume will transfer intact between platforms. Plan for customers to reset their passwords on first login, and confirm with BigCommerce and Shopware documentation exactly what the export and import support. Send a clear message before cutover, and test the reset email flow end to end with real mailbox providers before go-live.
Pricing rule mismatches
Customer group prices, bulk pricing tiers and channel-specific rules are where totals quietly diverge. The Catalog API exposes bulk pricing rules, but Shopware uses its own price rules and customer group structures, so each rule needs an explicit mapping. Place a fixed set of test carts in both stores, covering tiers, groups and tax, and compare the line totals. Any difference should be resolved before the new store takes orders.
Crossing the 1 million euro threshold
The Community Edition is free only for shops linked to an account that generate no more than 1 million euros in gross merchandise value over the preceding 365 days. Shopware states that plan pricing also depends on gross merchandise value and other factors. Track trailing 365-day GMV from the first month after launch, and get a written plan quote before growth crosses the line. Ask Shopware which plan applies and what support response times it includes.
Questions buyers ask before moving from BigCommerce to Shopware
What drives the cost of moving from BigCommerce to Shopware?
The cost depends on catalog size, how many BigCommerce apps the store relies on, how much of the theme must be rebuilt, and which integrations (ERP, payments, shipping, tax, search) must be connected again. Costs fall into one-time work (extraction, mapping, theme rebuild, plugin selection, testing, cutover) and recurring items (hosting or a Shopware plan, plugin licenses, support, upgrades). Ask any implementation partner to price each component separately, and ask Shopware to confirm current plan fees on its pricing page, since those fees depend on gross merchandise value and other factors.
How long does a BigCommerce to Shopware migration take?
No duration is fixed here because it depends on the number of products, variants and customers, the number of apps to replace, and how much custom theme and checkout logic must be rebuilt. The schedule should be set in the written scope after a catalog and app inventory has been completed. Ask for phases, dependencies and the point at which the existing BigCommerce store stays live during testing and cutover.
What does the internal team need to provide during the migration?
Your team needs to name a business owner who signs off on product data, pricing, tax and checkout rules, and an engineer who can grant API credentials and access to the BigCommerce admin. You also need someone who owns DNS, domains, redirects and the payment and shipping accounts that will be reconnected. Plan for the team to review test orders and reports, because data mapping errors are usually found by merchandising and finance staff, not by developers.
Can our own team migrate from BigCommerce to Shopware without a partner?
A team with Shopware 6 development experience can complete a small store alone, provided it has time for extraction scripts, plugin evaluation, theme work and testing. Larger catalogs, custom checkout logic and multiple integrations usually need more specialized skills and a clear test plan. Assess your team against the actual app inventory and catalog size, and decide early which parts you will build in-house and which will be handled under a fixed-scope engagement.
What does the Shopware Community Edition revenue threshold mean for our licensing?
Shopware's pricing page says shops linked to an account that generate more than 1 million euros in gross merchandise value over the preceding 365 days need a paid plan instead of the free Community Edition. The Community Edition includes community support only. Model your gross merchandise value across the preceding 365 days, including growth plans, and confirm with Shopware how it counts sales across linked accounts and storefronts before you commit to a licensing model.
Which Shopware plan should we expect to need above the threshold?
Shopware lists Rise at 600 euros per month with AI-assisted content and 8-hour support response, Evolve at 2,400 euros per month with B2B quotes and approvals and 4-hour response, and Beyond at custom pricing with 1-hour 24/7 support. Plan pricing is based on gross merchandise value and other individual factors, so the right tier depends on your sales volume and required features. Confirm current terms, support commitments and what each plan includes directly with Shopware.
What should we ask for in a written scope before starting?
Ask for a listed inventory of the data to be moved (products, variants, images, categories, customers, open orders) and the exact fields each item maps to in Shopware. Request a list of each BigCommerce app with its Shopware replacement or decision to drop it, the theme rebuild scope, the integrations to reconnect, the test and cutover plan, and the rollback approach. Also confirm deliverables, acceptance criteria, what happens to the BigCommerce store during cutover, and how ongoing support and upgrades are priced.
Can we keep our SEO URLs and rankings after moving to Shopware?
Yes, but only if the URL structure is mapped before cutover and old product, category and page URLs redirect to their new equivalents. Export the current URLs, decide which ones will change, and create redirect rules and sitemaps in advance. Test redirects on staging and monitor crawl errors after launch. Confirm the exact redirect method and any limits with Shopware and your hosting provider for your own environment.
Shopware licensing, the revenue threshold and hosting choices
Shopware 6 is licensed under the MIT License, so the software itself carries no license fee. The cost question sits elsewhere. Shopware's pricing page says that shops linked to an account generating more than 1 million euros in gross merchandise value over the preceding 365 days need a paid plan instead of the free Community Edition. Before you plan a migration, estimate your trailing 365-day gross merchandise value across all shops that would sit under the same account, and compare it with that threshold. A store that crosses the line will move to a paid plan, and that changes your recurring cost model from day one.
Paid plans are priced on gross merchandise value and other individual factors, according to the same pricing page. Rise, Evolve and Beyond are the named tiers, and the page lists different response times and features for each, including B2B quotes and approvals on Evolve and 24/7 support on Beyond. Ask Shopware in writing which tier and price apply to your projected volume, which factors move the price, and whether the figure changes if your volume grows after launch. Confirm current figures on the Shopware pricing page before you decide, because tiers and thresholds change.
Shopware can run as SaaS, as PaaS on managed infrastructure, or self-hosted. Each option moves a different set of costs: hosting, patching, backups, PHP and database operations, and uptime monitoring either sit with your team or with the vendor or a hosting partner. Self-hosting keeps customer and order data inside your own environment, but it makes your team or a partner responsible for security updates and performance tuning. Decide the hosting model before you size the migration, because the export and import routes described elsewhere on this page depend on where the new store runs.
How DeployOpen works on this
DeployOpen plans and implements the move from BigCommerce to a self-hosted Shopware 6 store inside your own cloud account, data center or private network. Each step, from catalog extraction through theme rebuild and cutover, is agreed in writing before work starts, so your team knows what is delivered and what stays with you.
How we scope
- The written scope lists which BigCommerce data sets move: products, variants, categories, customers, orders and redirects.
- Scope names the BigCommerce apps to be replaced and the Shopware plugins or custom code that will cover each one.
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any work begins.
How we build
- We extract the catalog through the BigCommerce Catalog API and map variants, images and custom fields to Shopware properties.
- We rebuild the storefront theme and check the free Community Edition threshold against your gross merchandise value.
- Testing covers imported data, customer logins, checkout, payments and URL redirects before any cutover is planned.
How we hand over
- You receive documentation of the hosting setup, data mapping decisions, plugin list and redirect table.
- Runbooks cover backups, upgrades to new Shopware releases and the steps to restore the store.
- Handover includes a walkthrough with your team so administrators can manage catalog and content after launch.
How we support
- Ongoing support, upgrades and continuous security testing are available as a retainer after go-live.
- Retainer scope is agreed in writing and can cover plugin updates, patching and monitoring of the self-hosted stack.
- Ask us to confirm which Shopware plan and support level your store needs before the scope is finalized.
