Validate Products and Categories

Validate Products and Categories

A catalog result is ready for approval when representative Products and Categories are present, accurate enough for the approved platform model, correctly related, and usable for merchandising and navigation. Use this checklist to identify catalog defects, document accepted platform differences, and decide whether the catalog can advance toward sign-off.

This validation covers migrated catalog data and the outcome of applicable migration configuration. It does not replace target-store checkout testing, complete SEO and redirect validation, or live inventory-integration testing.

When to use this checklist

Use this checklist after Validate Full Migration Results confirms that the completed activity and overall migration scope are suitable for detailed validation.

Complete it before final sign-off and before relying on the target catalog for launch preparation.

Prepare the catalog evidence

Collect evidence that identifies the expected source record and the corresponding target result:

• the completed migration activity and target store;
• selected Products, Categories, Manufacturers, and Taxes where applicable;
• Success, Failed, and Skipped results for the relevant data types;
• stable source identifiers such as SKU, Product ID, Category ID, or a unique name and path;
• target Product and Category identifiers or URLs;
• the approved expectations for exact values and supported transformations;
• applicable Additional Options, Attribute Mapping, purchased Add-ons, and approved Customization;
• known Demo findings, source-data issues, and accepted platform-model differences;
• a findings record with severity, owner, and required next action.

Validate data, not theme styling alone

A theme can change spacing, image crops, labels, and presentation without changing migrated catalog data. Confirm the underlying Product or Category record before classifying a visual difference as a migration defect.

Build a representative catalog sample

Do not inspect only simple or recently created Products. Select enough records to cover business importance, structural complexity, configuration impact, time range, and known risk.

Sample dimension	Include when available	Why it matters
Business importance	High-revenue Products, high-traffic Categories, campaign Products, and operationally critical inventory	Exposes differences with material business impact.
Product structure	Simple Products, variants, options, multiple images, special pricing, complex attributes, and inactive or hidden records	Tests how different Product structures are represented.
Category structure	Top-level Categories, nested Categories, Products assigned to multiple Categories, and high-volume navigation groups	Tests hierarchy, assignments, and navigation meaning.
Configuration impact	Records affected by HTML stripping, description-image import, Inventory Location Mapping, Attribute Set Mapping, Root Category Mapping, Data Filter, Advanced Data Mapping, Advanced Database Mapping, Data Transformation, or Customization	Confirms that selected configuration produced the approved result.
Time and source window	Older and recent Products, plus records near the beginning and end of the intended source-data window	Detects incomplete or unintended scope.
Known risk	Demo issues, previously Failed or Skipped records, unusual source values, unsupported fields, and expected platform transformations	Confirms that known exceptions are resolved or accepted.

Increase the sample when the catalog is complex, source quality is inconsistent, a configuration rule affects many records, or failures appear across more than one Product or Category pattern.

Run the Product and Category checks

1. Confirm the activity and catalog scope

   Verify that the records belong to the intended migration activity, migration path, target store, and source-data window. Confirm which catalog data types and configuration rules were in scope.

2. Reconcile processing evidence

   Review Success, Failed, and Skipped results for Products, Categories, Manufacturers, and Taxes where applicable. Classify every Failed and unexpected Skipped record that affects the required sample.

3. Confirm Product presence and identity

   Match each sampled target Product to the intended source Product using stable identifiers. Confirm that required Products exist once, unless approved target behavior intentionally creates another supported representation.

4. Validate Product fields

   Compare the approved fields, including name, description, SKU or other identifiers, status, visibility where applicable, regular price, special price, inventory quantity, attributes, options, and required images.

5. Validate variants, options, and images

   Confirm that variants or option combinations remain associated with the correct parent Product, carry the expected identifiers and values, and can be selected or managed as required. Verify image ownership, order, and availability where those details are part of the acceptance criteria.

6. Validate Manufacturer, Tax, and inventory relationships

   Confirm that Products retain the intended Manufacturer and Tax relationships where supported. When Inventory Location Mapping applies, verify that migrated stock is assigned to the approved target location or consolidation result.

7. Validate Category structure and assignments

   Confirm Category names, descriptions, status, hierarchy, parent-child relationships, and Product assignments. Where the Target Platform uses a collection-style or otherwise different catalog model, compare the result with the approved equivalent rather than requiring identical source structure.

8. Validate navigation and catalog URLs

   Confirm that priority Categories and Products can be reached through the intended target navigation and that their target URLs open the correct records. Record priority URLs for the later content, URL, and redirect review; do not treat this step as complete SEO or redirect sign-off.

9. Validate affected configuration behavior

   Test normal, boundary, and exception records affected by applicable options, mappings, Add-ons, or Customization. Confirm that filtering, supported field or database destinations, transformation, and target representations match the approved rules without breaking required relationships.

10. Check operational catalog usability

    Confirm that sampled records can be found, opened, edited, displayed, and made available for the intended merchandising or purchase workflow. Validate migrated inventory values here; validate live synchronization and downstream inventory integrations only when those systems are separately in scope.

11. Classify differences and record the decision

    Assign a failure class and severity to every unexplained difference. Record Pass, Pass with accepted limitations, or Fail, together with evidence, owners, and corrective actions.

Apply testable catalog checks

Area	Pass condition
Product presence	Every required sampled Product exists in the intended target store and represents the correct source Product.
Identity and duplication	Stable identifiers match the approved expectation, and no unexplained duplicate Product exists.
Core fields	Required names, descriptions, identifiers, status, prices, special prices, inventory, attributes, and options are exact or transformed according to an approved rule.
Variants and options	Required combinations remain attached to the correct Product and preserve the intended commercial meaning.
Images	Required images are available, associated with the correct Product or Category, and usable under the approved target behavior.
Manufacturer and Tax relationships	Applicable Products retain the required Manufacturer and Tax meaning.
Category structure	Required hierarchy or approved target equivalent is complete and navigable.
Product assignments	Sampled Products belong to the intended Categories or approved target groupings.
Inventory locations	Applicable source locations map to the approved target locations or consolidation result.
Configuration behavior	Applicable options, mappings, Add-ons, and Customization produce the approved scope, values, and relationships.
Operational usability	Sampled catalog records can support the intended merchandising, navigation, and Product-selection tasks.

Interpret expected platform differences

Some catalog differences can be acceptable when they are defined before validation and preserve the required business meaning.

Difference	Acceptance approach
Categories become collections or another grouping model	Confirm that Product membership, navigation ownership, and merchandising use remain correct.
Attribute sets become Product types or another supported structure	Confirm that required attributes, variants, and management rules remain available.
Image order or display crop changes	Confirm that required images are attached and usable; assign theme presentation work separately.
Tax representation differs	Confirm the intended Product tax relationship and document target-side calculation or configuration work separately.
Inventory locations are consolidated	Confirm that the consolidation was approved and that the resulting quantity and location meaning are correct.
Unsupported fields use an approved fallback	Confirm the field is available in the agreed target destination and can support the required task.

Do not approve an unexplained difference merely because the platforms use different data models.

Decide the catalog outcome

Pass

Use Pass when:

• the sample covers the required risk dimensions;
• required Products and Categories are present and correctly identified;
• field values and approved transformations meet the acceptance criteria;
• variants, images, Manufacturer, Tax, inventory, and Category relationships are correct where applicable;
• navigation and catalog usability meet the approved scope;
• Failed and Skipped records are resolved or understood;
• no unresolved Blocker or High-severity catalog issue remains.

Pass with accepted limitations

Use Pass with accepted limitations when:

• the difference is known and explained;
• it is permitted by the approved acceptance criteria;
• the operational and merchandising effect is understood;
• an authorized owner accepts it;
• any target-side cleanup or later validation has an owner and due date;
• the limitation does not make launch preparation materially unsafe.

Fail

Use Fail when:

• a required Product, Category, variant, image, or relationship is missing or incorrect;
• critical identifiers, prices, inventory values, or Category assignments do not meet the approved expectation;
• unexplained duplicates exist;
• Failed or Skipped records affect required scope;
• configuration behavior is incorrect;
• the catalog cannot support the intended merchandising, navigation, or Product-selection task;
• evidence is insufficient for approval.

Classify catalog failures before correction

Failure class	Safest corrective path
Wrong activity, environment, or source-data window	Stop validation and identify the correct migration result.
Source-data quality issue	Correct the source record or document an approved source limitation.
Selection or filtering issue	Review the selected data and applicable Data Filter behavior before another migration activity.
Additional Option issue	Correct the responsible option and define the affected Products or Categories for revalidation.
Attribute Mapping issue	Correct Inventory Location, Attribute Set, or Root Category Mapping and retest affected structures.
Advanced Data Mapping, Advanced Database Mapping, or Data Transformation issue	Correct the rule or destination and retest normal, boundary, and exception records.
Customization issue	Compare the result with the approved Custom Service requirement and request review when it differs.
Processing issue	Preserve the activity, data type, record identifiers, counts, and relevant log evidence before contacting support.
Platform-model limitation	Define the supported target representation and obtain approval for the documented difference.
Target-store setup or theme issue	Correct the target configuration without starting another migration activity unnecessarily.
Validation-method issue	Correct the source-target match, expand the sample, or collect missing evidence before deciding.

Do not start another migration activity before identifying the affected scope

A catalog issue may come from source data, configuration, target-store setup, or a platform-model difference. Determine the cause and the exact affected records before selecting another migration action.

Record the catalog validation output

Record:

• migration activity, target store, and review date;
• selected catalog scope and source-data window;
• sampled source and target Product or Category identifiers;
• checks performed and expected results;
• applicable Additional Options, mappings, Add-ons, and Customization;
• Success, Failed, and Skipped findings that affect the catalog;
• accepted platform differences and operational effects;
• open issues, severity, owner, due date, and corrective path;
• final Pass, Pass with accepted limitations, or Fail decision;
• reviewer and approval date.

Do not include credentials, access tokens, or unnecessary personal data in evidence. Use My Tickets when the issue requires Next-Cart review.

Next step

After Pass or Pass with accepted limitations, continue with Validate Customers and Orders.

After Fail, correct the classified cause and repeat the affected catalog checks. Do not repeat unaffected validation unless the corrective action could change those records or relationships.