Introduction
A migration proof sheet tests a cutover better than a green done message. A copy job can end while a date shifts, a link breaks, or the wrong person gets access. A matching count helps, but it answers one question. Before go-live, record what was checked, what is wrong, who accepts risk, and when to repair or roll back.
Why a completed migration is not yet a decision
Most plans include tests, checks, cutover roles, and rollback. That is sound. Microsoft says to name the people who decide at cutover and test.[1] Its Synapse-to-Fabric guide calls for row counts, access checks, and full task tests.[2] AWS DMS lists source-target checks, costs, and limits.[3] AWS cutover guidance calls for final source controls, link checks, and rollback triggers with an owner.[4]
The mistake is to treat these checks as one comfort score. They are not equal. A matching total can hide wrong records. A clean sample can miss an edge case. Good data can sit behind the wrong access. A usable target can still rely on an old link.
Our view is simple: a migration should pass when separate proof covers the planned use. One green metric is not enough. This is the gap between a done copy and a fit decision. A tool can say its work ended. A migration proof sheet shows if the target is fit for a named use at a named decision point.
The six proof layers of a migration proof sheet
The migration proof sheet puts nine fields into six proof layers. Each asks its own question. Together, they stop one strong result from hiding a serious fault.
1. Boundary and change control
First, set the scope boundary and source state. Name the objects, time window, exclusions, and target use. Then record the last write or freeze point. If a freeze will not work, state the change window. Without this, a later claim about missing data has no firm reference point.
2. Population
Next, check expected and actual population counts. Counts give broad proof of completeness. They do not show that records keep the same meaning. Each big gap needs a clear reason. “Under review” is not one.
3. Meaning and dependencies
Use risk-based samples to test meaning. Include odd dates, formats, links, attachments, record links, and known edge cases. This layer tests what counts cannot see. A sample is useful, but it is still a sample. Do not call it full proof of the whole population.
4. Exceptions and materiality
Keep an exception register for missing, changed, skipped, duplicate, or failed items. Give each an impact class, owner, outcome, and sign-off rule. This stops the happy path from hiding what matters most.
5. Access and useful work
Check access apart from data quality. Named roles should see and change only what the target design allows. Then ask a test user to finish a useful full task. A correct record is not enough if people cannot find, edit, approve, or use it in real work.
6. Recovery and accountability
Last, set the repair or rollback trigger and name the decision owner. State the clear condition, the last safe time, and what happens to changes made after cutover. This keeps a safe choice open.
The nine fields to place on the sheet
The model is small on purpose. It does not replace product work, expert review, or a team’s cutover plan. It gives those tasks one clear decision record.
Use the table as a working sheet, not paperwork after the fact. A simple decision log for digital teams can hold the final state, conditions, expiry, and next proof event. Detail may sit elsewhere. Yet the record should point to it.
Evidence stamps keep proof from going stale
Each proof item needs an evidence stamp. Record capture time, source and target boundary, method, seen result, reviewer, last change, due date or retest point, and layer owner. A change can be a new source map, role change, link change, or data update.
Freshness matters. Evidence taken before the last change is stale. For example, an access check from yesterday does not show access after today’s role update. The migration proof sheet should show that before the go or no-go talk.
Sort exceptions before the cutover window
A low exception may be okay only with an owner, repair date, no blocked task, no excess access, and no effect on required totals or record links. Low does not mean ignored.
A material exception needs repair and retest unless named business and technical authorities accept a written condition. It should say what is limited, why it is okay now, and when it ends.
A critical exception means the target is not ready for the named use. Missing data, wrong access, a failed core task, or an unsafe recovery path are common cases. Do not let good checks average away a critical failure.
Use four authority-bound decisions
A migration proof sheet has four outcomes: PROCEED, PROCEED_WITH_CONDITIONS, REPAIR_AND_RETEST, and ROLLBACK. Use a strict order. ROLLBACK outranks REPAIR_AND_RETEST. It outranks PROCEED_WITH_CONDITIONS, which outranks PROCEED.
PROCEED needs business, technical, and data owners to sign the layers they tested. There can be no material or critical exception. If access, privacy, or legal rules are in scope, the right security, privacy, or legal reviewer must sign that boundary too. The cutover lead records the final state. That role cannot erase a missing sign-off.
PROCEED_WITH_CONDITIONS is tighter. It allows only low, time-bound exceptions accepted by named business and technical authorities. REPAIR_AND_RETEST follows when an owner withholds sign-off or proof is not complete. Only the named rollback authority, or a pre-named delegate, can call ROLLBACK. A critical trigger should not wait for rushed consensus.
A fictional community-club directory case
Consider a fictional community club moving its public event directory between two web tools. The team expects 1,240 event entries. The target also reports 1,240. On counts alone, the move looks complete.
However, a risk-based sample finds repeat dates shifted for two patterns. The exception register also lists 18 image links to the old service. The population layer passed. The meaning and dependency checks did not. The right decision is REPAIR_AND_RETEST, not PROCEED.
After the date map and links are fixed, a different reviewer repeats the edge-case checks. They also complete the create-edit-publish task. This is fictional, not a claim about a real club, client, system, or deployment. Its point is simple: counts and working meaning are different proof.
What We Recommend
Before the cutover window, name the business task that must work. Name the exception owner for each open item. Set the evidence-expiry rule and the rollback or repair trigger. Then use the migration proof sheet at each decision point. It helps when several teams own parts of the move.
Match the depth to the risk. Data checks can take time and add system load.[3] Risk-based sampling can suit a lower-impact move, but state its limits. A tool’s check feature can add useful evidence within its scope. Its data-type limits still matter.[3] Rollback may be unsafe after new writes start. Then set the last safe choice point and a plan for post-cutover changes. The same habit that helps teams make software updates safer without costly delays can prevent a late decision with no clear owner.
Key Takeaways
- A completed copy shows activity, not that the target is fit for use.
- Six proof layers map nine fields into one decision record.
- Evidence stamps show who checked what, how, when it ends, and if a later change made it stale.
- Low exceptions can be time-bound and owned. Material and critical exceptions need stronger action.
- Critical evidence has conservative precedence. It cannot be offset by a set of green checks.
Conclusion
A migration proof sheet does not promise a flawless move. It gives a team a more honest basis for a decision. The aim is not more ceremony. It gives clear proof of risk, a clear limit on the unknown, and a safe step when evidence changes. It helps small teams put time and effort into what matters, much like cloud cost control for small teams: make the trade-off clear before costs arrive.
Frequently Asked Questions
Is a matching row count enough to approve a migration?
No. It helps test that all records came across. It does not show record meaning, record links, access rights, other system links, or full work.
When should a team use a full check instead of sampling?
Use a full check when the cost of error is high. Use it when the system, data, rules, or change pattern calls for it. Sampling can work for lower-impact areas, but record its limits.
Can a migration tool’s check feature replace the proof sheet?
No. A tool check can be strong proof within its scope. It does not by itself show business use, access, links to other systems, how exceptions are handled, or a safe recovery choice.
Does every exception force a rollback?
No. Low, owned, time-bound exceptions may support PROCEED_WITH_CONDITIONS. Material issues usually need repair and retest. Critical issues require REPAIR_AND_RETEST or ROLLBACK under the agreed authority model.
Sources
- Microsoft Learn: Cutover process
- Microsoft Learn: Synapse-to-Fabric validation and cutover
- AWS DMS: Data validation
- AWS: Cutover stage
