Shopware preparation should define how source records relate to sales channels, Products and variants, properties, custom fields, Customers, Orders, Shopping Experiences, rules, media, URLs, extensions, and external systems. A complete export is not enough when the same Product can appear in several sales channels, variants inherit or override parent values, properties can support both filtering and variant generation, and commercial behavior depends on assigned rules.
Every preparation action should have an owner, an evidence artifact, and a ready condition. The preparation package should also distinguish source evidence from target implementation. Product relationships, historical Order context, existing URLs, external identifiers, and extension-owned records belong to migration readiness; live payment, shipping, tax, workflow, theme, and sales-channel behavior remain target-side implementation decisions.
Secure Shopware, Hosting, Database, and File Access
Confirm access to Shopware Administration, hosting or cloud management, the database where available, application files, media storage, scheduled tasks, integration credentials, and extension management. Record the Shopware version, deployment model, PHP and database environment for self-hosted installations, active sales channels, languages, currencies, extensions, custom code, and connected systems.
| Preparation action | Owner | Evidence | Ready condition |
|---|---|---|---|
| Confirm administrative access | Shopware administrator | Working account and role summary | Products, Customers, Orders, rules, sales channels, extensions, and content can be inspected. |
| Create recoverable source backups | Infrastructure owner | Database export, file/media archive, configuration archive, and restoration owner | The source Store can be recovered independently of the live environment. |
| Record the technical environment | Technical owner | Shopware, PHP, database, hosting, deployment, and extension-version inventory | Version-dependent records and customizations are documented. |
| Capture custom code and extensions | Development owner | Extension list, custom plugins/apps, modified files, custom entities, and deployment notes | Every non-core record or behavior has an accountable owner. |
| Map external systems | Integration owners | ERP, PIM, WMS, CRM, marketplace, search, payment, and fulfillment identifiers | Continuing data authorities and synchronization keys are known. |
Preserve internal identifiers for Products, variants, Categories, properties, sales channels, Customers, Orders, media, custom fields, and external systems. These keys are necessary when records must be reconciled across Shopware entities or reconnected to integrations.
Prepare Sales Channels, Domains, Languages, and Customer Scope
Shopware sales channels can represent storefronts, headless contexts, product-comparison feeds, social channels, or other customer-facing endpoints. Products, Categories, domains, languages, currencies, payment methods, shipping methods, themes, and Customer relationships can depend on the selected sales channel.
| Sales-channel area | Evidence to prepare | Ready condition |
|---|---|---|
| Channel inventory | Sales-channel ID, type, status, domain, language, currency, Customer scope, and responsible owner | Every active customer-facing context is listed once. |
| Product availability | Product/variant IDs, visibility level, assigned channels, and excluded channels | Product scope is not inferred from global catalog presence. |
| Domain and language context | Domain, path, locale, currency, hreflang intent, and fallback behavior | Localized records are tied to the correct public context. |
| Customer binding | Registration behavior, Customer-to-channel relationship, duplicate-email cases, and account policy | Customer identities are not merged across channels without evidence. |
| Channel-specific configuration | Payment, shipping, tax, theme, analytics, and legal-content owners | Live configuration is separated from migrated record evidence. |
Document whether the source Store has several storefronts, regions, brands, languages, wholesale paths, marketplaces, or headless experiences. Identify which contexts should remain distinct and which are intentionally consolidated. That decision should exist before catalog and Customer evidence is normalized.
Prepare Products, Variants, Properties, and Custom Fields
Shopware Products can use parent and variant relationships, properties, manufacturers, media, Categories, advanced prices, custom fields, delivery times, purchase quantities, and sales-channel visibility. Properties can support storefront filtering and can also provide the values used to generate variants, but descriptive properties and variant-defining properties are not automatically the same set.
| Catalog pattern | Evidence to prepare | Ready condition |
|---|---|---|
| Simple Product | Product ID, product number, price, stock, tax, manufacturer, Category, media, and channel visibility | The Product can be interpreted without hidden extension dependencies. |
| Variant family | Parent ID, variant IDs, option combinations, inherited and overridden values, SKUs, stock, price, weight, and images | Every sellable variant is traceable to the correct parent and option values. |
| Filterable property | Property group, option values, Product assignments, filter use, and translations | Descriptive discovery data is distinct from buyable variant identity. |
| Custom field | Field set, technical name, type, entity assignment, values, translations, and consuming process | Staff-facing, storefront, rule, and integration uses are documented. |
| Multi-channel Product | Product/variant IDs, assigned channels, visibility levels, main Category, and channel-specific SEO path | Channel availability is explicit rather than inferred. |
| Media-rich Product | Primary/gallery media, variant-specific images, alt context, sort order, and external storage | Every media asset has a known Product or variant owner. |
Record inactive, hidden, discontinued, back-order, closeout, digital, bundle-like, subscription-like, or extension-created Products separately. Do not normalize unusual Product states into one ordinary active Product merely to simplify the source inventory.
Prepare Categories, Dynamic Product Groups, and Shopping Experiences
Shopware Categories can support navigation, Product assignment, storefront entry points, and content layouts. Dynamic Product Groups can define rule-based Product sets. Shopping Experiences can provide landing pages, shop pages, Category layouts, sections, blocks, elements, links, and media. These relationships need separate evidence even when they appear as one customer journey.
| Storefront structure | Evidence | Ready condition |
|---|---|---|
| Category hierarchy | Category IDs, parents, active state, Product assignments, sales channels, translations, and main Category use | Catalog hierarchy and channel scope are complete. |
| Dynamic Product Group | Conditions, Product examples, sales-channel assignment, and business purpose | Rule-driven assortment is not treated as a static Category export. |
| Shopping Experience | Layout ID, type, assigned Category or landing page, sections, blocks, media, and linked Products/Categories | Content ownership and catalog references are documented. |
| Navigation path | Sales channel, Category tree, menu purpose, access context, and priority URLs | Navigation is not assumed from Category records alone. |
| Internal links | Source page, linked Product/Category/content ID, language, and destination intent | Links can be rewritten without losing the referenced business object. |
Identify layouts or content elements created by extensions. Separate reusable content from theme presentation and from Product data. If a Shopping Experience contains a linked Product, Category, form, or extension block, record both the layout and the referenced owner.
Prepare Rules, Prices, Promotions, and Commercial Conditions
Shopware Rule Builder assignments can affect advanced prices, promotions, shipping costs, payment or shipping availability, flows, Product visibility, Category visibility, and content access. Preparation should describe the business condition and every place where the rule is assigned.
| Commercial area | Evidence to prepare | Ready condition |
|---|---|---|
| Rule | Rule ID, name, conditions, priority, status, referenced Customers/groups/channels, and assignments | The rule’s business purpose and all affected areas are known. |
| Advanced price | Product/variant, currency, rule, quantity range, gross/net values, list price, and date context | Every price is attached to the correct commercial condition. |
| Promotion | Code, rules, discount scope, exclusions, usage limits, dates, and relevant historical Orders | Historical discount evidence is separated from future promotion configuration. |
| Shipping/payment condition | Assigned rule, sales channel, Customer context, region, cart threshold, and exception | The condition is documented without treating it as migrated Order data. |
| Stock and delivery | Product/variant quantity, external owner, warehouse context where used, delivery time, and back-order state | The authoritative stock owner and sellable-unit key are known. |
Historical Order totals should remain snapshots. Do not plan to recalculate old prices, discounts, taxes, or shipping charges from current Rule Builder assignments.
Prepare Customers, Addresses, Orders, and Historical States
Customer preparation should include account identity, sales-channel relationship, Customer groups, addresses, language, company or tax information, consent evidence, external IDs, and authentication dependencies. Order preparation should preserve historical Product lines, variant selections, addresses, totals, state-machine history, transactions, deliveries, documents, refunds, and integration references.
| Record area | Owner | Evidence | Ready condition |
|---|---|---|---|
| Customer identity | Customer-data owner | Customer ID, email, sales channel, group, language, status, addresses, and external ID | Duplicate and channel-bound identities are resolved deliberately. |
| Authentication | Security owner | Password scheme, SSO/social login, reset path, MFA, and account communications | Account access is planned without assuming credential portability. |
| Order lines | Order-data owner | Product/variant IDs, snapshot labels, quantities, prices, promotions, taxes, and custom payloads | Purchased items remain understandable even if the catalog later changes. |
| Order state | Operations owner | Order, transaction, and delivery states with timestamps and business meaning | State history can be interpreted without recreating the source workflow. |
| Documents and references | Finance/integration owners | Invoice, credit note, transaction, shipment, marketplace, ERP, and fulfillment IDs | Historical reconciliation keys remain traceable. |
Select guest, registered, channel-bound, discounted, refunded, partially delivered, and extension-affected Orders. These cases expose relationships that ordinary completed Orders do not.
Inventory Extensions, Custom Entities, and Integrations
Create an ownership ledger for every plugin, app, custom entity, custom field set, Flow Builder action, search extension, payment or shipping integration, ERP/PIM/WMS connector, marketplace feed, theme extension, and scheduled process that reads or writes business data.
| Dependency | Evidence to prepare | Ready condition |
|---|---|---|
| Extension | Name, version, status, purpose, configuration owner, entities, tables, custom fields, and affected records | Extension-owned data has a destination or retained owner. |
| Custom entity or field | Schema, entity assignment, relationships, translations, and consuming code | Custom data can be interpreted independently of the source implementation. |
| External system | Endpoint, authority by entity, synchronization direction, IDs, and cutover owner | The migration will not create competing systems of record. |
| Flow or webhook | Trigger, condition, action, payload, destination, and error owner | Operational automation is separated from static migrated records. |
| Generated data | Indexes, caches, logs, sessions, queue records, and abandoned extension tables | Non-authoritative technical data is excluded deliberately. |
Inactive extensions should remain in the ledger when their historical data still appears in Products, Customers, Orders, documents, or external reconciliation.
Prepare Priority URLs, SEO Evidence, and Redirect Decisions
Record priority Product, Category, landing-page, shop-page, and content URLs by sales channel and language. Include canonical behavior for variants, main Category relationships, metadata, internal links, backlinks, campaign paths, and any SEO-url template or redirect extension involved.
| URL evidence | Owner | Ready condition |
|---|---|---|
| Product and variant paths | SEO/catalog owner | Each priority Product has a channel-aware source path and intended destination. |
| Category and landing paths | Content owner | Category hierarchy, Shopping Experience, and route intent are connected. |
| Multilingual paths | Localization owner | Language and sales-channel context are preserved. |
| Redirect inventory | SEO owner | Every high-value old path has a keep, change, merge, retire, or redirect decision. |
| Internal links | Content owner | Source references can be rewritten to the intended target objects. |
Do not rely only on a sitemap. Include URLs from analytics, search data, backlinks, campaigns, Customer communications, and high-value internal navigation.
Select Representative Migration Test Samples
Choose samples that represent the Store’s real architecture. Record source IDs, product numbers, URLs, sales channels, property values, rules, Customer relationships, Order references, and the reason each sample was selected.
| Sample | Evidence to prepare | Preparation purpose |
|---|---|---|
| Variant family | Parent, variants, options, inheritance, stock, prices, images, and channels | Represents Shopware’s Product and variant model. |
| Property-heavy Product | Property groups, filter values, custom fields, Category, and search use | Represents discovery and field ownership. |
| Rule-dependent case | Rule, assigned price/promotion/shipping/payment area, and affected records | Represents condition-based commercial behavior. |
| Multi-channel Customer | Customer, registration channel, groups, addresses, and duplicate-email context | Represents channel-bound identity. |
| Complex Order | Variant lines, promotions, states, transaction, delivery, document, and external IDs | Represents historical commerce evidence. |
| Shopping Experience | Layout, Category/landing assignment, media, links, and extension blocks | Represents content-commerce relationships. |
| Extension-owned record | Core entity, extension schema, custom fields, and integration keys | Exposes non-core scope before execution. |
The Shopware sample package is ready when each selected record has source evidence, sales-channel and rule context, related files, and a named reviewer.
Complete the Final Shopware Readiness Gate
| Readiness area | Ready condition |
|---|---|
| Access and recovery | Administration, hosting, database/files where applicable, media, credentials, backups, and restoration ownership are confirmed. |
| Sales channels | Domains, languages, currencies, Customer scope, Product visibility, and responsible owners are documented. |
| Catalog | Products, variants, properties, Categories, media, prices, stock, custom fields, and identifiers are traceable. |
| Commerce history | Customers, addresses, Orders, states, deliveries, transactions, documents, and external references have source evidence. |
| Content and URLs | Shopping Experiences, navigation, priority paths, metadata, internal links, and redirect decisions are documented. |
| Dependencies | Rules, extensions, custom entities, flows, webhooks, and external systems have named owners. |
| Samples | Representative records cover every material Product, channel, Customer, Order, content, rule, and extension pattern. |
The Shopware scope is ready when every material record can be traced to its source owner, related records, evidence artifact, and intended destination or retained system.
Conclusion
Shopware preparation requires coordinated evidence across sales channels, Products and variants, properties, custom fields, Categories, Shopping Experiences, rules, Customers, Orders, extensions, URLs, and integrations. The checklist should make those relationships explicit before execution instead of relying on record totals or generic exports.
A complete readiness package preserves recoverable source evidence, defines authoritative records, separates historical transactions from live configuration, and gives every material dependency a named owner.
Common Questions
What should be prepared first for a Shopware migration?
Confirm Administration and infrastructure access, create recoverable backups, record the Shopware and extension environment, and identify every active sales channel. Detailed catalog work should not begin until the team can inspect the source and recover it reliably.
Why must sales-channel scope be documented separately?
Products, Customers, domains, languages, currencies, visibility, content, and commercial configuration can depend on the sales channel. Global record presence does not prove that the correct customer-facing context has been preserved.
How should Shopware properties and variants be prepared?
Document property groups, values, Product assignments, filter use, and the option combinations that generate variants. Record inherited and overridden values for each sellable variant so descriptive properties are not confused with variant identity.
Which rules require preparation evidence?
Include rules assigned to prices, promotions, shipping, payment, flows, Product or Category visibility, and content access. Record conditions, priority, referenced entities, and every assignment that depends on the rule.
Which Shopware Orders should be selected as representative samples?
Include guest and registered Customers, channel-bound accounts, variants, promotions, refunds, partial deliveries, multiple state changes, documents, transactions, and external integration references.
What belongs in the Shopware extension ledger?
Record every extension, custom entity, custom field set, flow, webhook, theme dependency, and external connector that creates or consumes business data. Each item needs an owner, affected records, source evidence, and a destination or retained-system decision.