Migration assurance
Sample migration report
A report combines a scoped readiness status with severity counts, detected migration inventory, evidence and validation steps. The example below describes the report structure without requiring JavaScript.
- Example status: BLOCKED
- Example module: Orders API v0 to v2026-01-01
- Evidence type: SOURCE_LINE
- Result scope: Static analysis of submitted, supported files
Executive summary
This public sample represents the shape of an unlocked migration report. It shows readiness, severity counts, detected inventory, module deadline context and the assurance workflow that follows the initial static scan.
| Field | Example value | Meaning |
|---|---|---|
| Readiness | BLOCKED | At least one blocker must be resolved before cutover. |
| Primary module | Orders API v0 to v2026-01-01 | The sample is scoped to an Orders migration fixture. |
| Evidence model | SOURCE_LINE, SAMPLE_DATA, WORKFLOW_ANSWER | Every finding states where the evidence came from. |
| Scope | Supported submitted files only | Unsupported files remain unverified, not silently passed. |
Report screenshot preview
The visual report card summarizes readiness, blocker count, affected module, ruleset version and next migration task before showing the detailed finding table.
| Visual area | Sample value |
|---|---|
| Readiness badge | BLOCKED |
| Primary blocker | Deprecated Orders API v0 operation |
| Next task | Replace deprecated calls, then re-scan from a fresh upload |
| Evidence package | HTML, JSON, SARIF and ZIP artifacts without raw source |
Downloadable sample artifacts
Download the sample HTML report or a sample evidence ZIP. The ZIP contains report metadata, quality-gate context and checklist files only; it does not contain source.
Download sample HTML artifact Download sample HTML checksum Download sample evidence ZIP Download sample evidence ZIP checksum
Interactive finding card
The app version renders the same sample through the live report component so users can expand findings, review evidence, inspect the action plan and see the upgrade outcome before uploading their own code.
Finding example
A finding combines severity, rule ID, source location, business impact, required change, validation steps and the official reference where available.
| Severity | Rule | Evidence | Required change |
|---|---|---|---|
| BLOCKER | AMZ-ORD-OPERATION-001 | src/orders.ts:42 — getOrderBuyerInfo(orderId) | Use getOrder with includedData=BUYER and compare same-order payloads. |
Scope summary
Reports show how much of the submitted package was actually analyzed. Partial scans are called out so a clean result never implies coverage of unsupported, generated or excluded files.
| Scope item | Example | Why it is shown |
|---|---|---|
| Files submitted | 1 | The public sample fixture submits one supported source file. |
| Files scanned | 1 | The same source file is scanned through the normal engine. |
| Skipped / unsupported | 0 | This sample has no skipped files; real scans show skipped scope when present. |
| Ruleset | amazon-orders-1.0.0-r1 | The report is tied to the active Orders ruleset version. |
Action plan
Unlocked reports group findings into prioritized migration tasks. The plan is dependency-aware: foundation tasks such as replacing deprecated calls appear before follow-up tasks such as enum, includedData or validator work.
| Priority | Task | Validation |
|---|---|---|
| CRITICAL | Replace deprecated Orders API v0 calls | Re-scan and confirm AMZ-ORD-OPERATION-001 is fixed. |
| HIGH | Compare migrated Orders payloads | Run Orders Payload Parity Validator on same-order samples. |
| MEDIUM | Review unsupported wrapper code | Assign manual verification for dynamic call construction. |
Quality gate
The quality gate turns findings and coverage into a single deterministic readiness state. A user can accept risk for warnings, but cannot turn active blockers into a ready state.
| Gate | Example state | Reason |
|---|---|---|
| Migration quality gate | BLOCKED | A deprecated Orders operation remains active. |
| Warnings | None | This sample fixture scans 1 of 1 submitted files and has no skipped scope. |
| Next state | AT_RISK or READY_WITHIN_TESTED_SCOPE | Only after blockers are resolved and re-scanned. |
Alternative partial scan example
A partial scan is shown as a separate coverage warning only when submitted files are skipped or a required rule group does not complete. It is not mixed into this 1/1/0 sample gate result.
| Condition | How it would appear | Reason |
|---|---|---|
| Files submitted 5, scanned 4, skipped 1 | Warning: Partial scan | One submitted file was outside supported scope. |
| Required rule groups 3, completed 2 | Blocked or warning depending on scope | Coverage was incomplete and must be reviewed. |
Re-scan comparison
After code changes, upload the source again and compare the new report to the baseline. Stable finding fingerprints classify the migration delta.
| Diff state | Example | Use |
|---|---|---|
| Fixed | AMZ-ORD-OPERATION-001 removed | Confirms a migration task was resolved. |
| Remaining | Dynamic wrapper still unresolved | Keeps unresolved work visible. |
| New / regressed | A legacy call reappears in another file | Prevents accidental reintroduction before rollout. |
Validator result
The sample report links static findings to module-specific data validation. Validators apply only to the supplied samples, and their result is scoped accordingly.
| Validator | Example result | Interpretation |
|---|---|---|
| Orders Payload Parity | FAILED | Same-order payload comparison found missing buyer data. |
| Settlement Sample Validator | NOT_VERIFIED | No Flat File V2 settlement sample was supplied for this Orders sample. |
| Finances Reconciliation | NOT_VERIFIED | No listTransactions sample was supplied for this Orders sample. |
Export list
Unlocked reports can be exported for engineering, QA, security review and project records.
- HTML report for human review.
- CSV finding list for spreadsheets.
- JSON report for automation.
- SARIF for code-scanning tools.
- Evidence package ZIP containing findings, action plan, quality gate and cutover checklist.
Limitations
The sample is intentionally explicit about what the scanner can and cannot prove. Static analysis cannot observe production traffic, runtime feature flags, generated code after upload or payloads that were not supplied.
- A clean scan means ready within tested scope, not a certification.
- Dynamic wrappers and generated clients can require manual verification.
- Validators prove only the submitted samples and manifests.
- Re-scans require a fresh source upload because source code is not retained.
- Ruleset updates never mutate an old purchased report; a new re-scan snapshots the then-current ruleset and the comparison marks rulesetChanged=true when versions differ.
Frequently asked questions
Is this a certification?
No. It is deterministic migration evidence within tested scope, not a guarantee of production behavior.
Official sources
Use this sample as the purchase preview
Run a free scan first, then unlock the outcome package when the preview shows covered findings.
Last reviewed: 2026-07-02.
Open the interactive scanner: /app#/sample-report