Define Acceptance Criteria

Define Acceptance Criteria

Define acceptance criteria before you run migration work beyond basic setup.

Acceptance criteria describe what the migrated result must satisfy before you approve the result, continue to the next migration stage, or prepare the target store for launch.

Acceptance criteria must be testable

A useful acceptance criterion names the data area, the sample to check, the expected result, and the condition that would block sign-off.

Prerequisites

Before defining acceptance criteria, confirm that:

Requirement	Why it matters
Migration scope is defined	Acceptance criteria must match the data types, filters, Add-ons, and Custom Service requirements in scope.
Source Platform and Target Platform are confirmed	Platform data models affect what can be preserved exactly and what may need target-side configuration.
Purchased migration details are known	The Migration Service, Add-ons, Entity Points Plan, and approved custom work affect what should be reviewed.
Validation owner is assigned	Someone must decide whether the target store result is acceptable.
Sample records are available	Validation depends on representative Products, Customers, Orders, CMS pages, and other in-scope data types.
Known constraints are documented	Some differences come from target platform behavior rather than migration failure.

Acceptance criteria workflow

1. Confirm the migration scope.

   Review the data types, exclusions, filters, Add-ons, Custom Service requirements, and expected target behavior already defined for the migration service.

2. Choose representative validation samples.

   Select records that reflect real business risk. Include normal records, high-value records, complex records, and known edge cases.

3. Write pass conditions for each important data area.

   Describe what the target store must show for each sample to pass. Use observable fields, relationships, totals, statuses, URLs, or behavior.

4. Define acceptable differences.

   Document differences that are allowed because of Target Platform behavior, supported limitations, or approved fallback handling.

5. Classify issue severity.

   Use severity levels so blockers, high-priority issues, medium-priority issues, and low-priority differences are handled consistently.

6. Identify sign-off blockers.

   List the issues that must be resolved before Full Migration, launch preparation, or final approval can continue.

7. Prepare evidence requirements.

   Decide what screenshots, record IDs, order numbers, SKUs, customer emails, URLs, or notes must be included when reporting an issue.

8. Confirm the next action for each result.

   Decide whether the result should proceed, require configuration changes, require Custom Service review, require support investigation, or move to launch readiness.

Acceptance criteria worksheet

Use this structure before migration work begins.

Area	What to define	Example
Data type	The data area being validated	Products, Categories, Customers, Orders, Reviews, Coupons, CMS pages.
Sample set	The records you will inspect	Top products, complex variants, refunded orders, repeat customers, priority landing pages.
Expected result	What the target store should show	Product title, SKU, price, image, variants, and category assignment match the approved expectation.
Allowed difference	Differences that do not block approval	Target Platform changes display labels, URL format, or order status wording while preserving meaning.
Blocker condition	What prevents approval	Missing order line items, broken product relationships, inaccessible priority URLs, or incorrect customer-order links.
Evidence required	What must be included in an issue report	SKU, order number, customer email, screenshot, target URL, expected result, and severity.
Owner	Who confirms the result	Store owner, project owner, catalog owner, finance owner, SEO owner, or technical owner.

Recommended validation samples

Choose samples that expose important relationships and edge cases.

Data area	Recommended samples	What to confirm
Products	Top sellers, complex variants, products with many images, products with sale pricing, products with custom attributes.	Names, SKUs, pricing, variants, options, status, visibility, images, category links, and metadata.
Categories	Main navigation categories, nested categories, high-volume categories, categories used for campaigns.	Hierarchy, product assignment, collection behavior, URLs, and visibility.
Manufacturers	High-priority brands, products with manufacturer associations, products with missing or unusual brand values.	Manufacturer values are preserved or mapped to the approved target location.
Customers	Repeat customers, customers with multiple addresses, recently created customers, customers linked to orders.	Contact fields, addresses, groups where supported, customer-to-order relationships, and login expectations.
Orders	Recent orders, older orders, refunded orders, cancelled orders, partially fulfilled orders, high-value orders.	Line items, quantities, totals, tax lines, discounts, status mapping, fulfillment details, and customer links.
Reviews	Products with multiple reviews, moderated reviews, reviews with ratings and text.	Product association, reviewer details where supported, rating, text, and publication status.
Coupons	Active promotions, expired promotions, percentage discounts, fixed discounts, campaign-specific codes.	Code, status, rule behavior, date handling, and Target Platform compatibility.
CMS pages	Priority CMS pages, policy pages, landing pages, content with images or embedded HTML.	Page existence, title, content, metadata, URL behavior, and any layout differences that require target-side work.
SEO URLs	High-traffic products, categories, CMS pages, campaign URLs, organic landing pages.	Redirect target, no critical 404s, no redirect loops, and correct destination pages.

Pass condition examples

Write pass conditions as specific, observable checks.

Weak criterion	Stronger criterion
Products look good.	The sampled Products show correct title, SKU, price, main image, variant options, and assigned Categories in the target store.
Orders migrated correctly.	The sampled Orders show correct customer link, line items, quantities, discounts, tax lines, totals within approved tolerance, and status mapping.
Customers are fine.	The sampled Customers show correct email, name, addresses, customer group where supported, and linked order history.
URLs work.	Each priority source URL redirects to the correct target page without a critical 404, loop, or unrelated destination.
Custom data is included.	Each approved Custom Service sample shows the specified source field in the agreed target destination with the approved transformation.

Issue severity levels

Use severity to decide what must be fixed before the next step.

Severity	Definition	Examples	Action
Blocker	Prevents approval, launch preparation, or core store operation.	Missing order line items, broken customer-order relationships, inaccessible target store, critical products missing, checkout-impacting data issue.	Stop and contact support with evidence.
High	Affects important business data but may not block every workflow.	Top products missing images, high-value category assignment wrong, priority redirects failing, major status mapping mismatch.	Resolve before sign-off unless approved by the business owner.
Medium	Causes review or operational friction but has a manageable workaround.	Some display formatting differences, lower-priority metadata mismatch, non-critical content cleanup.	Track and resolve before or after launch based on risk.
Low	Cosmetic or expected target-side adjustment.	Theme formatting differences, minor content spacing, target platform label differences.	Record as post-launch or target-side cleanup if needed.

Do not approve a result with unresolved blockers

If a blocker affects core catalog, customer, order, payment, checkout, URL, or launch-critical behavior, resolve it or explicitly defer it with written business approval before continuing.

Handling platform differences

Some differences are expected because platforms store and display data differently.

Difference type	How to handle it
Category structure becomes collection-style grouping	Validate whether products are grouped correctly and navigation can be configured on the target store.
Order status labels differ	Confirm the status meaning and fulfillment state, not only the label text.
Tax or discount totals differ slightly	Compare line-level composition and confirm whether target tax settings or rounding rules explain the difference.
CMS page layout changes	Confirm content exists and decide whether layout cleanup belongs to target-side theme or page-builder work.
Original order identifier cannot be displayed natively	Confirm the approved fallback field is searchable and visible where support teams need it.
Customer passwords cannot be carried over	Validate the password reset path or Customer Password Plugin path where supported.

Sign-off criteria

Use sign-off only after validation results are clear.

A migration result is ready for sign-off when:

• in-scope data types have been checked against the agreed sample plan;
• blocker issues are resolved or formally deferred;
• high-severity issues have an approved resolution or owner;
• Custom Service requirements have been validated against approved examples;
• known platform differences are documented and accepted;
• launch-critical checks have owners and next steps;
• support tickets include evidence for any remaining issue.

Expected result

After defining acceptance criteria:

• validation samples are selected;
• pass conditions are written for each important data area;
• acceptable differences are documented;
• issue severity levels are defined;
• blockers are identified;
• evidence requirements are clear;
• sign-off rules are ready before migration execution or validation begins.

Verification

Before moving to connection setup, configuration, or execution, confirm these checks:

Check	Pass condition
Scope alignment	Acceptance criteria match the defined migration scope.
Sample coverage	Samples include normal records, complex records, business-critical records, and edge cases.
Data-area coverage	Products, Categories, Customers, Orders, and other in-scope data types have pass conditions.
Custom Service coverage	Custom Service requirements have specific examples and validation rules.
Severity coverage	Blocker, high, medium, and low issue handling is defined.
Evidence coverage	Issue reports require record IDs, screenshots, expected result, and affected area.
Owner coverage	A person or team is responsible for approval.
Next-step coverage	You know whether validation leads to configuration changes, support investigation, another migration action, or launch preparation.

Failure handling

Issue	What to do
Criteria are too vague	Rewrite them with specific records, fields, relationships, and pass conditions.
Samples do not represent real business risk	Add top products, complex variants, recent and historical orders, priority URLs, and Custom Service examples.
Stakeholders disagree on what passes	Resolve the decision before Full Migration or launch preparation.
A difference may be target platform behavior	Document the difference, confirm whether it is expected, and decide whether target-side configuration is needed.
A blocker appears during validation	Open or update a support ticket with severity, examples, screenshots, expected result, and affected record IDs.
Data volume changes before execution	Recheck the Entity Points Plan before attempting to complete migration work.
Remaining source data must be brought into the target store	Use the appropriate current migration action instead of manually importing remaining data.

What not to do

Do not:

• approve migration results based only on total record counts;
• validate only the easiest records;
• ignore relationships between Orders, Customers, Products, Taxes, discounts, and statuses;
• treat expected platform differences as blockers without checking target behavior;
• treat blockers as cosmetic issues;
• manually import remaining source data into the target store to bypass plan or validation issues;
• start launch preparation without validation ownership and sign-off criteria.

Next step

If your acceptance criteria are ready	Go to
You need to set up platform access	Prepare Source and Target Store Access
You need to complete Custom Service details	Prepare Custom Service Requirements
You are ready to connect platforms	Connect Your Source and Target Platforms
You are ready to select data and options	Configure Your Migration
You need to run a limited validation sample	Run a Demo Migration
You found a blocker	Tickets
You need validation guidance later	Validate and Launch Your Target Store