How to migrate Shopware B2B Suite before Shopware 6.8

Shopware B2B Suite Migration Before Shopware 6.8

Shopware states that the legacy B2B Suite is no longer being developed. New features are delivered through B2B Components. Shopware also states that the Suite will no longer be supported starting with Shopware 6.8. This does not establish a release year or confirm support for every earlier version. Check the current lifecycle guidance before planning your deadline. (docs.shopware.com)

Scope note, last verified October 12, 2026: This guidance covers migration from the Shopware 6 B2B Suite to B2B Components. Record your exact Shopware version, Suite version, migration-extension version and commercial plan before approving the project.

B2B Components currently include employee management, quotes, approvals, quick orders, shopping lists and organisation units. Availability depends on the Shopware release and plan. For example, budgets require Shopware 6.7.4.0 or newer. Individual Pricing requires 6.7.8.0 or newer and depends on organisation units. The current documentation applies to Shopware 6.7.14.0 or newer. (docs.shopware.com)

Start with workflows, not feature lists

Inventory every workflow used by customers, sales representatives, administrators and support teams. Include roles, permissions, approvals, budgets, lists, pricing, addresses, reference fields and ERP-dependent data.

Confirm usage through database analysis, support tickets, analytics and customer interviews. Prioritise each workflow with a weighted score:

• revenue and number of organisations affected
• contractual or compliance impact
• operational importance
• quality of available workarounds
• implementation effort and delivery risk

This produces a defensible roadmap. It also prevents a rarely used but contractually required process from being overlooked.

Design the target before moving data

Classify every Suite capability as standard, changed, replaceable, custom or retired. Do not rely on an old project assessment as proof of a current product gap. Test the documented behavior on your target Shopware version.

Create a proof of concept for high-risk areas such as pricing, permission inheritance, approval routing and customer-specific fields. Then hold a decision gate. Migration should begin only after process owners approve the target workflows, architecture and estimated effort.

Useful deliverables include a capability matrix, architecture decision log, risk register and signed acceptance criteria.

Treat migration as an engineering project

Shopware provides the official B2B Suite Migration extension. Its documented process uses a message queue and ordered processing for related entities. Shopware also advises teams to verify the migration order for their dataset. Do not treat this sequencing as a guarantee of transactional rollback or error-free retries. (developer.shopware.com)

Build a coverage sheet for every source entity. Record its target, transformation, custom fields, expected volume, migration support, dependency, validation method and owner. Confirm exclusions against the documentation for your installed extension version. Custom Suite entities or overridden behavior may require additional mappings or handlers because the migration framework is extensible rather than automatically aware of project customisations. (developer.shopware.com)

Before each rehearsal, create a backup and prove that it can be restored. Confirm that queue workers are active. Run the migration repeatedly in an isolated staging environment based on a recent production copy.

Validation should include:

• counts by organisation, entity type and status
• duplicate, uniqueness and orphan checks
• field-level samples for currencies, units and custom data
• price, discount, tax and order-total comparisons
• effective-permission matrices
• queue interruption and recovery tests
• ERP round trips and duplicate-message checks

Test security and integrations

Permission testing must include failed-access scenarios. Verify that employees cannot view another organisation's prices, quotes, orders, lists, budgets, addresses or approval tasks. Repeat these tests through the storefront, administration, exports and APIs.

For each integration, define the system of record and write owner. Document changed APIs, events, webhooks, retry rules and idempotency keys. Add monitoring for rejected, duplicated or stale messages.

Rehearse cutover without creating split-brain data

Run customer pilots in staging unless Shopware confirms that live coexistence is supported. If both systems must run in production, assign one write owner for every entity. Define synchronization and conflict-resolution rules before granting access.

The cutover runbook should cover backups, the exact freeze scope, queue draining, final migration, reconciliation, security tests, smoke tests, customer communication and go or no-go authority. Set measurable limits for queue backlog, API latency and migration duration.

Rollback is realistic only before users create important target-system data. After the first employee change, quote or order, recovery may require forward fixes and manual reconciliation rather than a simple restore. Define separate recovery actions for each checkpoint.

A successful migration preserves purchasing operations and access controls, not only records. If external support is needed, assess providers through version-specific migration experience, authorization testing, ERP expertise and documented recovery planning.