Cloud Computing Architecture Guide

Waves, Data Movement, Cutover, and Rollback

Goal

Turn portfolio intent into controlled execution through dependency-aware waves, rehearsal, explicit gates, and safe recovery choices.

The Short Version

A migration wave is a learning and risk boundary, not merely a batch of assets. It groups workloads that can move together because their dependencies, business windows, technical method, and operating teams align. Each wave should improve the method for the next one.

Cutover is a business and technical state transition. Data synchronization, traffic routing, user communication, validation, decision authority, and support coverage must converge at the same time.

The Wave Loop

flowchart LR
    A["Plan"] --> B["Rehearse"] --> C["Synchronize"] --> D{"Go / no-go"}
    D -- Go --> E["Cut over"] --> F["Validate"] --> G["Stabilize"]
    D -- Stop --> A
    G --> H["Apply lessons"] --> A

Choose early waves that are representative enough to test identity, connectivity, data, monitoring, support, and cost practices without concentrating unacceptable business risk. Sequence around dependency groups, criticality, deadlines, business calendars, method, team capacity, and evidence confidence. Leave enough time between waves to stabilize and incorporate learning.

Data and Cutover Decisions

Data movement needs an agreed source of truth, encryption, bandwidth plan, initial copy, change synchronization, integrity checks, reconciliation, retention, and freeze-window decision. The application and data plan must agree about when writes stop, where they resume, and how conflicts or late transactions are handled.

A cutover runbook includes identity, DNS, certificates, routing, integrations, jobs, partner allowlists, communications, staffing, monitoring, business validation, and decision authority. Define go/no-go evidence, stop conditions, success criteria, and a time after which the recovery choice changes.

Rollback is not always safe. Once users write new data in the destination, returning traffic to the old system may lose or split state. A roll-forward repair, read-only mode, or alternate manual process can be safer. Rehearsal should establish what can actually be reversed and within which window.

Example: Customer Application and Database

A customer application and its tightly coupled database move together. Shared identity remains available across both environments. The team performs an initial data copy, streams changes, rehearses DNS and certificate updates, and validates order counts and payment reconciliation. After destination writes begin, the plan switches from simple rollback to a roll-forward or controlled service pause.

Common Mistakes

  • Grouping workloads by server count or department alone.

  • Calling rollback complete without accounting for destination writes.

  • Leaving business validation and communication outside the runbook.

  • Starting waves faster than teams can stabilize and learn.

If Someone Asks You

A safe wave groups dependency-compatible workloads, rehearses data and cutover steps, defines go/no-go and recovery authority, validates business outcomes, and leaves time to stabilize. Its lessons must improve the next wave.

What You Should Remember

Sequence around dependencies, rehearse the transition, and make go, stop, and recovery decisions explicit.

Questions to Check Your Understanding

  1. Which factors make workloads good candidates for one wave?

  2. Why can rollback become unsafe after cutover?

  3. What evidence belongs at a go/no-go gate?

Further Study