After a representative migration test or a broader run into Shopware, validation must connect the agreed data result with the buying and operational outcomes the destination needs. Approve evidence in the actual installed release, sales channel, language, currency, Customer group, rule and extension context, because a correct record in one context can remain unusable in another.
Shopware validation should prove that migrated records support the intended sales-channel and rule-driven commerce model. A Product can exist while its variants, property values, sales-channel visibility, advanced prices, Rule Builder references, custom fields, or Shopping Experience placement produces the wrong buyer outcome. A Customer or Order can exist while its sales-channel context, line-item data, state history, or external identifier no longer supports service and reconciliation.
The relationships below describe the Shopware 6 operating model. Record the deployed release, edition, deployment model and enabled extensions; an older or customized store needs evidence for its actual equivalents. Native capability or an installed extension does not establish accepted migration coverage for its records, references or configuration.
Evidence should follow the relationships Shopware evaluates: Product to variant and properties, Product to sales channel and visibility, price or promotion to Rule Builder conditions, Customer to sales channel, Order to line items and states, content to Shopping Experience or Category, and custom field to the app, extension, or integration that consumes it.
Use Pass, Watch, and Block for Shopware Evidence
- Pass: representative and exception evidence proves the intended Shopware behavior.
- Watch: the commercial outcome is usable, but a documented nonblocking correction, presentation task, configuration item, or accepted difference remains.
- Block: the issue materially affects selling, pricing, Product visibility, Customer access, historical Orders, content, SEO, integration continuity, compliance, or agreed migration scope.
| Evidence area | Shopware-specific proof | Typical Block condition |
|---|---|---|
| Product model | Parent Products, variants, properties, prices, media, stock, and Category assignments support purchasing. | A priority Product cannot be selected or purchased correctly. |
| Sales channels | Products, Customers, domains, currencies, languages, and content appear in intended channels. | A priority channel is missing data or exposes the wrong assortment. |
| Rules and pricing | Rule Builder references, advanced prices, promotions, shipping, and payment contexts resolve correctly. | A material buyer receives the wrong price, access, or checkout option. |
| Customers and Orders | Identity, sales-channel context, line items, totals, states, addresses, and external IDs remain understandable. | A material historical Order cannot be reconciled. |
| Content and SEO | Categories, Shopping Experiences, media, routes, metadata, and redirects support discovery. | High-value content or routes fail. |
| Extensions | Custom fields, apps, plugins, documented migrated outputs, and separately implemented deliverables work through their owner. | A launch-critical workflow loses data or a required reference. |
The report should record the sales channel, Customer group, rule context, Product or variant ID, language, currency, and external-system context used for each decision.
Shopware findings should name the evaluated sales channel and rule context. A Product can pass in one storefront and block another because visibility, currency, Customer binding, advanced pricing, or Rule Builder conditions differ.
Use Representative Testing to Prove the Shopware Model
Representative testing should include records that expose Shopware relationships:
- simple Products and variant families using several property groups;
- Products with excluded or unavailable variant combinations;
- Products assigned to different sales channels and visibility levels;
- advanced prices connected to quantity or Rule Builder conditions;
- promotions, shipping, or payment behavior dependent on rules;
- Customers bound to specific sales channels where used;
- Orders with discounts, taxes, refunds, deliveries, or state changes;
- Categories and Shopping Experiences with media and internal links;
- custom fields, app records, plugin data, and external IDs.
Representative evidence should prove that source attributes were translated correctly as Shopware properties, variant options, custom fields, or external records. If a structural error would repeat across the catalog or sales channels, classify it as Block before broader migration execution.
The sample should include a Product or Order from each critical sales channel and each major rule context. A single default-store sample cannot approve a multichannel Shopware operation.
Validate Products, Variants, Properties, and Visibility
Shopware variants are generated from selected property values. The parent Product, variant combinations, Product numbers, prices, stock, media, delivery information, and visibility need to remain coherent.
| Product evidence | Pass | Watch | Block |
|---|---|---|---|
| Variant structure | Intended combinations exist and remain attached to the correct parent. | Minor option ordering or naming remains. | Variants are missing, duplicated, or generated from the wrong properties. |
| Product number and stock | Identity and inventory belong to the correct variant. | Noncritical cleanup remains. | Fulfillment or integration would use the wrong item. |
| Price and tax | Net and Gross Product values produce the intended storefront result for the configured tax and customer-group context. | Controlled rounding or display refinement remains. | A material Product has the wrong Net/Gross basis, price, or tax context. |
| Media | Parent and variant media support accurate selection. | Secondary image order remains. | Buyers cannot distinguish a required variant. |
| Visibility | Active status and sales-channel visibility expose Products only where intended. | Controlled publication work remains. | Restricted Products become public or intended Products disappear. |
| Properties and filters | Descriptive and variant properties support intended filters and selection. | Low-value filter cleanup remains. | A critical Product family cannot be found or configured. |
Validate the storefront, Administration, cart, Order line, and external systems. A variant that displays correctly but uses the wrong Product number or stock identity should not pass.
Shopware can use properties both for variant generation and Product filtering. Confirm that descriptive properties were not converted into unnecessary variant dimensions and that true variant values were not flattened into custom fields.
Include variants with exclusions, inactive combinations, distinct media, and different stock states. Those cases prove whether the generated structure retains real sellable identity rather than only the visible option labels.
Validate Sales Channels, Domains, Languages, and Customer Scope
Sales channels can represent storefronts, headless APIs, Product-comparison feeds, social channels, or other selling contexts. Validation should prove channel assignment and the related domain, language, currency, Customer, Product, navigation, and theme context.
Review:
- Product and Category assignment to each critical sales channel;
- Product visibility level within the channel;
- domain and route behavior;
- language and translation values;
- currency and price display;
- navigation Category entry points;
- Customer binding to sales channels where enabled;
- headless or feed identifiers where used.
Use Block when a priority Product or Customer is available in the wrong channel, absent from the intended channel, or assigned to a route or currency context that prevents purchase. Use Watch when data is correct but controlled theme, navigation, or merchandising work remains.
Customer binding deserves specific evidence. When Customers are bound to sales channels, identical email addresses can represent distinct accounts in different channels. Validate identity and Order association within the intended channel instead of merging accounts solely by email.
Test login with an account registered in its intended channel and with a channel where access must be denied. Existing binding can remain even after the global binding setting is disabled. Prove account and historical Order identity in that channel; matching emails alone do not establish that accounts should be merged or share access.
Validate Rule Builder, Advanced Prices, Promotions, Shipping, and Payment Context
Shopware’s Rule Builder can govern advanced prices, promotions, shipping methods, payment methods and other enabled commercial behavior. Rule-controlled Product visibility requires Dynamic Access or another identified implementation that owns that restriction. Product and Customer records alone do not recreate these rules, their references or the required extension.
| Rule-dependent evidence | Required proof |
|---|---|
| Rule identity | The intended rule exists or has an explicit target replacement owner. |
| Referenced data | Customer groups, sales channels, currencies, Products, tags, custom fields, and other references resolve correctly. |
| Advanced price | The intended buyer, quantity, Product, channel, and Net/Gross basis produce the expected price. |
| Promotion | Conditions and exclusions produce the expected discount without unintended combinations. |
| Shipping/payment availability | The intended method appears only in the correct commercial context. |
| Product visibility | With Dynamic Access or the identified visibility implementation enabled, rule-controlled Products are exposed or hidden as intended. |
A copied rule definition should not pass if its references point to missing or changed IDs. Validate through the storefront context that evaluates the rule. Use Block for material pricing, access, or checkout errors; use Watch for documented configuration work that does not prevent launch.
Use a matching buyer, quantity or cart context and a nonmatching one, including a boundary value where it changes price or method availability. For Dynamic Access, also test the intended restricted Product in the cart so a later rule change cannot leave an unauthorized purchase path. An admin rule that looks valid is insufficient without its evaluated result.
Historical Order discounts and shipping/payment labels remain transaction evidence. They do not prove current Rule Builder, promotion, shipping, or payment configuration.
The evidence should capture the rule conditions and the resolved references used during evaluation. A rule can remain syntactically valid while its Product, sales channel, Customer group, currency, tag, or custom-field reference no longer represents the intended object.
Validate Customers, Orders, States, and Historical Context
Customer validation should cover identity, addresses, Customer groups, sales-channel assignment, language, consent context, external IDs, and duplicate-prone accounts.
Order evidence should preserve Customer or guest identity, line items, variants, custom fields, prices, discounts, taxes, shipping costs, payment and delivery states, Order state, documents, refunds, addresses, and external references where included.
Use Block when a material Order loses its variant or custom-line information, totals are incorrect, Customer association is unsafe, state history is unusable, or external reconciliation fails. Use Watch for controlled cosmetic differences or accepted low-value exclusions.
Migrated Orders do not prove live checkout, Rule Builder, payments, tax, shipping, warehouse, fulfillment, document generation, notifications, returns, or ERP export. Those current behaviors require separate operational approval.
Validate state meaning carefully. Shopware can distinguish Order, transaction, and delivery states. A single source status may need to be interpreted across those state areas rather than copied mechanically into one label.
Validate Categories, Shopping Experiences, URLs, and Content
Shopware content can involve Categories, Shopping Experiences, Product layouts, media, SEO URLs, metadata, navigation, landing pages, and app-owned content. Validate the record and its placement relationship.
| Content evidence | Validation focus |
|---|---|
| Category tree | Parent-child hierarchy, navigation role, Product assignment, and sales-channel context. |
| Shopping Experience | Correct layout assignment, content blocks, media, and referenced Products or Categories. |
| Product layout | Intended Product pages use the correct layout and data. |
| SEO URL | Priority source routes reach useful destinations in the intended domain and language. |
| Media | Files, alt context, associations, and rendered availability remain correct. |
| Internal links | Links resolve to the intended Shopware route without stale source paths. |
Use Block for broken priority routes, missing required policy content, or Shopping Experiences whose missing references prevent a critical journey. Use Watch for controlled presentation work when the underlying content and ownership are complete.
A Category record does not prove navigation, and a Shopping Experience record does not prove that every block renders correctly in the target theme. The final report should identify whether the finding belongs to migrated data or target presentation.
Content review should include reusable blocks and dynamic Product references where used. A Shopping Experience may render successfully while a referenced Product stream, Category, media asset, or translated value is incomplete.
Validate Custom Fields, Apps, Plugins, Supported Adjustments, and Separately Implemented Outputs
Shopware custom fields can attach structured values or object references to several program areas and can participate in templates, cart data, Store API behavior, or Rule Builder conditions. Apps and plugins can add entities, fields, routes, subscribers, scheduled tasks, or external integrations.
For each critical value, document:
- owning Shopware entity and custom-field set;
- data type or referenced object;
- app, plugin, storefront, Rule Builder rule, API, or external consumer;
- stable identifier;
- representative Pass and exception evidence;
- owner of any remaining deployment or configuration.
Validate documented migrated and separately implemented outputs against their documented scope. A transformed field or custom relationship should be tested through the actual app, API, rule, storefront template, or external system that consumes it.
Use Block when custom data is orphaned, object references are wrong, a rule cannot evaluate or a critical external system cannot identify the record. Pending app or plugin deployment may be Watch only when the launch-critical outcome is already usable and the remaining task is nonblocking, with a documented data contract, reference integrity and owner. If the dependency is required for day-one buying, access or operations, keep that readiness area Block until it works, even when deployment belongs to a separate scope.
Distinguish Representative Testing From Broader Migration Execution Evidence
Representative testing proves selected structural assumptions. Broader migration execution must prove complete volume, channel coverage, relationships, and exceptions.
Broader migration review should include:
- all major Product and variant patterns;
- complete sales-channel assignment and visibility;
- languages, currencies, domains, and Customer binding;
- Rule Builder references, prices, promotions, shipping, and payment contexts;
- Customers and Orders across state and exception patterns;
- Categories, Shopping Experiences, media, and URLs;
- all migrated and separately implemented outputs;
- app, plugin, custom-field, and external-ID exceptions;
- changes introduced after representative migration test.
Reopen a Representative test Pass when broader migration execution reveals missing variant combinations, inconsistent properties, channel-assignment gaps, broken rule references, duplicate Customers, orphaned Orders, content-reference failures, or unsupported plugin data.
Segment exception evidence by sales channel, language, Product family, rule context, Customer group, source period, and extension owner. One aggregate count can hide a complete failure in one channel.
Revalidate After Later Migration Actions
| Later action | Shopware revalidation scope |
|---|---|
| Continue with the accepted configuration | Validate newly eligible records and confirm that prior Product, channel, rule, Customer, Order, content, and integration assumptions remain valid. |
| Continue after revising configuration | Revalidate every relationship affected by changed filters, mappings, data type selection, or configuration, including prior approvals. |
| Create a new migration result | Treat the output as a distinct migrated result and repeat the full Shopware validation and launch decision. |
Record the prior and new decision together. When a changed configuration alters Product identity, sales-channel assignment, or Customer matching, previously approved Orders, rules, and URLs may also need review.
Shopware revalidation should follow changed references. A new Product mapping can affect variants, dynamic groups, rules, Shopping Experiences, URLs, and historical Order links; a changed Customer mapping can alter channel binding and rule outcomes.
Name the records and rules the later run actually touches, including earlier records that may be updated or processed again. Continuing with an unchanged configuration does not establish a newly-added-only source window. Compare the combined earlier and later Shopware result, preserve accepted target-side changes where required, and reopen variant identity, sales-channel binding, rule references, effective prices, Order states, Shopping Experiences and extension consumers that depend on a changed record. Do not inherit a prior Pass merely because the run completed.
Build the Shopware Launch Decision
Launch approval requires:
- no unresolved Block affecting purchasing, sales-channel visibility, pricing, Customers, historical Orders, content, SEO, compliance, or integrations;
- completed representative migration test and broader migration evidence;
- proof of documented migrated and separately implemented outputs;
- separate approval for live Rule Builder behavior, checkout, payments, tax, shipping, fulfillment, documents, returns, and extension deployment;
- revalidation after applicable later migration actions;
- named owners and closure dates for Watch items.
Keep separate statuses for catalog readiness, sales-channel readiness, commercial-rule readiness, historical-data readiness, content/SEO readiness, and integration readiness. A passing storefront should not conceal a Block in an Order or external-system workflow. Record the approving owner and evidence date for each status so later configuration changes can reopen the correct decision rather than the entire Store.
Conclusion
Shopware validation should prove that Products, variants, properties, sales channels, rules, Customers, Orders, content, custom fields, and extensions work together in the intended commerce context.
Representative testing proves selected Shopware relationships. Broader migration execution must cover every material sales channel, rule context, Product pattern, Customer and Order exception, while later actions reopen the relationships they alter. Launch approval should follow documented Pass, Watch, and Block evidence.
Common Questions
Why must Shopware sales channels be validated separately?
Products, Customers, domains, languages, currencies, navigation, visibility, and theme context can differ by sales channel. A Pass in one channel does not approve another.
How should Shopware variants be validated?
Validate the parent Product, generated combinations, property values, Product numbers, prices, stock, media, visibility, cart result, and Order line together.
Do migrated Orders prove Rule Builder and checkout logic are ready?
No. Orders prove historical transaction readability. Current rules, promotions, payments, shipping, tax, documents, and fulfillment require separate configuration and operational approval.
How should Rule Builder references be approved?
Test the rule in the sales-channel and Customer context that evaluates it, and confirm that referenced Products, groups, currencies, custom fields, and other entities resolve correctly.
What should be checked for custom fields?
Confirm the owning entity, data type, referenced object, language behavior, app or rule consumer, Store API requirement, and external identifier where relevant.
What requires revalidation after a later Shopware migration action?
Recheck touched Shopware records, including earlier records updated or processed again, and every dependent rule, channel, price, state, content or integration assumption. Compare the combined result and accepted target-side changes. Revised configuration can reopen older evidence; a distinct migration result needs its own complete launch decision.
Does disabling Customer binding make existing Shopware accounts usable in every channel?
Do not assume so. Existing Customers can remain bound to their registration channel after the setting is disabled. Test an authorized account in its intended channel and a channel that should deny access, and verify historical Order ownership. Approve the actual account behavior or an explicitly agreed change rather than merging identities by email.