Shopware preparation starts with context and assignment: where a Product is visible, which variant values are inherited or overridden, and which enabled consumer uses a rule. Global record presence cannot explain those relationships. Preserve original identifiers, assignments, and commercial meanings before preparing the intended Shopware environment.
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.
Source access, evidence and recovery
Identify the actual Source separately from the intended Shopware installation. For a Shopware Source, confirm Administration, permitted hosting/cloud/database/files, media, scheduled-task, integration-access, and extension evidence. Record its version, deployment, self-hosted PHP/database context where applicable, channels, languages, currencies, extensions, custom code, and systems. For another Source, collect equivalent relationships without inventing Shopware IDs. Record the destination version/deployment, contracted features, compatible enabled extensions, theme consumers, and implementation owners separately.
| Preparation action | Owner | Evidence | Ready condition | Source / Target applicability |
|---|---|---|---|---|
| Confirm administrative access | Actual Source administrator; Shopware administrator when Shopware is the Source | Working account and role summary | For a Shopware Source, Products, Customers, Orders, rules, sales channels, extensions, and content can be inspected. Another Source provides access to its own selected records. | Actual Source administration. Native Shopware Administration applies when that installation is the Source; intended Target administration is separately confirmed. |
| Create recoverable source backups | Source infrastructure or platform-recovery owner | Dated actual Source backups or exports, permitted file/media/configuration evidence, coverage, limits, protected location and recovery owner; native database archives where accessible | Required Source evidence is recoverable under the declared method; full-Store restoration limits are explicit. Resolve a required recovery gap, agree its explicit exclusion or hold the affected scope. | Actual Source recovery arrangements under its deployment/hosting permissions. A hosted/cloud Source need not provide direct database or filesystem access, and an export is not proof of full Store restoration. |
| Record the technical environment | Source technical owner; intended Target deployment owner separately | Actual Source version, hosting/deployment and components; for a Shopware Source, Shopware and extension-version inventory, with PHP/database details only where applicable and accessible | Version-dependent records and customizations are documented. | Actual Source software and deployment. Self-hosted PHP/database details are conditional; intended Shopware Target version, deployment and compatible entitled/enabled features are independent decisions. |
| Capture custom code and extensions | Source development owner; intended Target extension owner separately | Actual Source extensions and custom behavior; extension list, custom plugins/apps, modified files, custom entities and deployment notes where present and accessible | Every non-core record or behavior has an accountable owner. | Actual Source code, schemas and record consumers. Intended Shopware extensions, replacements and field consumers require their own compatible Target implementations. |
| Map external systems | Source and continuing integration owners | ERP, PIM, WMS, CRM, marketplace, search, payment, and fulfillment identifiers | Continuing data authorities and synchronization keys are known. | Actual Source and continuing external identifiers and authorities. Future Target endpoints, stock writers and synchronization responsibilities are assigned independently. |
Protect actual Source evidence using the method available under its hosting and deployment permissions. Record the date, covered records/files/media/configuration, missing areas, recovery route and owner. Retain native Shopware database/files archives where accessible; another hosted or cloud Source may provide exports/files or managed recovery instead. Recovering selected evidence is different from restoring the complete Store and all of its extensions.
Freeze original Product/variant IDs, product numbers, parent links, property definitions, Categories, channels, Customer/Order IDs, media, custom-field schemas, rule assignments, and external keys where present in the actual Source before cleanup. For a Shopware Source, preserve inherited-versus-overridden states as well as values; another Source keeps its own relationship and override evidence. Record approved source-to-intended changes separately, including retired values needed to interpret historical transactions or 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 rules can be assigned to advanced prices, promotions, shipping costs, payment or shipping availability, and flows. Product, Category, or Shopping Experience block access also needs a compatible entitled and enabled consumer such as Dynamic Access; a rule definition alone does not establish that feature or its assignments. Record the condition, priority, referenced context, assignment, and actual implementation owner for every required behavior. Hiding a Category does not by itself restrict its Products in search or direct access.
| 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 and timestamp, installed stock meanings/calculation, external owner, warehouse context where used, delivery time, minimum quantity, closeout, and back-order state | The authoritative stock owner and sellable-unit key are known. |
For every representative base or advanced price, record whether the source value is Net or Gross and which tax and Customer-group context gives that basis meaning. Readiness requires more than preserving the number: the same sample must produce the intended customer-facing result after the target tax context is applied.
Historical Order totals should remain snapshots. Do not recalculate old prices, discounts, taxes, or shipping charges from current Rule Builder assignments. Prepare stock using the installed Shopware version and actual calculation model: stock and available-stock fields do not have identical semantics across every version or configuration. Record tracking, warehouse/external authority, minimum-quantity and closeout rules, opening quantities, and pending obligations separately. History must not produce a second inventory effect.
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, external IDs, and authentication dependencies. Record actual channel-binding settings and the chosen Source-to-Target verification decision, SSO dependency, or reset, activation, or first-login handling, with identity and communication owners. Order preparation should preserve Product lines, variant selections, addresses, totals, Order/transaction/delivery state histories, documents, refunds, and integration references. Record Flow, webhook, notification, payment, stock, and fulfillment events that the import plan must contain rather than replay.
| 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 | Actual password/SSO or first-login handling, reset/activation path, MFA where supplied by the identity implementation, 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.
Confirm Shopware Target implementation prerequisites
The intended Shopware deployment must be able to consume the agreed channel, variant, rule and content relationships. A Source rule definition does not supply its enabled access consumer, and a stored quantity does not settle the destination stock-calculation model. Confirm the intended version, available features and compatible implementations before execution, keeping historical states and opening operational responsibilities separate.
| Preparation action | Owner | Evidence to prepare | Ready condition |
|---|---|---|---|
| Confirm the intended deployment, access and features | Target technical and business owners | Shopware version/deployment, administration, contracted features, compatible enabled extensions, available infrastructure/storage access and recovery responsibilities | The intended environment and required entitled/enabled components are explicit and available to their owners. |
| Prepare channels and catalog consumers | Target commerce and catalog owners | Sales channels/domains/languages/currencies, Product visibility, customer-binding decisions, real variants, inheritance/override treatment, properties and field definitions | Required channel and sellable-record relationships have a usable Target representation; global record presence alone does not settle scope. |
| Confirm commercial, access and stock models | Target pricing, access and inventory owners | Rule assignments and compatible consumers, Net/Gross and tax/group context, advanced prices/promotions, installed stock meaning, quantity authority, closeout/minimum rules and pending obligations | Required behavior has an enabled consumer and agreed effective settings; rule definitions, Category visibility or quantity columns alone do not establish readiness. |
| Prepare account, content and route consumers | Target identity, content and site owners | Account/address/authentication decisions, Shopping Experience assignments and extension blocks, Categories/navigation, media, custom fields, priority URLs and SEO intent | Required identity, layout, field, media and discovery relationships have compatible consumers and explicit access treatment. |
| Assign extensions and continuing live operations | Target development, operations and integration owners | Custom entities/fields, Flow/webhook/scheduled consumers, external identifiers and stock authority, future payment/shipping/tax/notification behavior and historical/test containment decisions | Continuing processes have usable implementations and owners; historical states cannot replay charges, messages, stock effects or fulfillment. |
Select Representative Migration Test Samples
Choose samples that represent the Store’s real architecture. Record original IDs and values, product numbers, URLs, channels, property values, inheritance/override states, rules and consumers, Customer relationships, Order references, intended representation, agreed exclusions, and why each sample was selected. Keep dated untouched source evidence and related files, with coverage and recovery ownership.
| 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 expectations, intended representation, sales-channel and rule context, related files, agreed exclusions, and a named reviewer. These inputs prepare later verification without replacing it.
Complete the Final Shopware Readiness Gate
| Readiness area | Ready condition |
|---|---|
| Access and recovery | Required actual Source access and owners, available backups or exports/files/media/configuration evidence, recovery method, date, coverage, limits and owner are confirmed. Required evidence is recoverable under that method; intended Target administration and permitted infrastructure are separately assessed. |
| 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. |
| Target prerequisites | The intended Shopware deployment/features, channel/catalog representation, rule/access/stock models, account/content/field consumers, access and continuing-operation owners are confirmed. |
The Shopware scope is ready when every material record can be traced to its source owner, related records, evidence artifact, and accepted destination or retained system, with required implementation prerequisites confirmed. Resolve required gaps, exclude them by agreement, or hold the affected scope before proceeding. An owner and a future deadline alone cannot settle missing inheritance, rule-access, or stock evidence.
Assess actual Source evidence and intended Target consumers together. Missing inheritance meaning, an unavailable required rule/access consumer, undefined stock authority or a material recovery gap remains a readiness gap even when records exist. Resolve the requirement, agree its explicit exclusion or hold the affected scope before execution; later validation owns proof in the declared sales-channel and buyer context.
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.
Carry the evidence package, intended Target decisions and any held scope into Shopware Validation Priorities. Preparation defines what must be tested; migrated results and acceptance belong to that later review.
Common Questions
What should be prepared first for a Shopware migration?
Identify the actual Source and collect required access, dated archives, field meanings, media, and recovery ownership. For a Shopware Source, include its installed version, extensions, channels, and permitted infrastructure evidence. Separately record the intended destination installation, entitled enabled features, and consumers before detailed catalog classification.
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, and required Product, Category, or content access. Record conditions, priority, referenced entities, and assignments. Access requirements also need the compatible entitled and enabled consumer, such as Dynamic Access; the rule alone is insufficient.
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.
Does a Rule Builder condition make Product and content access ready?
No. Record its assignments and the compatible entitled and enabled access consumer, such as Dynamic Access. Category restrictions do not automatically restrict contained Products in search or direct access. Prepare expectations for every required context and name the implementation owner.
Can stock columns be interpreted without the installed Shopware model?
No. Version and calculation settings affect stock semantics. Preserve the actual field meanings, variant key, timestamp, warehouse or external authority, minimum-quantity and closeout rules, and intended destination model. Keep opening stock and pending obligations separate from historical Orders so history does not cause a second deduction.