Cloud migration rehearsal and cutover runbook

A migration plan starts with the business process and its write paths. In a B2B document-approval workspace, the document API, version database, approval history, attachments and task permissions work together. If the version a person reads differs from the approved version, an identical document title conceals a different business outcome. Identify which approval event a notification webhook delivers before deciding which components move together.

For each migration group, record the target version, source and destination authority, write owners before and after cutover, and the person who checks the result. “Copy the database” leaves a gap: changes and callbacks arriving after the copy still need a destination. Final synchronization is a separate task. When the source stops accepting writes, determine how inbound events are retained, replayed or reconciled.

The worked example is a fictional team workspace. An author submits a document and a designated approver reviews its version before approving it. The example policy denies self-approval by the author. Document and approval records are authoritative in the source database before cutover and in the destination afterward. Only one environment owns notification-webhook delivery. Times, counts and results illustrate completed documentation; production execution remains not performed. Use the cloud operations handover checklist for subsequent access and operating responsibilities.

A rehearsal needs a defined test dataset, controlled external effects, a starting state and expected results. Copy speed in a test environment does not establish production duration. Record differences in document versions, approval changes, attachment volume, network conditions and permissions. When notification webhooks go to a test receiver, delivery to the actual production receiver remains a separate verification item.

The fictional rehearsal record runs final synchronization from 21:02 to 21:08 and compares 40 documents with final approval event AP-040. By 21:10 it checks twelve attachment hashes and role-based access. By 21:12 it verifies that the designated approver sees version v3 of test document DOC-T01 and can approve it, while the author's approval attempt is denied. At 21:13 the source webhook worker is stopped and the destination worker is ready. The eleven-minute total belongs to the fictional record; actual duration fields require the executing team's measurements.

Use not performed, passed, failed and blocked as distinct result states. An expected result is not proof of a pass. Retain execution times, evidence locations, the data range examined, reviewers and open issues. A repeat rehearsal should link to the previous attempt and identify what changed. For checks possible only in production, specify the stage, scope and approval needed before they are performed.

Cutover transfers real requests and authoritative writes to the destination. After readiness checks, control writes from users, jobs and callbacks, then synchronize and compare the final changes. Change traffic through the approved route, verify critical business behavior and enable destination writes. The detailed order depends on the system's data model and migration approach. Task owners and reviewers need access to the same result locations.

In the fictional hold decision, version v3 of DOC-018 is approved in the source but still awaiting approval in the destination. Approval event AP-041 is missing there; only AP-040 has arrived. Forty matching document records and twelve matching attachment hashes do not make approval-state comparison pass. Keep destination business writes closed while approval history is resynchronized. Recheck the version and approval state as well as allowed approver access and denied author self-approval before deciding again.

AWS pre-cutover guidance describes planning task order, ownership, timing, tests and rollback in advance. Apply those principles to the evidence available for the actual service. The worksheet is an original planning aid, not a vendor command sequence. Define the approved environment and completion conditions before carrying out the work.

Returning before destination business writes begin differs from returning afterward. New document versions, approval records and delivered webhooks do not follow traffic automatically when a route is changed back. Identify the approved version, approver permissions and feasibility of reverse synchronization. If a notification was delivered, determine how the receiver prevents duplicate effects when that approval event is delivered again. Unknown data and external state are reasons to investigate, not conditions for blind automatic rollback.

The deadline example uses a change window ending at 21:30. Reserving eight minutes for return procedures and five minutes for business verification gives a final decision time of 21:17. If mandatory verification is incomplete then, do not approve continuing the original plan. Evaluate remaining time, source readiness and destination writes against the agreed recovery or contingency procedure. The arithmetic does not prove that data can be returned safely.

AWS cutover and rollback guidance distinguishes rollback after new data has arrived. IXC's rollback-ready deployment article examines compatibility across code, configuration, data and external contracts. Each decision record needs the time, observed values, selected action, executor, approver and any follow-up reconciliation.

An available home page is the start of verification. Match document versions to approval states, and verify that only permitted roles can open attachments or approve a document. Compare the notification's event identifier, document and version as well. Deduplicating a repeated event in a test receiver and confirming delivery to a production receiver are separate checks. Do not mark the workflow complete before the required business verification finishes.

The fictional closing record covers document v3, approval history, attachment permissions and one designated webhook worker operating. It retains the test receiver's duplicate-handling result and assigns an owner and next check for the production receiver. The business approver assesses the open item's impact and temporary handling. This does not authorize automatic resumption with unresolved risks: incorrect approval states or access controls affecting critical work require a hold.

Retiring the source requires separate decisions about data and log retention, the period during which recovery might need it, unresolved reconciliation and contract termination. Starting the destination does not authorize deleting source resources. Record retained assets, cost ownership, permissions to revoke and accounts or workers to close. This also defines the split between internal teams and managed cloud operations.

To compare migration proposals, align discovery, design, synchronization, rehearsal, cutover, validation and stabilization. System counts and a target date are insufficient. Business owners supply allowable disruption and expected outcomes; technical owners supply dependencies and data access constraints. Ask the delivery team what it executes and what evidence it returns at each stage. “Migration complete” can mean different work depending on whether business checks and source retirement are included.

IXC's cloud migration service covers dependency assessment, migration sequencing, rehearsal, cutover and stabilization. Pre-release QA can help define checks for critical workflows, permissions and exception paths. Use unresolved worksheet items to agree on what IXC and internal teams will own. Handle production access and data through the agreed access process; shared planning sheets contain references to credentials, never secret values.

The resulting evidence consists of migration groups and data authority, stage results, proceed/hold/recovery decisions and remaining operating work. The fictional example demonstrates how the records connect. Actual execution records require dates, environments, approvals and evidence. Reuse business and environment identifiers in the handover checklist so open migration items continue into operations.