This review companion keeps the synthetic M01, M02 and M03 records distinct and compares last sync against a declared routing start and review snapshot. The initial 09:50 sync precedes the 10:00 routing start. A 10:10 comparison passes the time-order check while recorded acceptance remains zero of three. It performs no tenant operation.

Confirm the method before adopting its gates
Microsoft documents multiple migration paths and notes that actual migration performance varies. Record the applicable method and current guidance rather than assuming one cutover checklist governs every environment. Microsoft: Migration Performance and Best Practices
The example below illustrates a cutover review only after an administrator confirms that method's applicability. In the actual-use section, keep source/target environment, method, relevant versions, scope, authority, and rollback/retention decisions blank until supplied. The example's label does not select a technical path for your organization.
Microsoft's cutover article separately discusses sync status, routing verification, licensing, and a last-sync time after direct routing begins. Use that separation for this evidence exercise; consult current method-specific documentation before any authorized operational work. Microsoft: Exchange Cutover Migration
Do not turn historical client versions, example mailbox limits, or a published waiting interval into universal rules. The workbook should reference the administrator's verified path and requirements rather than reproduce steps whose applicability has not been established.
Reconcile all three mailbox records
Use this original synthetic roster at its declared review snapshot:
| Mailbox ID | Supplied sync-report state | Exception or gap | Recorded acceptance |
|---|---|---|---|
| M01 | Synced | License/access, routing and acceptance evidence absent | Not recorded |
| M02 | Failed | Exception X02 needs review | Not recorded |
| M03 | Unknown | Current report/source missing | Not recorded |
There is one reported Synced mailbox among three roster entries. There are zero recorded acceptances. That means the workbook lacks acceptance evidence for every entry; it does not prove that three users failed a test or that M03 had a failed migration.
Keep failed and unknown distinct. X02 identifies an exception to inspect, not a cause we have diagnosed. For M03, ask for the missing source/report and its timestamp instead of inventing a success or failure. Leave the actual owner, diagnosis, remedy, and result blank until provided.
Use stable mailbox IDs and an agreed roster denominator. An exact duplicate M01 report does not create a fourth mailbox. Conflicting current reports for one ID need reconciliation; do not select whichever state makes the completion summary look better.
Inspect the post-routing time order
Use a fictional review snapshot of October 14, 2026, at 10:15 UTC. This model clock is not a live tenant observation or the current time.
| Synthetic evidence | Timestamp |
|---|---|
| T01: routing began/was observed in the example | 2026-10-14T10:00:00Z |
| T02: supplied last-sync time, initial case | 2026-10-14T09:50:00Z |
| T02: replacement time in comparison case | 2026-10-14T10:10:00Z |
The initial T02 precedes T01 by ten minutes. It cannot support a sync after direct routing began, so that finalization condition remains held in this cutover exercise.
The replacement T02 is ten minutes after T01 and five minutes before the declared review snapshot. It meets the time-order comparison only. It does not resolve M02's failure, supply M03's report, verify all mail routes, establish licenses/access, or accept every mailbox.
Retain the initial timestamp and the revision history. Record what the timestamps actually represent and their evidence scope. A routing observation with no established start-time meaning needs clarification before it can be used as T01 for this gate.
Hold malformed, missing, or future evidence
Require a parseable timestamp with a clear timezone and source meaning before comparison. A missing value is unknown, not midnight. A malformed value needs correction, not a favorable sort order.
For this fictional 10:15 UTC snapshot, a purported observed sync at 10:20 UTC lies in the future. Flag it for review as unsuitable observed evidence at that snapshot. A scheduled future sync is a plan, not a completed event. Keep its state separate rather than claiming the timing gate has passed.
The checklist should expose each held condition, responsible owner when assigned, follow-up question, source revision, and actual reviewer decision. Passing one condition cannot automatically finalize the overall migration.
Inspect the companion
Select M02 to read its separate X02 exception, then M03 to see a missing report rather than an invented failure. Enter a full timestamp with timezone and press Compare time. A blank, malformed or future observed time cannot pass. The supplied 10:10 scenario changes only that comparison; it fills no license, routing or user-acceptance field.
Keep operational decisions in the approved IT workflow. The HTML is a reading companion to the method-specific workbook, not the workbook itself or an administrative tool. Retain actual source references, scope and reviewer decisions in the authorized record.
Copy this prompt
Create an explanatory review page for a fictional, administrator-confirmed cutover migration case. Do not perform a migration or provide tenant commands. Keep an agreed roster of three unique mailbox IDs: M01 Synced with license/access, routing and acceptance evidence absent; M02 Failed with exception X02 requiring review; M03 Unknown because the current report is missing. Show one reported Synced out of three and zero recorded acceptances. Buttons select each mailbox and reveal its separate evidence gaps without changing the summary.
Provide a timestamp comparison with fixed routing start 2026-10-14T10:00:00Z and fixed review snapshot 2026-10-14T10:15:00Z. Initial last sync is 2026-10-14T09:50:00Z, which is held because it precedes routing. A supplied 10:10Z scenario passes only the post-routing time-order condition. Blank, malformed, timezone-free and future 10:20Z values must be held for review. Preserve the initial time as clearly labeled history.
Use a labeled text input and Compare time, supplied-scenario and Reset buttons. Changing input clears stale comparison output. Do not infer acceptance, access, routing verification or complete migration from this gate. Actual tenant/method/version/authority/rollback fields remain in the maintained authorized workbook, not fabricated here.
Return one complete self-contained HTML file with embedded CSS and JavaScript. Use native labeled controls with type="button" actions, readable text of at least 16px, strong contrast and visible focus. Make the layout responsive at 360px without horizontal scrolling. Keep supplied text literal. Use no remote dependencies or storage, and describe only actions the page actually performs.
Put the exception questions before finalization
Keep tenant evidence, the agreed roster, rollback decisions and acceptance criteria in the authorized migration workbook. Bring M02’s exception and M03’s missing report to the responsible reviewer with their actual source references. For an administrator’s explanation of this fictional review, NOS can render the sanitized HTML roster and time comparison. Use the 10:10 scenario to explain why a passed time comparison still leaves other conditions unresolved.