cloud-migration-strategy

Inventory every workload with its dependencies, then assign each one of the 6 R's (Rehost, Replatform, Refactor, Repurchase, Retire, Retain) with a documented reason. Avoid applying a single strategy to everything, and retire unused applications before moving anything.

The strangler-fig pattern migrates large systems incrementally by placing a routing layer in front of the existing system, building capabilities one at a time in the new environment, and redirecting routes gradually. Each step is small, testable, and reversible, avoiding a big-bang cutover.

No. Re-architecting during the move couples a platform change with a design change, making failures unattributable and rollbacks harder. Rehost or replatform first, stabilize in the cloud, then refactor only the workloads that justify the engineering cost.

Use a bulk transfer of historical data followed by change data capture or ongoing replication to keep the target in sync until cutover. Validate with row counts, checksums, and reconciliation, and compare network transfer time against deadlines, considering physical transfer appliances for very large datasets.

Cutover outages concentrate when there is no parallel run, canary traffic shift, or tested rollback. Run old and new systems in parallel, shift a small traffic slice first, validate the target before real users, and schedule the cutover in a low-traffic window.