About this article: AI-assisted writing, reviewed against the cited sources. This is source research, not lab validation. Check the stated versions and your own requirements before making changes.
A migration decision record explains who authorised the next stage, which evidence they relied on and when that evidence stops being valid. Keep it alongside the technical runbook so the sponsor, application owner and incoming support team can reconstruct the decision without reading a night of chat messages.
The existing cutover runbook already covers consistency checks, gate owners, deadlines and stage-dependent recovery. This article adds the board and handover record: approval scope, exception limits, evidence expiry and the transfer of decision authority.
Why it matters
A successful check at 18:00 can be invalidated by a later configuration change or an unexpected writer. A sponsor can accept a limited service inconvenience without authorising loss of new transactions. Unless those boundaries are recorded, a verbal “go” may be interpreted more broadly than intended.
The record is useful after a smooth migration too. It identifies outstanding obligations, who owns them and why the business accepted temporary restrictions.
How it works
Prepare the decision record before the window
Use one controlled record with a named editor. Link to technical evidence instead of copying commands or changing pass values during the meeting.
| Field | What to record |
|---|---|
| Decision identity | Change ID, application, exact stage and version of the approved plan |
| Authority | Commander, sponsor, technical owners and named deputies with contact routes |
| Evidence | Result, measurement time, owner and reference to the saved runbook output |
| Validity | Maximum evidence age and events that require rechecking |
| Writer state | Where the newest committed records live and which systems may write |
| Decision | Go, defer, or stop progression; time, approver and reasons |
| Exceptions | Specific accepted limitation, compensating control, owner and expiry |
| Next review | Stage boundary or deadline when the decision must be reconsidered |
Treat validity periods as locally agreed controls, not universal numbers. A new deployment, resumed partner feed, failed consistency check or unexpected write can invalidate evidence immediately even if it is only minutes old.
Distinguish a limited exception from a failed mandatory gate
Agree non-waivable integrity and security conditions before the window. A missing consistency proof or uncontrolled production writer is a reason to stop progression; a sponsor's willingness to accept inconvenience does not supply that proof.
A potentially waivable item must be identified in advance, with the required risk authority. For example, the business might accept a delayed non-critical report if the workaround is tested, its owner is available and an expiry is recorded. This example does not make integrity, security or legal obligations waivable.
Record the exact scope of each exception, its effect on other checks and any required re-test. Repeated small exceptions can change the combined risk, so the commander must assess the total rather than treating each as independent permission.
Record a decision at each authority boundary
Go authorises only the named next stage while its evidence remains valid. It does not authorise later deletion of the old environment or automatically cover a changed design.
Defer leaves the source in its known authoritative state when the switch has not started. Record a new decision time and ownership of any queues or paused work before ending the bridge.
Stop progression pauses further change and invokes the rehearsed recovery decision. Determine the actual writer state, preserve evidence and use the authorised controls to prevent competing writes. Once the target has accepted new transactions, returning to an older source can lose them. Choose the tested reconciliation/failback path or forward recovery with the appropriate technical and business authority. A stop call is not an instruction to restart an old VM automatically.
NIST SP 800-84 gives a test director and team members immediate termination authority when safety or organisational/data security is at stake. Applying that principle to named migration participants is an editorial policy recommendation. Define the stop signal and escalation route in advance; nobody should have to find a new approver to report an uncontrolled writer or security breach.
Make shift handover an explicit acceptance
The incoming commander or service owner records acceptance of the current stage, writer state, unresolved exceptions, recovery options and next deadline. If a deputy cannot be reached, follow the pre-agreed defer or escalation rule. A silent departure from the bridge does not transfer authority.
Keep the technical outputs and decision record together, with access appropriate to any sensitive operational information. If evidence is corrected later, retain the original decision and add a dated correction so the history remains understandable.
What to choose and why
Use this record when several teams or shifts share a migration decision. Keep a simple migration record short, but still include authority, evidence references, writer state and the next review point. The sponsor accepts business risk; the technical owners establish whether the evidence meets the approved conditions.
Agree migration responsibilities with the provider before the window. How migration is delivered gives service context; contractual response times must come from the actual agreement.
Risks and limits
A completed form does not establish data consistency or service recovery. Those require the mechanism-specific checks and rehearsals in the technical plan. A decision record also cannot make an unsafe rollback safe. Recovery after target writes, lost cluster authority or unknown data divergence needs the relevant specialist procedure.
This is an editorial governance template. Its examples are not legal advice, a provider SLA or lab-validated migration instructions.
Sources
Developed with AI assistance. Source research only; no migration, recovery or infrastructure procedure was executed or lab validated.
Source research accessed 14 November 2026. These documents support the stated principles and tool-specific conditions; the planning templates are editorial recommendations.
- NIST SP 800-84, September 2006.
- NIST SP 800-34 Rev. 1, May 2010, section 4.4.
- NetLeverage: cutover runbook and stage-dependent recovery.
Related future topics
- Acceptance criteria before decommissioning the old system.
- Staff communications during cutover.
- Hypercare exit and support handover.
Learning notes
- A go decision authorises a named stage, while its evidence remains valid.
- Record what invalidates evidence as well as when it was measured.
- Predefine which conditions cannot be waived and who accepts limited exceptions.
- Stop progression before choosing a recovery path based on the newest writes.
- Transfer decision authority explicitly between shifts.
This article was originally published on .