Validate Demo Results

Validate Demo Results

A validated Demo result should give you enough evidence to decide whether the migration path and available standard behavior are suitable for the intended Full Migration. Use this checklist to approve the Demo evidence, identify changes required before Full Migration, or stop for support or Custom Service review.

A Demo is limited by design. It can confirm representative data structure, relationships, available options, and standard mapping behavior, but it cannot prove complete data coverage, purchased Add-on behavior, approved Customization, identifier preservation, or launch readiness.

When to use this checklist

Use this checklist after the Demo Migration reaches a final state and after you have completed the immediate result review in Review Demo Results.

Complete the checklist before you finalize the purchased migration configuration or rely on the Demo as evidence that a Full Migration is ready to run.

Prepare the validation evidence

Collect the following before you begin:

• the completed Demo activity and completion time;
• the Source Platform and Target Platform used for the Demo;
• the selected Demo data types;
• Success, Failed, and Skipped results where available;
• stable source identifiers for the sampled records;
• access to the corresponding target-store records and storefront output where applicable;
• the expected values, relationships, and platform-model conversions available in Demo;
• the acceptance criteria that apply to the Demo;
• a findings record with an owner for each unresolved issue.

Validate the correct evidence

Confirm the target store and Demo activity before comparing records. A valid comparison must use records produced by the intended Demo, not records from an earlier test, another migration path, or manual target-store work.

Account for Demo scope and limitations

Validate the Demo against the scope it is designed to prove, not against Full Migration coverage. Use the complete limits in Run a Demo Migration before classifying a missing data type, unavailable Add-on, identifier behavior, support record, or sample-size difference as a defect.

Record any behavior that must still be validated through the purchased service, an Add-on, approved Customization, or target-store configuration.

Build a representative Demo sample

Do not validate only the simplest or most visually obvious records. Use the available Demo result to cover the highest-value and highest-risk examples present in the sample.

Area	Include when available	Validation purpose
Products	A simple Product, a Product with variants or options, multiple images, special pricing, inventory, or important attributes	Confirm structure, values, images, and target usability.
Manufacturers and Categories	Brand relationships, nested Categories, and Products assigned to important Categories	Confirm support-data relationships and navigation structure.
Customers	A Customer with complete contact details, multiple addresses, or a meaningful Customer Group	Confirm identity, addresses, and supported group behavior.
Orders	An Order with several line items, discounts, tax, shipping, or a meaningful status	Confirm totals, statuses, and Product-Customer relationships.
Taxes	Tax-related Product or historical Order values	Confirm that required tax relationships or values are represented as expected.
Pages	A Page with images, links, formatting, dates, or status	Confirm content presence, presentation, and editability where applicable.
Known edge cases	Records with source-data issues, unusual structures, or expected platform-model transformations	Confirm whether the intended fallback or transformation is acceptable.

If the Demo result does not contain a record needed to test a critical requirement, mark that requirement as not demonstrated by Demo. Do not convert missing evidence into a pass.

Validate the Demo result

1. Confirm the Demo activity and scope

   Verify the migration path, completion time, selected data types, and the target store that received the sample. Record any Failed or Skipped results before reviewing individual records.

2. Reconcile the available sample

   Confirm that the target records correspond to the intended source sample. Use stable identifiers such as SKU, email address, Order number, or Page title rather than relying only on record counts.

3. Check record presence and identity

   Verify that each required sampled record exists in the target store and represents the correct source object.

4. Check fields and available platform-model conversions

   Compare required values with the acceptance criteria. Use exact matching for identifiers, required presence, and relationships when exact preservation is expected. Use approved equivalence when the target platform represents the same business meaning differently.

5. Check relationships

   Confirm Product-Manufacturer, Product-Category, Order-Customer, Order-Product, image, address, and other relationships that are relevant to the selected sample.

6. Check operational usability

   Confirm that sampled records can be found, opened, edited, displayed, or otherwise used as required by the Demo acceptance criteria.

7. Check available options and mappings

   Verify that the options and standard mappings available in Demo produced the intended result. Record every setting that must change before Full Migration.

8. Classify every difference

   Classify each difference as a Demo limitation, source-data issue, standard configuration issue, platform-model difference, target-store setup issue, support issue, or requirement for an Add-on or Custom Service.

9. Record the Demo decision

   Assign Pass, Pass with accepted limitations, or Fail. Record the evidence, accepted limitations, unresolved issues, owners, and required next action.

Apply testable checks

Check	Pass condition
Activity	The result belongs to the intended Demo activity, migration path, and target store.
Processing evidence	Failed and Skipped results are understood and do not invalidate the required sample.
Presence and identity	Required sampled records exist and match the intended source records.
Field accuracy	Required values match the expected source values or the supported platform-model conversion available in Demo; configured Add-on or Customization output remains untested.
Relationships	Required support-data and cross-record relationships remain intact.
Operational usability	Sampled records can support the intended review or target-store task.
Options and mappings	Available Demo settings produced the intended result or a documented change is required.
Evidence coverage	Every critical Demo acceptance criterion is demonstrated or explicitly marked for later validation.

Decide the Demo outcome

Pass

Use Pass when:

• the representative sample meets the Demo acceptance criteria;
• no unexplained high-severity discrepancy remains;
• Failed and Skipped results are resolved or understood;
• required relationships and available configuration behavior are correct;
• remaining requirements are clearly assigned to Full Migration, purchased features, or target-store readiness checks.

Pass with accepted limitations

Use Pass with accepted limitations when:

• the difference is expected and explained;
• the limitation is permitted by the acceptance criteria;
• the operational effect is understood;
• an authorized owner accepts the limitation;
• any required follow-up validation or corrective work has an owner.

A Demo limitation alone does not justify an accepted limitation for the final migration result. It only records that the requirement remains untested in Demo.

Fail

Use Fail when:

• a required sampled record or relationship is missing or incorrect;
• an unexplained discrepancy remains;
• Failed or Skipped records invalidate the required evidence;
• the available configuration cannot produce the required standard result;
• the evidence is insufficient to support the decision to proceed.

Classify failures before changing the setup

Failure class	Safest next action
Wrong activity, path, or target store	Stop the review and identify the correct Demo evidence.
Connection or source-access issue	Correct and verify the supported connection setup before another Demo.
Source-data quality issue	Correct the source record or document an approved source limitation.
Data selection or standard option issue	Correct the available Demo setting and repeat the check, or record the required paid configuration when the control is unavailable in Demo.
Standard mapping issue	Review the available Demo mapping and repeat the check where possible. Record any unavailable or Add-on-dependent adjustment for paid configuration and validation.
Add-on requirement	Confirm that the required Add-on is included in the purchased service and define its validation examples.
Custom Service requirement	Document the unsupported data or tailored processing requirement for review.
Platform-model difference	Define the supported target representation and acceptance condition.
Target-store setup issue	Correct the target configuration, then repeat the affected check.
Processing issue	Preserve the affected data type, identifiers, status, and available error evidence before contacting support.

Do not approve a Demo from appearance alone

A record can look acceptable while identifiers, relationships, status mappings, totals, or source scope are wrong. Base the decision on testable evidence, not only storefront presentation.

Record the sign-off output

Record:

• Demo activity and completion time;
• migration path and target store;
• selected data types;
• Success, Failed, and Skipped results where available;
• sampled source and target identifiers;
• checks performed and results;
• Demo limitations that remain for later validation;
• accepted platform-model differences;
• required configuration changes;
• required Add-ons or Custom Service review;
• open issues, severity, owner, and next action;
• final Pass, Pass with accepted limitations, or Fail decision;
• reviewer and approval date.

Next Steps

After Pass or Pass with accepted limitations, apply every approved change in Configure Your Migration and complete Review Migration Configuration.

After Fail, resolve the classified issue before approving the Full Migration configuration. Use Support Tickets when the evidence indicates a processing, entitlement, or unsupported-behavior issue that requires Next-Cart review.