Migration and cutover¶
Trigger¶
A project must move data/services from a current state to a target state through a controlled production cutover.
Intended outcome¶
Migration completes with reconciled data, controlled rollback boundaries, operational acceptance and owned residual defects.
Workflow steps and gates¶
| Step | Accountable role | Activity | Handover | Gate |
|---|---|---|---|---|
| 1 | Data Architect | defines source/target models, authoritative ownership and data constraints | migration data model and ownership boundaries | Every migrated domain has an accountable data owner and target definition |
| 2 | Data Migration and Cutover Lead | builds migration strategy, reconciliation rules and integrated cutover sequence | migration plan, cutover runbook and rollback plan | Every object has mapping, acceptance and rollback/restore semantics |
| 3 | Data Engineer | implements and rehearses migration pipelines against production-like volume | migration execution evidence and exceptions | Rehearsal proves throughput, error handling and repeatability |
| 4 | Test Manager | independently assesses migration, reconciliation and business acceptance evidence | test and residual-risk report | Exit criteria were defined before execution and are met or explicitly waived |
| 5 | Service Transition and Operational Readiness Manager | confirms monitoring, support, recovery and receiving-team readiness | operational cutover constraints and acceptance evidence | No critical operational readiness gap is unowned |
| 6 | Release Engineer | integrates deployment artefacts with the cutover critical path | release manifest and deployment/rollback evidence | Exact artefact versions and rollback steps are known |
| 7 | Change Manager | authorises the production window and stop/go governance | production change authorisation | Rehearsal, reconciliation and operational evidence are available to the decision |
| 8 | IT Service Owner | accepts the migrated service after stability and reconciliation checks | service acceptance and residual issues | Service, data and ownership acceptance are explicit before legacy retirement |
Running this workflow: operator and implementer boundary¶
In Claude Code or Codex CLI, use the prompt in the next section (or adapt it to your programme): it is a provider conversation request, not a shell program named after this workflow. You supply the source materials, actual owners, gate acceptance and any authorisation for changing real systems. The provider agent interprets the registered workflow stages and role contracts, calls supported tools if allowed, and returns explicit evidence and blockers. Stage completion in the diagram or metadata is not proof of a successful external tool call, an approved exception or a released system.
For consequential decisions explicitly start /layered (Claude) or $workflow-layered (Codex); this version does not force every direct/natural-language workflow invocation into Fabric. Human L0 authority remains separate, with Codex requiring the actual human to run any protected authority command in a trusted terminal. See the interaction model, layered engagement and human authority.
How to use this workflow¶
A practical prompt pattern is:
Apply the
migration-and-cutoverworkflow to this situation. For each step, identify the current state, accountable role, required evidence, hand-over artefact, gate status and unresolved blocker. Do not skip a gate merely because the implementation is technically complete.
Operational interpretation¶
The workflow is most useful when the team keeps each hand-over explicit. The system can help generate or review the artefacts, but the accountable role and approval decision remain organisational responsibilities.