Validate Customers and Orders

Validate Customers and Orders

Customer and Order data is ready for approval when representative identities, addresses, groups, historical transactions, totals, statuses, and relationships meet the approved business and support requirements. Use this checklist to verify the migrated result without exposing customer credentials, payment details, or unnecessary personal data.

This validation confirms migrated historical data and supported account behavior. It does not authorize payment capture, refunds, fulfillment actions, or launch; those operational systems require separate target-store readiness checks.

When to use this checklist

Use this checklist after Validate Full Migration Results confirms that the completed activity and overall scope can advance to detailed validation.

Validate Products first when Order acceptance depends on Product links, identifiers, or catalog relationships. Complete this checklist before final sign-off and launch preparation.

Prepare customer and Order evidence

Collect:

• the completed migration activity, target store, and source-data window;
• selected Customers and Orders scope;
• Success, Failed, and Skipped results for Customers and Orders;
• stable source identifiers such as Customer ID, email address, Order ID, or Order number;
• target Customer and Order identifiers;
• approved expectations for Customer ID and Order ID preservation when those options were enabled and supported;
• applicable Customer Group, Order Payment Status, and Order Fulfillment Status mappings;
• records affected by Data Filter, Advanced Data Mapping, Advanced Database Mapping, Data Transformation, or approved Customization;
• accepted password or customer-access behavior;
• approved total tolerances or transformed expectations where exact equality is not required;
• a privacy-conscious findings record with severity, owner, and required next action.

Protect customer and payment data

Do not collect or share plaintext passwords, complete payment-card data, access tokens, or unnecessary personal details. Mask email addresses, phone numbers, and street addresses when full values are not required to identify the issue. Use secure evidence-sharing methods requested by Next-Cart support.

Build a representative Customer sample

Select enough Customers to cover the conditions that matter to account access, segmentation, service, and Order history.

Sample dimension	Include when available	Validation purpose
Address conditions	Customers with one address, multiple addresses, separate billing and shipping addresses, and incomplete optional address fields	Confirm address presence, ownership, and supported structure.
Customer classification	Customers in important Customer Groups, segments, tax groups, wholesale groups, or default groups	Confirm Customer Group Mapping and operational meaning.
Relationship conditions	Customers with multiple Orders, Customers with no Orders, and guest Orders where supported	Confirm identity and Order ownership without forcing unsupported relationships.
Time range	Older and recent Customers, plus records near the beginning and end of the intended source-data window	Detect incomplete scope.
Known risk	Duplicate emails, unusual characters, source-data issues, Demo findings, and previously Failed or Skipped records	Confirm resolution or approved handling.
Configuration impact	Customers affected by ID preservation, filtering, supported field or database mapping, transformation, or Customization	Confirm configuration behavior.

Build a representative Order sample

Include Orders that expose financial, status, fulfillment, and relationship complexity.

Sample dimension	Include when available	Validation purpose
Time range	Recent Orders, older Orders, and records near the source-data window boundaries	Confirm complete intended history.
Financial complexity	Orders with discounts, coupons, shipping, tax, multiple line items, or more than one currency	Confirm line composition and totals.
Lifecycle state	Paid, pending, failed, refunded, cancelled, shipped, delivered, returned, unfulfilled, and partially fulfilled Orders	Confirm payment and fulfillment meaning after mapping.
Relationship complexity	Orders linked to registered Customers, guest Orders, Products with variants, and Products no longer active	Confirm Customer-Order-Product relationships and historical usability.
Business importance	High-value Orders, frequently referenced Orders, and Orders important to support or accounting	Prioritize operational risk.
Known exceptions	Previously Failed or Skipped Orders, unusual source records, and approved platform-model transformations	Confirm corrective or accepted handling.

Increase the sample when Customer data is inconsistent, status mapping is complex, totals differ unexpectedly, or failures affect more than one Order pattern.

Run the Customer and Order checks

1. Confirm the activity and scope

   Verify the migration activity, target store, migration path, source-data window, and selected Customers and Orders. Confirm that the sampled records belong to the intended result.

2. Reconcile processing evidence

   Review Success, Failed, and Skipped results. Classify every Failed and unexpected Skipped Customer or Order that affects required history, relationships, or acceptance coverage.

3. Confirm Customer presence and identity

   Match each sampled target Customer to the intended source Customer using approved identifiers. Confirm that required Customers exist once unless the acceptance criteria explicitly allow another representation.

4. Validate Customer fields and addresses

   Compare required names, email addresses, contact fields, account status, dates, and billing or shipping addresses. Confirm address ownership and default-address behavior where supported and required.

5. Validate Customer Groups and identifiers

   Confirm that Customer Group Mapping preserves the approved pricing, tax, visibility, permission, or B2B meaning. When Preserve Customer IDs on Target Store was enabled and supported, verify the sampled identifiers and confirm that no target conflict changed the approved result.

6. Validate customer-access expectations

   Test only the documented behavior approved for the migration path. This may require a password reset path or another supported password-transfer method. Use designated test accounts and never request, compare, or record plaintext customer passwords.

7. Confirm Order presence and identity

   Match each sampled target Order to the intended source Order. When Preserve Order IDs on Target Store was enabled and supported, verify the sampled identifiers and confirm that numbering or target conflicts did not change the approved result.

8. Validate Order relationships and line items

   Confirm the intended Customer or guest ownership, Product and variant references where supported, line-item names or identifiers, quantities, unit values, and required historical snapshots. An inactive or deleted current Product must not make the historical Order unintelligible.

9. Validate financial composition

   Compare subtotal, discounts, coupon effects where applicable, shipping, tax, refunds or adjustments, and total. Confirm currency and approved rounding or tax-model differences. Do not invent a universal tolerance; apply the acceptance criteria defined for the migration.

10. Validate dates and statuses

    Confirm required creation and update dates, Order status, mapped payment status, and mapped fulfillment status. Validate the operational meaning of the target status, not only its displayed label.

11. Validate complex Order states

    For refunded, cancelled, shipped, returned, and partially fulfilled Orders, confirm that the target history preserves the approved state and amounts without making a historical transaction appear newly actionable.

12. Validate affected configuration behavior

    Test normal, boundary, and exception records affected by Customer or Order filtering, supported field or database destinations, transformation, status mapping, ID preservation, or Customization. Confirm that the rules did not break required relationships.

13. Check operational usability

    Confirm that authorized staff can find and interpret the sampled Customers and Orders for the approved service, support, accounting, or historical-reference use cases. Validate customer sign-in and live Order processing separately during launch readiness where applicable.

14. 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 Customer checks

Area	Pass condition
Presence and identity	Every required sampled Customer exists and represents the correct source Customer.
Core fields	Required identity, contact, status, and date fields are exact or transformed according to an approved rule.
Addresses	Required billing and shipping addresses exist, belong to the correct Customer, and retain the approved structure.
Customer Groups	Each sampled Customer has the intended target group or approved equivalent.
Preserved Customer IDs	When enabled and supported, sampled target identifiers match the approved source identifiers without conflicts.
Customer access	The documented reset or supported transfer behavior works for designated test accounts without exposing credentials.
Relationships	Customer-linked Orders appear under the correct Customer where the target model supports that relationship.

Apply testable Order checks

Area	Pass condition
Presence and identity	Every required sampled Order exists and represents the correct source transaction.
Preserved Order IDs	When enabled and supported, sampled target identifiers match the approved source identifiers without conflicts.
Customer relationship	The Order belongs to the correct Customer or approved guest representation.
Product and line-item relationships	Required Products, variants, line-item identifiers, quantities, and historical descriptions remain understandable and correctly associated.
Financial values	Subtotal, discounts, shipping, tax, refunds or adjustments, currency, and total meet exact or approved transformed expectations.
Dates	Required Order dates preserve the intended historical meaning.
Payment status	The mapped target status preserves the approved financial meaning, including paid, pending, failed, or refunded states where applicable.
Fulfillment status	The mapped target status preserves the approved fulfillment meaning, including unfulfilled, partial, shipped, delivered, returned, or cancelled states where applicable.
Operational usability	Authorized staff can locate and interpret the Order for the approved support, accounting, or historical-reference task.

Interpret expected platform differences

Difference	Acceptance approach
Customer Groups use different labels or structures	Confirm that the required pricing, tax, visibility, permission, or B2B meaning is retained.
Passwords cannot be transferred directly	Confirm the approved reset or supported password-transfer path and customer communication requirement.
Original identifiers cannot be native target IDs	Confirm the approved fallback field is searchable and available to the teams that need it.
Payment and fulfillment labels differ	Confirm the target states preserve the approved financial and operational meaning.
Tax or discount totals differ under a documented model	Reconcile line composition and approved rounding or tax behavior; do not accept an unexplained difference.
Historical Product references use snapshots	Confirm the Order remains understandable and supports the approved service or accounting use case.
Guest Orders use a different target representation	Confirm that guest identity and Order history remain usable according to the acceptance criteria.

Decide the Customer and Order outcome

Pass

Use Pass when:

• the samples cover the required Customer and Order risk dimensions;
• required records are present and correctly identified;
• addresses, groups, identifiers, line items, financial values, dates, and statuses meet approved expectations;
• Customer-Order-Product relationships are correct where supported;
• password or customer-access behavior matches the documented expectation;
• Failed and Skipped records are resolved or understood;
• no unresolved Blocker or High-severity 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;
• customer, support, financial, and operational effects are understood;
• an authorized owner accepts it;
• mitigation, customer communication, or later work has an owner and due date;
• the limitation does not make launch preparation materially unsafe.

Fail

Use Fail when:

• a required Customer, address, Order, line item, or critical relationship is missing or incorrect;
• identifiers, totals, currency, dates, payment status, or fulfillment status do not meet the approved expectation;
• customer-access behavior is unsupported or untested for a required use case;
• Failed or Skipped records affect required scope;
• configuration behavior is incorrect;
• privacy-safe evidence is insufficient for approval;
• the result cannot support the approved customer-service, accounting, or historical-reference use case.

Classify failures before correction

Failure class	Safest corrective path
Wrong activity, environment, or source-data window	Stop validation and identify the correct result.
Source-data quality issue	Correct the source record or document an approved source limitation.
Selection or filtering issue	Review selected Customers and Orders and applicable Data Filter behavior before another migration activity.
Customer or Order ID preservation issue	Review the responsible Additional Option, target conflicts, and approved fallback before reprocessing.
Customer Group or status mapping issue	Correct the applicable mapping and retest affected Customers, Orders, and related operational meaning.
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, 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 account or Order configuration issue	Correct the target configuration without starting another migration activity unnecessarily.
Validation-method or evidence issue	Correct the record match, expand the sample, or collect privacy-safe evidence before deciding.

Do not perform live financial actions as a validation shortcut

Historical Order validation must not trigger a new charge, refund, shipment, or customer notification. Use target-store test methods and launch-readiness procedures for live operational behavior.

Record the Customer and Order validation output

Record:

• migration activity, target store, source-data window, and review date;
• selected Customer and Order scope;
• sampled source and target identifiers using masked personal data where possible;
• checks performed and expected results;
• applicable ID-preservation options, mappings, Add-ons, and Customization;
• Success, Failed, and Skipped findings;
• exact or approved transformed financial expectations;
• documented password or customer-access behavior;
• 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.

Use My Tickets when an issue requires Next-Cart review. Include only the minimum personal data necessary to identify the affected records.

Next step

After Pass or Pass with accepted limitations, continue with Validate Content, URLs, and Redirects.

After Fail, correct the classified cause and repeat only the affected Customer or Order checks. Repeat related Product validation when the corrective action could change Product or variant relationships.