Validate Full Migration Results

Validate Full Migration Results

A Full Migration result is ready to advance only when the completed activity, processed scope, configuration behavior, representative records, relationships, and accepted limitations are supported by evidence. Use this runbook to decide whether the result can proceed to detailed domain validation and launch preparation or must return to correction and revalidation.

A completed processing status is an entry condition, not acceptance. This page coordinates complete result validation without replacing the detailed checks for Products and Categories, Customers and Orders, Content, URLs and Redirects, sign-off, or launch readiness.

When to use this runbook

Use it after a Full Migration reaches a final state and the immediate execution review is complete. For later continuation or new-migration activity, first complete Validate Results After a Migration Action so the selected action and source-reading behavior are confirmed.

Do not begin another migration activity while an unexplained result, destructive target impact, or Entity Points discrepancy remains open.

Prepare the validation evidence

Collect evidence that identifies exactly what was run and what result should be accepted.

Evidence	Record
Purchased service	Migration path, service type, service status, and target store.
Migration activity	Completion time, action, Run Mode, and History entry.
Source-data window	Normal configured scope, resumed processing point, or newly added records since the last successful run.
Configuration	Selected data types, Additional Options, Attribute Mapping, purchased Add-ons, and approved Customization.
Processing result	Data-type progress, Success, Failed, and Skipped totals, and migration log where available.
Account evidence	Relevant Statistics and History information.
Acceptance baseline	Approved scope, sample plan, exact or transformed expectations, severity rules, and sign-off owners.
Record evidence	Stable source identifiers, target identifiers or URLs, expected result, and actual result.

Protect credentials and personal data in the validation record. Use only the evidence required to identify the issue and compare the result.

Confirm the activity and expected scope

Before sampling records, confirm that the evidence belongs to the intended migration result.

• Verify the Source Platform and Target Platform in the purchased migration path.
• Verify the correct purchased service and target environment.
• Record the migration action and Run Mode.
• Confirm whether Continue the previous migration or Migrate only newly added entities affected the source-data window.
• Confirm the approved configuration used for the activity.
• Record target records that had to remain protected and whether target-data clearing was approved.

Do not infer source scope from the migration action

The migration action and Source Platform Options control different parts of the activity. Validate the actual source-data window from the recorded configuration and processing evidence.

Reconcile processing before data acceptance

Review every selected data type that appears for the migration path. When all supported types are selected, the normal processing sequence is:

Taxes -> Manufacturers -> Categories -> Products -> Customers -> Orders -> Reviews -> Coupons -> CMS Pages -> Blog Posts

A data type can be absent when it is unsupported for the selected migration path or was not selected. Absence is acceptable only when it matches the approved scope and platform support.

Processing check	Pass condition
Final state	Every selected data type has a completed or reviewed terminal state.
Success	Successful records are available for validation in the target store.
Failed	Every Failed result is classified, and required scope is corrected or formally held.
Skipped	Every Skipped result has an understood reason consistent with filters, dependencies, source quality, platform support, or approved scope.
Totals	Source expectations, Success, Failed, Skipped, unsupported, and intentionally excluded records reconcile plausibly.
Log and History	Available evidence identifies the activity, result, and affected records.

Do not invent a universal acceptable variance. Exact totals are required when the approved scope and platform behavior make equality an exact requirement. Otherwise, reconcile differences against Failed, Skipped, filtered, unsupported, transformed, or accepted records.

Build the representative sample

Use risk, business importance, structural complexity, configuration impact, time range, and known exceptions. Increase the sample when the data model is complex, source quality is inconsistent, Failed or Skipped results are material, or Add-ons and Customization affect many records.

Sampling dimension	Include
Business importance	High-revenue Products, priority Customers, operationally important Orders, high-traffic Categories, and important content.
Structural complexity	Variants, multiple images, nested Categories, multiple addresses, discounts, tax, shipping, refunds, unusual statuses, and rich content.
Configuration impact	Preserved IDs, SEO URLs, redirects, imported images, HTML stripping, mappings, Add-ons, and Customization.
Time and source window	Older and recent records, records near the beginning and end of the intended source window, newly added records, or records near an interruption point.
Known risk	Demo findings, prior source-data issues, previously Failed or Skipped records, unsupported fields, and platform-model transformations.

The sample is sufficient only when it covers the acceptance criteria and the conditions most likely to fail. Do not declare a pass from a fixed sample size that omits material risk.

Validate the complete result

1. Identify the accepted migration result

   Confirm the migration path, purchased service, target store, activity, completion time, action, Run Mode, and source-data window.

2. Reconcile Success, Failed, and Skipped results

   Review each selected data type. Classify every Failed and unexpected Skipped result before moving to record-level validation.

3. Confirm the configuration evidence

   Verify that the selected data, Additional Options, mapping, purchased Add-ons, and approved Customization match the configuration approved for this activity.

4. Reconcile scope and totals

   Compare expected source scope with target presence and processing evidence. Account for unsupported, filtered, failed, skipped, transformed, or intentionally excluded records.

5. Validate representative records and relationships

   Check presence, identity, required fields, approved transformations, relationships, and operational usability across the applicable data types.

6. Validate Additional Options

   Test the records affected by source-reading behavior, target-data clearing, HTML stripping, description-image import, ID preservation, SEO URLs, redirects, completion notification, and detailed reporting when those options were available and selected.

7. Validate Attribute Mapping

   Test applicable Site, Language, Inventory Location, Attribute Set, Root Category, Customer Group, Order Payment Status, and Order Fulfillment Status mappings. Confirm that each mapped value preserves the approved operational meaning.

8. Validate purchased Add-ons and approved Customization

   Test normal, boundary, and exception records affected by Data Filter, Advanced Data Mapping, Advanced Database Mapping, Data Transformation, and each selected Customization item. Confirm that combined behavior does not break required relationships.

9. Confirm target protection and clearing behavior

   Verify that manual, previously accepted, and application-created target records were preserved, replaced, or deleted only as approved. Stop further activity when destructive impact is unexplained.

10. Reconcile Entity Points

    Compare Entity Points usage with newly eligible records that migrated successfully for the first time. Previously counted records should not consume points again merely because another supported action processed them.

11. Classify differences and assign severity

    Classify each finding before selecting a corrective path. Assign Blocker, High, Medium, or Low severity based on its effect on required data integrity, operation, or launch preparation.

12. Record the validation decision and handoff

    Assign Pass, Pass with accepted limitations, or Fail. Record the evidence, accepted limitations, open issues, owners, and the detailed validation pages that must be completed next.

Validate configuration behavior

Configuration area	Testable pass condition
Data selection	Each selected supported data type is represented in the result, and exclusions match the approved scope.
Continue the previous migration	Processing resumed from the intended interruption point without unexplained omission or duplication.
Migrate only newly added entities	The activity processed records added after the last successful run; updates to existing records were not expected through this option.
Clear data on Target Store before Migration	Only the approved target data types and records were deleted, and required protected records remain.
Strip HTML tags	Affected Category and Product names match the approved plain-text expectation.
Import description images	Required supported images are present and associated with the correct target content.
Preserve Customer IDs	Supported Customer identifiers match the approved source identifiers without target conflicts.
Preserve Order IDs	Supported Order identifiers match the approved source identifiers without target conflicts.
Migrate SEO URLs	Supported priority URLs match the approved target behavior.
Create 301 redirects	Tested source URLs redirect to the intended target destinations without loops or incorrect chains.
Attribute Mapping	Applicable source values have the intended target Site, Language, Inventory Location, Attribute Set, Root Category, Customer Group, Payment Status, or Fulfillment Status.
Add-ons	Filters, supported field or database destinations, and transformations produce the approved record scope and values.
Customization	Each selected item meets its approved acceptance examples without conflicting with standard configuration or Add-ons.

Only test options, mappings, Add-ons, and Customization that were available and included for the purchased migration path.

Validate records and relationships

At this stage, confirm that the complete result is suitable for detailed domain validation. Do not duplicate every field-level check owned by the domain pages.

Area	Minimum coordination check
Taxes and Manufacturers	Required support records exist and link to applicable Products or Orders.
Categories and Products	Representative catalog records exist, retain required relationships, and remain usable for navigation and merchandising review.
Customers and Orders	Representative identities, addresses, line items, totals, statuses, and Customer-Order-Product relationships are present for detailed review.
Reviews and Coupons	Selected supported records exist and relate to the intended Products, Customers, or discount behavior.
CMS Pages and Blog Posts	Selected content exists with required relationships and can advance to content and URL validation.

Decide the Full Migration outcome

Pass

Use Pass when:

• the correct activity, configuration, and source-data window are confirmed;
• selected data types and processing results reconcile;
• representative records and critical relationships meet approved expectations;
• Additional Options, mappings, Add-ons, and Customization behave as intended;
• target protection and Entity Points usage are explainable;
• no unresolved Blocker or High-severity issue prevents detailed acceptance work;
• required evidence is recorded.

Pass with accepted limitations

Use Pass with accepted limitations when:

• every limitation is known and explained;
• the platform-model difference or approved exception is permitted by the acceptance criteria;
• customer impact is understood;
• an authorized owner accepts the limitation;
• follow-up work and its owner are recorded;
• the limitation does not make further validation or launch preparation materially unsafe.

Fail

Use Fail when:

• the wrong activity, path, environment, configuration, or source-data window was used;
• required records or relationships are missing or incorrect;
• Failed or Skipped results affect required scope and remain unresolved;
• configuration behavior is incorrect;
• destructive target impact is unexplained;
• Entity Points usage cannot be reconciled;
• evidence is insufficient to support acceptance.

Classify failures and select the corrective path

Failure class	Corrective path
Wrong activity or environment	Stop validation and identify the correct result before any further action.
Connection or source-access issue	Restore and verify the supported connection, then determine the safe continuation path.
Source-data quality issue	Correct the source record or document an approved source limitation.
Selection or source-window issue	Correct the Data selection or Source Platform Options before another activity.
Additional Option issue	Correct the responsible option and define the records that require revalidation.
Mapping issue	Correct the applicable standard mapping and retest affected values and relationships.
Add-on issue	Correct the filter, mapping, database mapping, or transformation and retest affected records.
Customization issue	Compare the result with the approved Custom Service requirement and request review when behavior differs.
Processing issue	Preserve the log, counts, data type, and record examples before contacting support.
Platform-model limitation	Define the supported target representation and obtain acceptance for the documented difference.
Target-store setup issue	Correct the target configuration without starting another migration activity unnecessarily.
Validation-method or evidence issue	Expand the sample, correct the comparison method, or collect missing evidence before deciding.

Hold further activity after unexplained destructive impact

Do not start another migration action when required target records were deleted, replaced, or changed outside the approved scope. Preserve the current target state and evidence, apply the recovery plan, and contact support.

Record the sign-off and handoff output

Record:

• purchased service, migration path, and target store;
• migration activity, completion time, action, and Run Mode;
• source-data window and Source Platform Options;
• configuration summary and selected data types;
• Success, Failed, and Skipped totals by data type;
• reconciliation of expected scope and target totals;
• sampled source and target identifiers;
• Additional Option, mapping, Add-on, and Customization results;
• target protection and clearing result;
• Entity Points result;
• accepted limitations;
• open issues, severity, owner, due date, and corrective path;
• final Pass, Pass with accepted limitations, or Fail decision;
• reviewer and approval date;
• required domain-validation handoffs.

Next step

After Pass or Pass with accepted limitations, continue with the detailed checks that apply to the approved scope:

• Validate Products and Categories
• Validate Customers and Orders
• Validate Content, URLs, and Redirects
• Define Sign-off Criteria

After Fail, correct the classified cause and repeat only the affected validation after the safe corrective action is complete. Use My Tickets when the issue requires Next-Cart review.