Migrate from Adobe Commerce to Shopware

Migrate from Adobe Commerce to Shopware: what moves and what you rebuild

Moving from Adobe Commerce to Shopware re-platforms the catalog, customers, orders, theme and integrations, and most of the effort sits in rebuilding extensions and theme work and in verifying that data arrived intact. Start by inventorying every Adobe Commerce custom module, third-party extension and external integration that your store calls, because Shopware does not run Magento extensions, and each item needs a Shopware equivalent, a custom plugin or a documented decision to drop it. Shopware is licensed under the MIT License, and it can run as SaaS, as PaaS on managed infrastructure or self-hosted, so the choice of hosting model is separate from the choice of platform. Most regulated organizations run this work with an internal platform team that owns the requirements, security sign-off and cutover decisions, and an implementation partner that handles the storefront build, integrations and data migration.

Effort and risk concentrate in three places. The first is the theme: Magento layout XML and Luma-based templates have no direct counterpart in Shopware's Twig-based storefront, so expect the design to be rebuilt rather than translated. The second is the extension inventory, where every replacement adds a component that someone must patch and test after each Shopware release. The third is data verification, where order history, tax and price rules, customer accounts and URL redirects must be reconciled before cutover. Ask your partner to confirm in writing how customer password credentials will be carried across, since that decides whether customers must reset passwords at first login. Before you commit, check your gross merchandise value against the threshold on the Shopware pricing page, because shops above it need a paid plan rather than the free Community Edition.

Which Adobe Commerce capabilities map to Shopware, and which need rework

This table maps the main Adobe Commerce areas to their Shopware counterparts and marks each as clean, needs rework or gap. Read the migration note in each row first, because most rework sits in custom modules, B2B flows and integrations rather than in standard catalog data. Confirm B2B and multi-store coverage against Shopware's paid plan features before you treat any row as settled.

Capability	Status	Migration note
Catalog and attributes	Needs rework	Map Adobe attribute sets and product types to Shopware properties and variants, then confirm how each attribute is exported and imported before cutover.
Categories	Clean	Rebuild the category tree and check that sorting, visibility and category-level content carry over with the export.
Customer accounts	Needs rework	Plan password handling and account migration explicitly, and confirm with Shopware how customer groups and addresses are imported.
Orders	Needs rework	Decide whether historical orders move in full or as an archive, since order IDs, statuses and invoice numbering must stay traceable.
Promotions and cart rules	Needs rework	Recreate catalog and cart price rules by hand and test each one, because Adobe rule logic rarely maps one to one.
Multi-store and multi-currency	Gap	Confirm in Shopware's pricing and feature documentation whether your store structure is supported on the plan you intend to run.
B2B company accounts and quotes	Gap	Shared catalogs, negotiable quotes and requisition lists need Shopware's paid B2B features or custom work. Confirm coverage before scoping.
Payments	Needs rework	Shopware Payments is available in the Community Edition with community support only. Confirm gateway support and contracts with your payment provider.
Checkout	Needs rework	Rebuild checkout steps and validation, then test tax, shipping and address rules against live-like data.
Theme and page builder	Clean	The Community Edition includes a visual page builder, but custom Luma-based theme code must be rewritten for Shopware's templating.
Custom modules and extensions	Gap	Flag every Adobe Commerce module without a Shopware equivalent as a gap, and estimate replacement work per module.

Which catalog, customer and order data moves, and which integrations to rebuild

A Shopware move succeeds or stalls on what the store actually holds and what depends on it. Map each data class and each connected system before choosing a migration tool, because the export path and the rebuild effort differ for every item.

Products, variants and attributes

Catalog data includes simple and configurable products, variant matrices, attribute sets, option values and media references. Adobe Commerce models these with its own attribute and attribute-set structure, and Shopware uses its own property groups, options and variant rules, so each attribute needs an explicit target. Confirm which export and API options your Adobe Commerce version supports for products, and test one configurable product end to end on a staging copy. Product images are often stored as files, so confirm whether they move with the export or must be fetched separately.

Categories and catalog structure

Category trees, anchor and static category behavior, and product-to-category assignments define navigation, filters and SEO landing pages. Shopware builds its navigation from its own category tree, so a flat copy of Adobe Commerce categories can break menus and facets. Document every category that carries content blocks or merchandising rules, because those settings rarely transfer in a plain data export and need a rebuild in the Shopware administration or a custom mapping.

Customer accounts and addresses

Customer records include login identifiers, group membership, default billing and shipping addresses, and newsletter status. Password hashes are the hardest item: Adobe Commerce and Shopware use different hashing schemes, so confirm with the Shopware team whether hashes can be imported or whether customers must reset passwords. Consent records for marketing and the legal basis for keeping each customer record should travel with the data, and the export must be checked for personal data you are not entitled to move.

Order history and financial records

Historic orders, invoices, credit memos and refunds are the records finance and tax authorities will ask for. Most teams keep closed orders in a read-only archive or in the legacy system and import only the fields Shopware needs for customer order history, order numbering and returns. Agree on order number formats before import so that new Shopware numbers do not collide with historic ones, and confirm with your accountants what must remain retrievable and for how long.

Tax, shipping and payment configuration

Tax classes, tax rules by region, shipping zones, carrier methods and payment method settings are configuration rather than data, so they are rebuilt rather than exported. Each rule must be recreated and tested with real checkout examples in every country you sell to. Payment gateway connections depend on credentials and tokenized card references that usually cannot be moved, so confirm with each provider whether saved payment methods can be transferred or whether customers must store them again.

URLs, redirects and integrations

Keep a complete list of indexed product, category and CMS URLs, then map each to its Shopware route with 301 redirects in place before cutover. Connected systems, including ERP, PIM, tax engines, shipping platforms, payment processors and marketing tools, each need an interface in Shopware through its API or a plugin. For every connector, confirm that a Shopware plugin or API endpoint covers the data flow and that the vendor supports Shopware, because a missing connector often becomes the largest unplanned cost.

How to migrate from Adobe Commerce to Shopware in five steps

This sequence moves an Adobe Commerce store to Shopware in controlled stages, so each stage produces evidence that the next one is safe to start. Each step ends with an artifact you can review before committing to cutover.

Inventory modules, data and integrations
Start by listing every custom and third-party module, theme override, cron job, payment and shipping integration, ERP or PIM connection, and each B2B feature in use, such as company accounts, shared catalogs or purchase orders. Your developers and store owner should review the list together, because Commerce-only features often hide in configuration rather than code. Note which data types exist (products, attributes, categories, customers, orders, tax rules, URL rewrites) and where each one is authoritative. You are done when you hold a module and integration inventory with an owner and a keep, replace or drop decision for every line, and a field-level data map showing where each Shopware entity will come from.
Run a pilot migration on a subset
Move a limited sample of categories, products with their attributes and variants, and a small group of customers into a Shopware test instance. Use it to test attribute and category mapping, pricing rules, customer password handling and the extensions you plan to rebuild. Document each mismatch and the fix applied, and confirm that the pilot data renders correctly in the storefront. The output is a pilot log listing every defect, its root cause and the change that resolved it. Do not move on until the pilot runs cleanly twice in a row against fresh exports, because a single successful run can hide mapping gaps.
Reconcile in a parallel staging run
Run a full migration into a staging copy of Shopware while Adobe Commerce stays live. Compare record counts, price and tax totals, stock levels, customer records and order history between the two systems, and test checkout, payment callbacks, shipping rules and transactional emails end to end. Build the URL redirect map from the Adobe Commerce URL rewrite table so that existing category and product URLs resolve on the new store. The output is a reconciliation report with each difference explained or closed, plus a tested redirect map. Ask your team to confirm that the report, not memory, is the basis for the go-live decision.
Cut over with a documented rollback path
Schedule the cutover window with your payment providers, shipping partners and any ERP or PIM owners, then freeze catalog and customer edits in Adobe Commerce. Run the final delta migration, switch DNS or the load balancer, and verify live checkout with real but low-value test orders. Keep Adobe Commerce, its database and media store intact and reachable so you can reverse the change if a critical defect appears. Write the rollback procedure before the window opens, naming who decides, what triggers it and what data entered Shopware after cutover would need to be reconciled back. The output is a signed cutover checklist with a rollback runbook that the business owner has approved.
Monitor the new store and close gaps
After cutover, watch error logs, failed payments, search indexing, 404 responses on old URLs and customer support tickets for the period you agreed in advance. Compare Shopware order volumes with the expected pattern and fix any redirect gaps as they appear. Confirm that Shopware updates, security patches and the payment and extension dependencies have an owner, since Shopware's support tier and whether you self-host or use a paid plan change who handles patching. The output is a post-cutover issues register with each item closed or assigned, and a documented operations handover.
Decommission Adobe Commerce and archive data
Once the agreed stabilization period has passed and no rollback is needed, shut down the Adobe Commerce application, revoke its API tokens and integration credentials, and remove scheduled jobs that could still write data. Export and archive the final Adobe Commerce database, media files, order records and audit logs in storage you control, with a retention period set by your legal and finance teams. Confirm the license end date with Adobe and the cancellation terms in your contract. The output is an archive manifest with checksums, a record of revoked access and a signed decommissioning certificate from the store owner.

Community Edition or a paid Shopware plan: when the GMV threshold decides

The first question for a merchant leaving Adobe Commerce is not which features they need, but whether their shop stays on the free Community Edition at all. Shopware's pricing page says that 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. Pull the GMV figure for the trailing 365 days from your own order data, across every storefront and sales channel linked to the same Shopware account, before you size the migration budget. Ask whether a second storefront or a separate business unit would be counted under the same account, because that changes the result.

Shopware states that plan pricing depends on gross merchandise value and other individual factors, so the published list prices are a starting point rather than a quote. The paid plans listed on the pricing page are Rise at 600 euros per month, with AI-assisted content and an 8-hour support response; Evolve at 2,400 euros per month, which adds B2B quotes and approvals and a 4-hour response; and Beyond, priced on request, with 1-hour support 24/7. Map these against the Adobe Commerce B2B and support features your store actually uses, and ask Shopware in writing which plan and terms apply at your GMV, including whether the figures are monthly, annual and per storefront.

Hosting is a separate decision from licensing. Shopware can run as SaaS, as PaaS on managed infrastructure, or self-hosted, and the pricing page presents these as options. Self-hosting on your own infrastructure keeps hosting under your control but moves patching, backups, scaling and uptime work to your team or implementation partner, which is a recurring cost. Managed options shift part of that work to Shopware. Confirm with Shopware which hosting models are available to your plan and region, what support covers in each model, and who is responsible for security updates on the platform.

What drives the cost and duration of moving to Shopware

This table lists the factors that change the price and timeline of a move from Adobe Commerce to Shopware, with the reason each one matters and how to keep it under control. Read it before requesting a quote, because the drivers that dominate your project are usually the custom code, data quality and integrations rather than the platform itself. Use the one-time and recurring split below to compare proposals on the same basis.

Driver	Why it matters	How to keep it down
Custom modules and extensions	Each Commerce-only or custom module must be rebuilt as a Shopware plugin, replaced with a Shopware extension, or dropped. Deep checkout or pricing logic costs more than cosmetic modules.	Build a module inventory that marks each item as used, unused, replaceable or unique. Retire unused modules before scoping.
Theme and page builder work	Adobe Commerce themes do not carry over. Storefront templates, components and the Shopware visual page builder must be designed and built again, and each template type adds testing.	Reduce the number of page templates, reuse Shopware's built-in page builder blocks, and agree on a fixed set of storefront views.
B2B features	Company accounts, shared catalogs, negotiated quotes, purchase orders and requisition lists may depend on Shopware's paid plan features or on custom work. Confirm which ones your store uses today.	List every B2B workflow in use, check each against the current Shopware plan features, and mark gaps as separate scope items.
Catalog size and attribute complexity	Large catalogs with many attribute sets, configurable variants and category trees take longer to map and validate. Attribute mapping errors surface late in testing.	Map attributes and categories to a written data model before migration begins, and cut unused attributes first.
Data quality	Duplicate SKUs, inconsistent customer records, orphaned orders and missing image files slow every import cycle and add rework after cutover.	Run cleanup and deduplication on the source before extraction, and set acceptance rules for record counts and field completeness.
Integrations	ERP, tax, shipping, payment, PIM, marketing and fulfillment connections each need a new Shopware connector, new credentials and separate test cases.	List every system that reads or writes store data, state which ones stay, and phase the rest after launch.
Storefronts and languages	Each additional storefront, currency, tax region or language multiplies content, URL, SEO and test work.	Launch the primary storefront first, then add regions as separate phases with their own acceptance criteria.
Hosting model	Self-hosted Shopware puts server build, patching, backups and monitoring on your team or partner. Shopware's SaaS or managed PaaS options move some of that work to Shopware, at a different cost structure.	Decide the hosting model before design starts, and ask each bidder to price the same model.
Internal Shopware experience	A team new to Shopware needs training, code reviews and more partner time. Experienced teams shorten the build and reduce defects.	Name an internal owner early, pair them with the implementation team, and budget for knowledge transfer in the scope.
One-time costs	Inventory and analysis, data mapping, migration scripts, theme and template build, integration build, and testing with cutover rehearsals. These are paid once but can be the largest share of the project.	Fix deliverables and acceptance criteria per phase so that rework is priced separately and visible.
Recurring costs	Hosting, Shopware plan fees if your store exceeds the free Community Edition threshold, security patching, version upgrades, and support retainers. The Shopware pricing page says plan pricing depends on gross merchandise value and other factors, so confirm the figure with Shopware.	Compare total cost over the planned operating period, and ask for a written support response commitment before signing.

What usually goes wrong in an Adobe Commerce to Shopware move and how to prevent it

Most failed re-platforming projects fail on a small number of predictable points: lost URLs, incomplete customer data, mismatched order and tax records, assumed extensions and late B2B work. Each card below names one risk and a check you can run in your own environment before cutover.

URL and SEO loss

Adobe Commerce URL structures, category paths and product URL keys rarely match Shopware's routing by default. Without a complete redirect map, search rankings and inbound links break on the day of cutover. Export every indexed URL from your current store and sort it against the Shopware storefront after import. Ask your agency or internal team to show a test run where each old URL returns a single 301 to its new destination.

Customer password and account gaps

Customer accounts often carry password hashes, addresses, newsletter flags and group assignments that a standard export does not fully map. Some customers will be unable to log in after the move if hashing formats differ or the import skips records. Confirm in writing which fields move and which require a forced password reset. Test a sample of accounts from each customer group on staging before any customer receives a notice.

Order history and tax mismatches

Historical orders feed refunds, returns, accounting and tax reporting, so a mismatch here causes problems long after launch. Check that order totals, currency, tax classes, shipping lines and invoice numbers reconcile between the Adobe Commerce database and the imported Shopware records. Have your finance team sign off a reconciliation report for a sample month. Decide up front whether historical orders are imported in full or archived read-only.

Extensions assumed to exist

Many Adobe Commerce stores depend on third-party extensions for shipping, tax, ERP connectors or promotions. Shopware uses its own extension system, so a module that works on Magento may have no equivalent. Build a list of every installed module and every integration, mark each as replaced, rebuilt or dropped, and get the owner of each business process to approve the decision. Do not treat an extension as available until you have checked its Shopware listing or written a replacement scope.

B2B logic rebuilt late

Company accounts, shared catalogs, negotiated prices, purchase orders and approval chains are usually the most complex part of a B2B store. If they are planned after the storefront is built, cutover slips or launches without them. Map each B2B rule to a Shopware feature, a paid plan capability or custom work, and confirm which items are in the scope agreed before the build starts. Review the Shopware pricing page to see which B2B features each plan covers.

Theme regressions on mobile and checkout

A theme rebuilt from scratch often looks right on desktop but breaks on mobile widths, in cart updates or at payment steps. Checkout is the highest-cost place for a regression, because a broken step loses orders directly. Run a scripted test of the full purchase path on the current mobile and desktop browsers you support, including guest checkout, saved addresses and failed payments. Keep the test results with the release record.

Cutover without a tested rollback

A cutover with no documented way back leaves the business with two diverging stores and no clean record of which orders belong where. Write the rollback steps, including DNS, payment provider settings and how orders placed after cutover would be reconciled. Rehearse the rollback on staging with a realistic data set, and confirm who has authority to trigger it. Keep the Adobe Commerce store running and read-only until the rehearsal succeeds.

How the move differs for stores with B2B, custom modules or large catalogs

A single-store merchant on a standard theme usually has the most direct path. The work centers on the catalog, customer accounts, orders and a storefront theme rebuilt in Shopware. The Community Edition includes product management, a visual page builder and Shopware Payments, but with community support only, according to Shopware's pricing page. It stays free as long as the shops linked to your account generate no more than 1 million euros in gross merchandise value over the preceding 365 days.

Theme rebuild: Replace the Adobe storefront theme with a Shopware storefront theme, then confirm the page builder covers the layouts you use today.
Payments: Confirm each payment gateway you rely on is available for your region and supported on the Community Edition, since community support is the only support tier there.
Threshold tracking: Track gross merchandise value over the preceding 365 days from the start of planning, because crossing 1 million euros requires a paid plan.
URL and SEO mapping: Build a redirect map from current product, category and CMS page URLs before cutover.

Check first how close your annual gross merchandise value is to the threshold, because that figure decides which Shopware plan you can run.

How much effort, time and internal work does the move need?

What drives the cost of moving from Adobe Commerce to Shopware?

The main cost driver is how much custom Adobe Commerce work has to be rebuilt, not the data volume. Costs rise with the number of custom modules, theme work, third-party integrations (ERP, payment, tax, shipping), B2B company account logic and the amount of historical data you want to keep. Shopware's own pricing is a separate recurring cost: its pricing page says plan pricing depends on gross merchandise value and other individual factors, so the price you pay after cutover depends on your sales volume. The free Community Edition applies only while shops linked to an account stay at or below 1 million euros in gross merchandise value over the preceding 365 days. Above that, a paid plan is required. Ask each vendor and partner to split the one-time project work from recurring licence, hosting and support fees.

How long does a migration from Adobe Commerce to Shopware usually take?

No duration is fixed by the platform, so the timeline depends on scope. The biggest variables are the number of custom extensions to rebuild, the complexity of the storefront theme, how many B2B features (company accounts, quotes, approvals, shared catalogs) need replacing, and how many integrations must be re-tested. Stores with a clean catalog and few custom modules move faster than heavily customized ones. Ask for a phased plan with a discovery stage, a data mapping stage, a build stage, a test stage and a cutover stage, and ask which stage sets the critical path. A fixed-scope agreement fixes the timeline once the scope is written down.

What does our team need to provide during the migration?

Your team needs to provide knowledge that only your business holds. Expect to supply:

Access to the current Adobe Commerce codebase, database and a staging copy that matches production
A list of custom modules, extensions, integrations and the business rules they enforce
Decisions on which historical orders, customers, catalog data and content to migrate
Approval of URL mapping, tax, shipping and payment configurations
A named owner for acceptance testing and for signing off cutover

Without these inputs, the work usually stalls at discovery. Agree the owners and turnaround times in writing before the build starts.

Can our team migrate to Shopware without an implementation partner?

Yes, a capable in-house team can migrate, because Shopware is MIT licensed and its source is open for your engineers to read and change. The question is capacity and risk, not permission. The team needs PHP and Shopware development skills, experience with data migration, staging and deployment pipelines, and someone who can own security patching after go-live. Consider a partner for the parts that carry the most risk, such as payment and tax integrations, data reconciliation and cutover rehearsal. Shopware's paid plans also include support response commitments, which are a different service from building the migration itself.

Is the Shopware Community Edition enough for our store?

It can be, if your shops stay at or below the 1 million euro gross merchandise value threshold over the preceding 365 days and your needs fit what the free edition includes. According to Shopware's pricing page, the Community Edition includes a visual page builder, product management and Shopware Payments, with community support only. It does not come with the paid tiers' support response times. The Rise plan lists 600 euros per month with AI-assisted content and 8-hour support response. The Evolve plan lists 2,400 euros per month with B2B quotes and approvals and 4-hour response. Beyond uses custom pricing with 1-hour 24/7 support. Check whether your B2B features, support obligations and volume growth require a paid tier before you commit.

How do we keep our URLs and search rankings after the move?

Start with a complete crawl of your current Adobe Commerce site and export every indexable URL, including category, product, CMS and filtered pages. Map each old URL to its new Shopware equivalent, and set up 301 redirects for every change before cutover. Keep the same URL structure where possible to avoid unnecessary redirects. Compare traffic and indexed pages in your search console before and after launch, and fix broken redirects quickly. Ask the team doing the work to show the URL map and redirect test results before the production switch.

What should we ask for in a fixed-scope quote?

A fixed-scope quote should list the deliverables, the assumptions behind them and the acceptance criteria. Ask for:

A written inventory of the modules, integrations, data sets and pages in scope, and what is excluded
Each deliverable with its acceptance test and the owner who signs it off
A list of assumptions about your inputs, such as access, data quality and decision turnaround
A cutover and rollback plan, including how URLs, orders and customers are handled during the switch
Post-launch support terms, separated from the one-time build
Which costs are one-time and which recur, including any Shopware plan or hosting fees you will pay directly

DeployOpen typically works on a fixed-scope basis, with scope, deliverables and timelines agreed in writing before work starts. Ask for the same breakdown from any other provider you compare.

How DeployOpen scopes, runs and supports a Shopware migration

DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside the client's own infrastructure. For a move from Adobe Commerce to Shopware, we agree the scope in writing first, then build and hand over the store on infrastructure you control.

How we scope

Inventory the Adobe Commerce modules, extensions, customizations and B2B features your store actually uses
Define which catalog, customer, order and URL data moves, and which is archived
Agree deliverables, timelines and acceptance tests in writing before any work starts

How we build

Map Adobe Commerce attributes, categories and customer groups to Shopware structures
Rebuild required extensions and theme work on Shopware, with a URL redirect plan
Test migrated data, checkout and payments on a staging environment before cutover

How we hand over

Document the architecture, data mappings, redirect rules and rollback steps for your team
Deliver backup and hardening configuration for the self-hosted Shopware environment
Provide evidence of tests and controls that your auditors can review, without certifying them

How we support

Offer ongoing support, upgrades and continuous testing as a retainer after go-live
Plan Shopware version upgrades on the maintained release lines with staged testing
Confirm response expectations and support scope in the written agreement before work starts

Migrate from Adobe Commerce to Shopware