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.
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, approved migration outputs, and non-standard migration 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 | Product or variant values produce the intended storefront result. | Controlled rounding or display refinement remains. | A material Product has the wrong 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.
Validate Rule Builder, Advanced Prices, Promotions, Shipping, and Payment Context
Shopware’s Rule Builder can influence advanced prices, promotions, Product visibility, shipping methods, payment methods, and other commercial behavior. Migrating Products and Customers does not reproduce every rule automatically.
| 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, and channel 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 | Rule-controlled Products are exposed or hidden as intended where the feature is used. |
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.
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 Tailored Migration handling 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 agreed supported and tailored 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 an external system cannot identify the record. Use Watch when the remaining app or plugin deployment is outside migration scope and the migrated data contract, reference integrity, and responsible owner are fully documented.
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 supported and tailored 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 under the accepted configuration | Validate newly eligible records and confirm that prior Product, channel, rule, Customer, Order, content, and integration assumptions remain valid. |
| continue under revised configuration | Revalidate every relationship affected by changed filters, mappings, data type selection, or configuration, including prior approvals. |
| produce a distinct 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.
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 agreed supported and tailored 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 every new or changed Shopware record and every Rule Builder, sales-channel, pricing, state, content, or integration assumption affected by the action. produce a distinct new migration resultrequires its own complete launch decision.