Define Sign-off Criteria

Define Sign-off Criteria

A migration result is ready for sign-off when the approved scope has been validated, required evidence supports the decision, unresolved limitations are explicitly accepted, and every blocking issue has a defined disposition. Use this page to convert completed validation work into a controlled Pass, Pass with accepted limitations, or Fail decision.

This sign-off approves the migrated result for the next project stage. It does not by itself authorize launch; target-store operational readiness and the final go or no-go decision are completed in the launch-readiness review.

When to define final sign-off criteria

Use this page after the applicable result and domain checks are complete:

• Validate Full Migration Results;
• Validate Products and Categories when catalog data is in scope;
• Validate Customers and Orders when Customer or Order data is in scope;
• Validate Content, URLs, and Redirects when content or URL continuity is in scope.

Use the initial criteria from Define Acceptance Criteria as the baseline. Final sign-off may clarify evidence, owners, and accepted limitations, but it must not quietly weaken an unmet requirement after validation.

Prepare the sign-off baseline

Before deciding, record the result that is being approved:

Baseline item	Record
Migration identity	Purchased service, Source Platform, Target Platform, migration activity, completion date, and target store.
Execution context	Migration action, Run Mode, source-data window, and applicable Source Platform Options.
Approved scope	Selected data types, exclusions, expected totals or scope, and required business use cases.
Configuration	Applicable Additional Options and Attribute Mapping groups.
Extended behavior	Purchased Add-ons and approved Customization, each kept separate.
Expected differences	Platform-model transformations, unsupported fields, target-side work, and approved fallback behavior.
Validation evidence	Execution results, samples, checks, findings, accepted limitations, and open issues from each required validation area.

If the baseline cannot identify which result, scope, and expectations are being approved, the evidence is not ready for sign-off.

Assign approval roles

Assign named owners before the decision is recorded.

Role	Approval responsibility
Migration owner	Confirms the migration activity, approved scope, configuration evidence, validation coverage, and issue record are complete.
Business owner	Confirms that the result supports the required business use cases and accepts documented business limitations or mitigations.
Technical owner	Confirms that target representations, URL behavior, integrations or target-side dependencies in scope, and technical risks are understood.
Domain owner, when needed	Approves specialist areas such as catalog, customer operations, finance, content, SEO, compliance, or fulfillment.

The same person may hold more than one role when governance permits, but each approval responsibility must still be addressed. Do not treat silence or an unavailable owner as approval.

Define the required validation areas

Include only areas that apply to the approved scope, but do not omit a material dependency because it is inconvenient to validate.

Validation area	Minimum sign-off evidence
Migration execution	Correct activity and environment, selected scope, Success, Failed, and Skipped review, and explainable totals.
Configuration behavior	Evidence that applicable options, mappings, Add-ons, and Customization produced the intended result.
Products and Categories	Representative catalog fields, structures, relationships, images, pricing, inventory, navigation, and usability where in scope.
Customers and Orders	Identity, addresses, groups, historical transactions, financial composition, statuses, and relationships where in scope.
Content, URLs, and redirects	Required content, internal links, priority URLs, and supported redirect behavior where in scope.
Accepted limitations	Documented platform differences, unsupported behavior, customer impact, owner, mitigation, and approval.
Open issues	Severity, classification, owner, due date, corrective path, and launch effect.

Operational checks such as checkout, payment, shipping, tax, notifications, live integrations, and final launch control belong to the launch-readiness decision. Include them here only when they are evidence needed to understand a migration-result limitation.

Define the sampling standard

Do not use a universal numerical sample size. Define a sample that covers the risk in the approved scope.

The sign-off record should show coverage across:

• business-critical and high-value records;
• simple and structurally complex records;
• records affected by options, mappings, Add-ons, or Customization;
• older and recent records, including source-window boundaries when relevant;
• known Demo issues, Failed or Skipped records, source-data problems, and expected platform differences;
• priority content and URLs;
• normal, boundary, and exception cases for each material rule.

Increase the sample when findings repeat, source quality is inconsistent, a transformation affects a broad population, or the initial evidence cannot establish whether an issue is isolated or systemic.

Sign-off depends on coverage, not a record count alone

A large sample of simple records can still be insufficient if it excludes the high-risk structures, transformations, or exceptions that determine whether the result is usable.

Set exact and transformed expectations

Define how each criterion will be compared before assigning a pass state.

Expectation type	Use when	Required sign-off evidence
Exact	Presence, preserved identifier when enabled and supported, required relationship, required content, selected mapping, redirect destination, or another inherently exact requirement	Source and target evidence match the approved value or relationship.
Approved transformed equivalent	The Target Platform represents the same business meaning through a different structure, label, field, URL pattern, content model, tax model, or image behavior	The expected target representation was defined before acceptance and supports the required use case.
Accepted limitation	A supported result cannot meet the original expectation, but the difference is understood and permitted	Impact, reason, owner, mitigation, due date when applicable, and explicit approval are recorded.

Do not reclassify an unexplained discrepancy as a transformed equivalent. The expected transformation must be supported by the platform model, configuration, or approved project requirement.

Apply the severity model

Severity	Definition	Sign-off effect
Blocker	Prevents required validation, critical data integrity, security, legal operation, critical navigation, or another mandatory acceptance condition.	Sign-off is Fail. Hold progression until resolved and revalidated.
High	Materially affects catalog, Customer, Order, content, SEO, integration, or operational use.	Resolve before sign-off unless an authorized owner formally accepts the limitation with strong controls and a safe launch path remains possible.
Medium	Has limited impact, a workable mitigation, and no critical business interruption.	Resolve when practical or approve as a controlled limitation with an owner and due date.
Low	Is cosmetic or low impact and does not prevent the approved use case.	Track according to project priority; it may be accepted when documented.

Severity describes impact, not the effort required to fix the issue. A simple fix can still be a Blocker when the affected behavior is mandatory.

Define the sign-off decision

Pass

Use Pass only when:

• the approved scope and result are clearly identified;
• every required validation area is complete;
• the sample covers the material risk dimensions;
• exact and transformed expectations are satisfied;
• Failed and Skipped results affecting scope are resolved or understood;
• no unresolved Blocker or High-severity discrepancy remains;
• required evidence and approvals are recorded.

Pass with accepted limitations

Use Pass with accepted limitations only when:

• each difference is known, explained, and permitted by the acceptance criteria;
• the customer and operational impact is understood;
• an authorized owner accepts the limitation;
• mitigation or follow-up work has an owner, due date, and closure evidence when needed;
• no unresolved Blocker remains;
• the limitation does not make the next stage materially unsafe.

A conditional approval is not permission to ignore the condition. Record what must be completed, who owns it, how closure will be verified, and whether the item must close before launch authorization.

Fail

Use Fail when:

• a blocker criterion fails;
• required records, relationships, values, or behaviors are missing or incorrect;
• an unexplained material discrepancy remains;
• Failed or Skipped results affect required scope;
• configuration behavior is wrong;
• the sample does not cover material risk;
• evidence is incomplete or contradictory;
• a required approver does not approve the result.

Build and approve the sign-off record

1. Identify the exact migration result

   Record the migration activity, path, service, target store, action, Run Mode, source-data window, and completion date.

2. Confirm the approved scope and configuration

   Record selected data types, exclusions, applicable Additional Options, Attribute Mapping, purchased Add-ons, approved Customization, and expected platform differences.

3. Confirm required validation coverage

   List each validation area that applies and link or attach the corresponding evidence. Mark an area incomplete when required evidence is missing.

4. Review the sampling record

   Confirm that the samples cover business importance, structural complexity, configuration impact, time range, and known exceptions. Expand the sample when the evidence does not establish the pattern.

5. Review each finding

   Record the expected result, actual result, failure classification, severity, owner, corrective action, due date, and current status.

6. Document accepted limitations

   State the reason, customer impact, mitigation, follow-up work, approval owner, and closure condition. Do not use a general statement such as “platform limitation” without describing the actual difference.

7. Select the decision

   Choose Pass, Pass with accepted limitations, or Fail using the defined conditions. Record the decision rationale without replacing the underlying evidence.

8. Obtain required approvals

   Record the migration-owner, business-owner, technical-owner, and applicable domain-owner decisions and dates. Resolve disagreement or record Fail; do not average conflicting decisions into approval.

9. Define the handoff

   Record which conditions must close before launch readiness, which accepted items move to a controlled stabilization backlog, and who owns the next review.

Use a reusable sign-off record

The record can be maintained in the customer’s approved project system, but it should contain at least the following sections.

Migration identification

• migration path and purchased service;
• migration activity and completion date;
• migration action and Run Mode;
• source-data window and Source Platform Options;
• target store;
• validation owner and review date.

Validation scope

• selected data types and exclusions;
• Additional Options;
• applicable Attribute Mapping groups;
• purchased Add-ons;
• approved Customization;
• known platform-model differences.

Sampling and result record

Area	Sample criteria	Records or URLs checked	Result	Evidence	Issue reference
Required validation area	Risk dimensions represented by the sample	Stable source and target identifiers	Pass, accepted limitation, or failed check	Report, log excerpt, redacted visual evidence, or comparison record	Project issue ID or reference

Issue record

Issue	Severity	Classification	Owner	Due date	Corrective action or acceptance	Status
Observable difference and affected scope	Blocker, High, Medium, or Low	Source, selection, option, mapping, Add-on, Customization, processing, platform, target setup, or evidence	Named owner	Required date	Safe corrective path or approved limitation	Open, resolved, accepted, or revalidation required

Accepted limitations

Limitation	Reason	Customer impact	Mitigation or follow-up	Approval owner	Closure condition
Defined difference	Supported explanation	Business, operational, content, search, or technical effect	Controlled action	Authorized name or role	Evidence required before closure or launch

Decision and approvals

• final decision: Pass, Pass with accepted limitations, or Fail;
• decision rationale;
• migration-owner approval and date;
• business-owner approval and date;
• technical-owner approval and date;
• domain-owner approval and date when required;
• conditions that must close before launch readiness;
• items assigned to a controlled stabilization backlog.

Handle sign-off problems

Problem	Required action
The evidence covers only simple or low-risk records	Expand the sample before deciding.
Source and target records cannot be matched reliably	Correct the identification method or obtain additional evidence; do not sign off an uncertain comparison.
An expected transformation was never defined	Establish the supported expectation and repeat the affected validation. Do not accept the difference retroactively without evidence.
A Blocker remains open	Record Fail, correct the cause, and revalidate before progression.
A High-severity issue is proposed for acceptance	Require documented impact, controls, authorized approval, closure or monitoring conditions, and separate launch-readiness review.
Owners disagree on the decision	Hold approval until the conflict is resolved or record Fail.
An accepted limitation has no owner or closure condition	The limitation is not controlled; assign ownership and completion evidence before conditional approval.
The issue requires Next-Cart review	Preserve the migration activity, affected identifiers, expected and actual results, configuration, and privacy-safe evidence, then use My Tickets.

Migration sign-off is not launch authorization

A result can pass migration validation while checkout, payments, shipping, taxes, notifications, analytics, integrations, security cleanup, or operational ownership still require work. Complete the launch-readiness review before making the target store available to customers.

Sign-off output

The completed output must identify:

• the exact migration result and approved scope;
• required validation areas and sample coverage;
• exact and transformed expectations;
• resolved, open, and accepted findings;
• severity, classification, owner, due date, and closure evidence for each issue;
• accepted limitations and their customer impact;
• final Pass, Pass with accepted limitations, or Fail decision;
• required approvals and dates;
• conditions that must close before launch readiness;
• the owner and date for the next review.

Next step

After Pass or Pass with accepted limitations, continue with the Launch Readiness Checklist. Carry every unresolved condition and accepted limitation into that review.

After Fail, correct the classified cause and repeat only the affected validation. Do not authorize launch-readiness progression until the sign-off decision is updated with complete evidence and required approvals.