Skip to content
Back to Site

Validation Evidence

Make validation reproducible by linking each sample to an expected result, finding, severity, evidence, corrective action, retest, and downstream decision.

The Validation sheet keeps the validation plan and the resulting evidence in the same record. Each Validation ID should make it possible to reconstruct what was checked, why the sample was chosen, what result was expected, what actually happened, and what decision or corrective action followed.

Use the Documentation for the validation procedure. Use the Toolkit to preserve the project-specific sample, finding, owner, evidence, and decision trail.

Field groupFieldsHow to use them
IdentityValidation ID, Activity, Data Area, Related IDsIdentify the check and connect it to the migration activity, task, risk, redirect, or decision it supports.
Test designValidation Objective, Sample / Selection Basis, Record / ReferenceExplain what the check proves, why the record was selected, and which source or target record is being examined.
Pass conditionExpected Result / Pass ConditionState an observable result that can be evaluated without guessing.
Responsibility and timingValidator, Planned DateAssign the check before the validation window begins.
FindingActual Result / Finding, ResultRecord what happened and choose the appropriate result state.
TriageSeverity, Issue Classification, Blocking?Describe the business significance and the most useful correction path.
RecoveryCorrective Action / Owner, Retest Required?, Retest ResultMake failure handling accountable and traceable.
Evidence and decisionEvidence Link, Decision ID, Follow-up Status, NotesPreserve the supporting evidence and connect accepted limitations or approval decisions.

Choose the validation activity and data area precisely

Section titled “Choose the validation activity and data area precisely”

The Activity list supports Demo Migration, Full Migration, Continue the Migration with the Last Used Configuration, Continue the Migration with a New Configuration, Perform a New Migration, Launch readiness, and Post-launch monitoring.

Data areas include the supported migration categories plus Images and media, URLs and redirects, Checkout, Storefront navigation, and Target configuration. Choose the area that best describes the evidence you are evaluating. Do not use a generic area when a more specific one will make later review easier.

Result records the test outcome:

  • Pass;
  • Pass with accepted limitations;
  • Fail;
  • Not applicable;
  • Not tested.

Severity records the consequence of a finding: Informational, Minor, Moderate, High, or Critical.

A Fail does not become acceptable because its severity is low, and a Pass with accepted limitations is not complete until the limitation is documented and authorized where required.

The workbook calculates Follow-up Status from the validation result and the evidence recorded in the row.

Validation stateFollow-up Status behavior
Not testedPending
Fail without a corrective action/owner or evidence linkIncomplete follow-up
Fail with corrective action/owner and evidenceReady for retest
Pass with accepted limitations without both evidence and a Decision IDIncomplete follow-up
Pass with accepted limitations with evidence and a Decision IDDecision linked
Pass or Not applicableComplete

This status is a completeness check for the record. It does not decide whether a failed result is acceptable or whether the target store can launch.

Record evidence without expanding the workbook into a data dump

Section titled “Record evidence without expanding the workbook into a data dump”

A useful Evidence Link points to a secure location containing the material needed to reproduce or review the finding. Keep the Validation row focused on the identifier, expected result, observed result, decision significance, and corrective path.

  1. Record the actual finding and choose Fail.
  2. Classify severity and issue type. Use the relevant Documentation troubleshooting or validation guidance to identify the safest corrective path.
  3. Assign the corrective action and owner. State what must change before retest.
  4. Mark whether retest is required. Do not change the original finding to hide the first failure.
  5. Add the evidence link. Preserve enough evidence for review or support escalation.
  6. Retest the affected condition. Record the retest result and connect any required acceptance decision.

Connect validation to the relevant procedure

Section titled “Connect validation to the relevant procedure”

Use the appropriate Documentation page to determine the sample, checks, and pass conditions. Common starting points include:

When a validation result affects URL continuity, maintain the URL-level evidence in Redirects. When a result requires authorization or an accepted limitation, record the decision in Decisions and sign-off.