After a representative test or broader migration into Magento Open Source, validate both the agreed record output and the target behavior it supports. Identify the installed release, modules, websites, stores, store views and inventory configuration for every result; evidence from the default view cannot establish correctness for another website or sales channel.
Record presence is only the start of Magento Open Source validation:
- A Product can exist while its configurable children, attribute set, website assignment, store-view content, source inventory or Category placement prevents the intended purchase.
- An Order can exist while its line configuration, totals, Customer identity or payment reference no longer explains the historical transaction.
Approve the relationships that support selling, administration and historical use.
Keep edition and implementation boundaries explicit:
- Customer Groups and tier pricing do not establish Adobe Commerce B2B company accounts or shared catalogs. Apply edition-specific documentation only to the matching implementation.
- Extension-owned blogs, page layouts and custom records need agreed scope and deployment evidence; native functionality is not a migration guarantee.
Set the Pass, Watch, and Block Rules
-
Pass:
Representative and exception evidence proves the agreed outcome, including an approved transformation or exclusion.
-
Watch:
A usable result has an accepted nonblocking issue, with its boundary, owner, due date and retest evidence recorded.
-
Block:
An agreed requirement or launch-critical outcome remains wrong or unproven, affecting purchasing, data integrity, SEO, compliance or required integrations.
Classify the affected scope. A task outside migration delivery can still block launch; an agreed exclusion is not automatically a defect.
| Evidence area | Magento Open Source proof | Typical Block condition |
|---|---|---|
| Product architecture | Product type, associated SKUs, options, attributes, media, and price support the intended buying flow. | A priority Product cannot be selected, purchased, or fulfilled correctly. |
| Store scope | Websites, stores, and store views expose the intended catalog, language, content, and URLs. | A priority storefront is missing or receives values from the wrong scope. |
| Inventory | Source quantities, stock assignment, reservations, and salable status support selling. | The Store oversells or hides valid inventory. |
| Customers and Orders | Identity, addresses, groups, lines, totals, statuses, and external references remain understandable. | A material historical Order cannot be reconciled. |
| Content and SEO | Priority CMS Pages, media, Product/Category routes, and redirects resolve correctly. | High-value traffic or required content is lost. |
| Custom data | Extension records, documented migrated outputs, separately implemented deliverables, and external IDs work through their intended owner. | A launch-critical workflow loses the record it needs. |
The final report should name the exact website, store view, Product family, Customer Group, inventory stock, and external system used as evidence. A default-scope Pass should not be applied automatically to every storefront.
Identify whether a finding belongs to migrated data, store configuration, theme behavior, extension deployment or an external integration. A record can pass its data check while the unfinished implementation still blocks launch.
Use migration reconciliation to distinguish intended differences from defects, then assign the correction and evidence needed for a retest.
Test Representative Products and Scope
Use the preparation sample ledger to select records that expose the actual Magento structure:
- simple, configurable, grouped, bundle, virtual, and downloadable Products where used;
- configurable families with several associated simple Products and variation attributes;
- Products from different attribute sets;
- Products assigned to several websites or Categories;
- localized names, descriptions, option labels, metadata, and URL keys;
- Customer Groups and tier or group pricing where relevant;
- Products with multi-source inventory or unusual stock states;
- Customers with multiple addresses and historical Orders;
- CMS Pages, Blog Posts, media, and priority redirects;
- extension-owned records and external identifiers.
Include exception cases alongside clean Products:
- Catalog choices: out-of-stock or disabled children, duplicate-looking option values and Products with custom options.
- Historical transactions: guest Orders and refunds.
- Extended data: extension-defined fields.
These cases can expose structural errors that uniform samples miss.
Treat the representative test result as Block when a repeatable mapping or scope error compromises an agreed required outcome. Correct the structural assumption before broader migration execution rather than accepting it as a cosmetic issue.
Prove Product Types and Configurable Relationships
Product type determines the relationship to prove:
-
Configurable:
Associated simple or eligible virtual children without custom options carry their own SKU and inventory identity.
-
Grouped and bundle:
Validate component relationships and their intended commercial behavior.
-
Virtual and downloadable:
Verify the applicable non-shipping or delivery context.
-
Custom options:
Choices modify a Product without creating separate stock-bearing children.
Apply the rules of the installed Product types rather than inferring equivalence from similar labels.
| Product proof | Pass | Watch | Block |
|---|---|---|---|
| Product type | The destination type matches the intended commercial behavior. | A minor presentation difference remains. | The Product cannot be sold or fulfilled correctly. |
| Configurable relationship | Parent, associated Products, variation attributes, and selected values remain coherent. | Option ordering or noncritical labels need refinement. | Children are missing, duplicated, disabled incorrectly, or attached to the wrong parent. |
| SKU, price, and inventory | Values belong to the correct sellable Product. | Controlled cleanup remains for low-risk records. | Price or stock would apply to the wrong SKU. |
| Bundle/grouped components | Components, quantities, options, and Order-line meaning are intact. | Minor presentation work remains. | The commercial package cannot be selected or understood. |
| Media | Parent, child, swatch, and gallery media support accurate choice. | Secondary image order needs refinement. | Buyers cannot identify the intended Product or variation. |
| Category and website assignment | Products appear only in intended storefront contexts. | Merchandising adjustment remains. | Priority Products are absent or exposed incorrectly. |
Validate Product behavior in the storefront, Admin, cart, Order line, and connected systems. An Admin record that looks correct should not pass if the buyer choice, stock identity, or Order snapshot is wrong.
Choose a configurable family whose children differ in price, image, stock or website assignment. Check each selection against the parent presentation: the configurable price is derived from eligible in-stock children, not an independent parent price. A uniform family cannot expose the same range of errors.
Child association is global across websites, stores and store views; visibility, localized values and stock availability need separate proof.
- Test a valid child and an unavailable or disabled child.
- Repeat the relevant selection in each intended storefront.
- Confirm that a visible parent does not expose an invalid or unpurchasable combination.
Do not model the parent-child association as an independent relationship in each store view.
Validate Attributes and Discovery
Attributes define Product information, configurable choices, filters, search, comparison, promotion conditions, and integration fields. Attribute sets determine which fields are available for each Product family.
Representative evidence should include:
- Products assigned to each important attribute set;
- dropdown, multiselect, swatch, text, date, and boolean fields where used;
- configurable attributes with global scope and required values;
- store-view labels and localized values;
- attributes used in search, filters, comparison and layered catalog filtering;
- ERP, PIM, supplier, compliance, or warehouse identifiers;
- custom attributes consumed by extensions or APIs.
Use Block for a required field missing from the agreed output, the wrong attribute set, an unresolved configurable choice or a launch-critical filter that cannot be used.
Use Watch for accepted noncritical label cleanup or optional merchandising refinement.
Illustrative example: Blue, blue and Navy Blue may be cleanup candidates or distinct commercial values.
Follow actual Products and filters, and compare with the approved normalization rules. Similar wording alone does not justify merging the values.
Check Store Scope, Categories, and Routes
Magento Open Source scope can change Product assignment, Category roots, language, content, URLs, metadata, and configuration. Validate each commercially meaningful website, store, and store view separately.
| Scope evidence | Required proof |
|---|---|
| Website | Intended Products, Customers, prices, and operational context belong to the correct website. |
| Store | The correct root Category and menu structure support discovery. |
| Store view | Localized Product, Category, CMS Page, label, metadata, and URL values appear correctly. |
| Category | Parent-child hierarchy, Product assignment, status, anchor/filter behavior, and route are correct. |
| URL and redirect | Priority source paths reach useful Product, Category, CMS Page, or Blog Post destinations. |
| Internal links | Product, content, and menu links resolve within the intended store view. |
A Product can pass in the default view while a localized storefront fails because a name, option label or URL is missing, or its website assignment and root Category expose the wrong assortment or browse structure. Preserve the exact website, store, store-view and root-Category context with the result instead of averaging unlike storefronts.
Menus, theme layout, search configuration, and live browsing remain separate target responsibilities. Category presence supports the evidence but does not prove every storefront discovery behavior automatically.
Retain both administrative and storefront evidence:
- Admin: inspect assignment, scoped values and inheritance.
- Storefront: prove that the selected website and store view produce the intended public result.
Neither observation substitutes for the other.
Reconcile Inventory and Sellability
When Inventory Management is installed and enabled, Magento Open Source can use multiple physical sources, stocks assigned to sales channels, reservations, and salable quantity. Validate quantity and availability through the full relationship.
| Inventory evidence | Validation focus |
|---|---|
| Source assignment | Each SKU belongs to the intended warehouse, pickup, drop-ship, or fulfillment source. |
| Source quantity | Quantity belongs to the correct SKU and source. |
| Stock assignment | Websites or sales channels use the intended stock. |
| Reservation behavior | Historical imported Orders do not create unintended reservations or deductions. |
| Salable quantity | Storefront availability matches source quantity, reservations, backorders, and Product state. |
| Configurable parent | Availability reflects valid associated Products. |
| External identifier | ERP or WMS can identify the correct SKU and source. |
A mismatch can exist even when total stock equals the source. Quantity attached to the wrong source or SKU is a Block when it affects fulfillment, pickup, overselling, or reporting.
Current warehouse synchronization, source selection, shipment creation, and carrier behavior require separate operational approval. The validation process confirms migrated inventory evidence and its relationships, not the complete deployment of those systems.
When stock is externally governed, confirm that the migrated SKU and source identifiers match the ERP or WMS contract. A correct opening quantity cannot compensate for an identifier that sends later updates to the wrong item.
Keep three inventory tests separate:
- Reconcile opening stock against its agreed snapshot and pending obligations.
- Exercise a controlled new purchase and its stock/reservation outcome.
- Confirm that historical Order import does not generate unintended payment, stock-deduction or fulfillment effects.
If historical reservation or transaction behavior is explicitly included, record and test that agreed exception.
Validate Customers and Historical Orders
Check Customer evidence by purpose:
- Identity: registered Customers, guests, duplicate-prone identities and multiple addresses.
- Commercial context: Customer Groups and tax context.
- Relationships: external IDs and Customer-to-Order association.
Verify required returning-customer access under the actual account-sharing scope. Test usable sign-in where the exact Source-to-Target migration path supports password continuity, or the agreed reset, activation or first-login route, separately from profile and address presence. Missing launch-critical account access remains Block; a copied identity or group label cannot establish it.
For historical Orders, verify the included evidence:
- Purchased items: Product/SKU lines and selected options.
- Transaction snapshot: addresses, prices, discounts, taxes and shipping.
- Operational history: payment references, statuses, invoices, shipments, credit memos, comments and external IDs.
Use Block when:
- a material Order links to the wrong Customer;
- configurable or custom-option values disappear from the Order line;
- financial totals are wrong;
- payment or fulfillment references cannot be reconciled;
- Customer Group meaning is lost for business-critical accounts;
- Order history becomes inaccessible in the intended website context.
Historical Orders demonstrate past transactions, not that the target can charge, fulfill or refund a new purchase. Approve current configuration and integrations separately:
- Checkout and charging: checkout, payment gateways, tax and fraud controls.
- Post-purchase operations: shipping, reservations, notifications, fulfillment, returns and ERP exports.
- Refund evidence: supported full or partial refunds of new paid Orders, where required by the agreed launch scope.
Give each approval a responsible owner.
Check Content and SEO Continuity
Review the included content and its public context:
- Records and presentation: CMS Pages, in-scope Blog Posts, Product/Category descriptions and media.
- Discovery and publication: metadata, internal links, publication state and priority URLs.
A Page passes when its content, media, route, store-view scope and intended accessibility meet the agreed outcome.
For redirect continuity, exercise the real source URL and confirm the intended useful destination, without loops or irrelevant chains.
Use Block for missing required policy/compliance content, widespread priority URL failure, broken high-value Product/Category routes or purchase-critical media loss.
An agreed low-value exclusion can Pass when it meets the accepted scope. Use Watch for a remaining accepted nonblocking formatting issue or metadata correction; record its impact and retest.
Theme layout, widgets, Page Builder structures where installed, and extension-owned Blog content may require target implementation outside ordinary record migration. The validation report should identify the owner rather than misclassify the problem as missing data.
Prove Extension and Integration Outputs
Validate extended data through the workflow that consumes it. Check the systems actually used:
- Data and operations: extensions, custom modules, ERP, PIM and WMS.
- Selling and fulfillment: search, tax, payment, shipping and marketplaces.
- Customer continuity: subscriptions, reviews and loyalty.
For each critical value, record:
- owning Product, Customer, Order, CMS, or custom entity;
- extension or external system;
- stable identifier and expected data type;
- direction of synchronization;
- representative successful and exception evidence;
- owner of any required target deployment or configuration.
Prove documented migrated and separately implemented outputs against the agreed scope. Exercise custom mappings, filters, transformed relationships and external IDs through the Admin, storefront, API, extension or external system that needs them. The migration validation checklist provides a broader review record.
Use Block when required data is incompatible, orphaned or untraceable, or when a launch-critical consumer cannot use it.
Target deployment outside migration scope still needs separate approval. Use Watch only for a demonstrably nonblocking task with complete data, identifiers, ownership and controlled follow-up; a required unproven workflow remains Block.
Extend Sample Findings to the Full Result
Representative testing proves selected structural assumptions. Broader migration execution must prove complete volume, relationship integrity, and exceptions.
Broader migration review should include:
- all major Product types and attribute sets;
- every website, store, and store view;
- complete Category and Product assignments;
- full Customer-to-Order relationships;
- inventory sources, stocks, and external IDs;
- priority content, media, URLs, and redirects;
- all migrated and separately implemented outputs;
- extension and integration exceptions;
- changes introduced after representative migration test.
Reopen a sample Pass when broader evidence reveals:
- inconsistent option values or missing associated Products;
- store-view overwrite or source-inventory gaps;
- duplicate Customers or orphaned Orders;
- redirect collisions or extension-record failures.
Correct the affected relationship and retest its dependent contexts.
Segment exception evidence by website, store view, Product family, attribute set, source location, Customer Group, and source period. Aggregate counts can hide complete failure in one storefront or Product family.
Revalidate After Later Migration Actions
| Later action | Magento Open Source revalidation scope |
|---|---|
| Continue with the accepted configuration | Validate the actual new, updated or reprocessed records and confirm that prior Product, attribute, scope, inventory, Customer, Order, content, and extension 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 Magento Open Source validation and launch decision. |
The evidence log should preserve the prior and new decision. If a previously approved Product, store view, or Order changes from Pass to Watch or Block, record the changed configuration, affected identifiers, and corrective owner.
Magento Open Source dependencies can propagate widely. Changes to Product identity can affect associated Products, inventory, Orders, URLs, and integrations, while changes to website or store-view mapping can reopen content, Customer, and Category evidence.
For the actual later run:
- Name the affected records and rules, including earlier records updated or processed again; unchanged configuration does not imply a newly-added-only window.
- Compare combined earlier/later output and preserve accepted target-side changes where required.
- Reopen dependent children, attributes, scoped content, sources/stocks, Customer-to-Order links, URLs and extension references.
Run completion alone cannot inherit an earlier Pass.
Make the Launch Decision
Launch approval requires:
- no unresolved Block affecting purchasing, Product scope, inventory, Customers, historical Orders, content, SEO, compliance, or integrations;
- complete representative migration test and broader migration evidence;
- proof of documented migrated and separately implemented outputs;
- separate approval for live checkout, payments, tax, shipping, fulfillment, source selection, returns, required refunds, and extension deployment;
- revalidation after applicable later migration actions;
- named owners and closure dates for Watch findings.
Keep separate decision states for storefront readiness, historical-data readiness, inventory readiness, content/SEO readiness, and integration readiness. One area should not conceal a Block in another.
Distinguish data Blocks from implementation Blocks. Both can prevent launch, but their owners, corrections and closure proof differ. Carry those findings into the separate go-live decision.
Conclusion
Magento Open Source validation should prove that Product types, configurable relationships, attributes, store scope, inventory, Customers, Orders, content, and extensions work together in the intended Target Store.
Representative testing establishes structural confidence, broader migration execution proves completeness and exceptions, and later migration actions require focused or full revalidation. Launch approval should follow documented Pass, Watch, and Block evidence.
Common Questions
Why are record counts insufficient for Magento Open Source validation?
Counts do not prove Product type behavior, associated SKU relationships, store-view scope, inventory availability, Customer associations, Order readability, or extension continuity.
Which configurable Product evidence is essential?
Validate the parent, eligible simple or virtual children, variation attributes, SKUs, prices, images, inventory, Category and website visibility, purchasability and Order-line result together. Child association is global, while visibility and localized output need proof in each intended context. Include unavailable or disabled choices as negative controls.
Should each website and store view be validated separately?
Yes. Product assignments, Category roots, language, content, URLs, and other values can differ by website, store, and store view.
Do imported Orders prove live checkout and fulfillment are ready?
No. Historical Orders prove transaction readability. Live payment, tax, shipping, inventory reservations, fulfillment, notifications, and returns require separate target configuration and approval.
How should extension-owned data be approved?
Test the migrated value through its consuming extension, API or external system, using the correct entity and stable identifier. Separately approve required target deployment. A launch-critical workflow remains Block until working evidence or an agreed scope change resolves it; ownership alone is insufficient.
What requires revalidation after a later Magento migration action?
Revalidate new or changed records and prior relationships affected by the actual run, including earlier records processed again. Check combined output and accepted target changes. An unchanged configuration does not imply a newly-added-only window; a distinct fresh result requires a fresh full validation decision.
Do Adobe Commerce B2B features belong to Magento Open Source validation automatically?
No. Customer Groups or tier pricing do not prove company accounts, shared catalogs or other Adobe Commerce B2B behavior. Identify the destination edition and installed extension that owns each requirement, then validate its accepted records and working output. Do not apply edition-specific documentation as a blanket Magento Open Source guarantee.