Cloud migration planning

A cloud migration plan should identify which workloads will move, how they will be grouped into waves, how each group will cut over and what must be checked before its old service is retired. Start with the business outcome and an existing workload assessment, then turn the findings into a sequence that owners can approve and operators can follow.

Decide what belongs in the migration

For each workload, confirm its business owner, reason for moving, proposed destination and unresolved constraints. Give it an initial treatment: move largely as it is, make limited platform changes, replace it, retain it for now or retire it.

That classification is a planning decision; it does not prove the destination is compatible. Investigate actual users and records before retiring a system whose purpose is unclear.

Keep the migration record focused on the change from the current service to an agreed design. Broader infrastructure planning determines where the workload could run and who would operate it.

AWS Prescriptive Guidance groups migration treatments into seven strategies: Retire, Retain, Rehost, Relocate, Repurchase, Replatform and Refactor or re-architect. For large migrations, it identifies rehosting, relocating and replatforming as common strategies, and cautions that refactoring during the migration adds complexity. One option is to move first and modernise after migration is complete.

Cloud Migration Strategies: AWS Prescriptive Guidance

Set the conditions for each move

Agree with the owner on an acceptable interruption, a cutover window and how much data loss, if any, the business can tolerate. Record business dates such as payroll processing or month-end close, along with the people needed to approve and support the change.

Where an Australian organisation handles personal information, have the privacy owner review the actual storage, contractor and overseas access arrangements. An Australian target location alone does not settle those questions. The Australian Privacy Principles apply according to the organisation and the handling arrangement.

Define acceptance checks as actions users must complete with the expected data and access. Include important integrations, background jobs and monitoring. These are checks to perform during migration, not results established by the plan.

Build groups and waves

Use assessed dependencies to identify components that must move together and those that can remain connected across environments temporarily. A shared writable database may affect several applications; a less frequent feed may be separable if its delay and data state are acceptable. Record an owner and a verification step for each proposed temporary connection.

Place move groups into waves that the available team can prepare, cut over, validate and support. An early wave should teach the team something useful while keeping the business impact manageable. A development move can reveal a procedural gap, but it does not prove production performance or a different integration will work.

Treat wave order as provisional while material dependencies or readiness questions remain open. Revise it when discovery or a rehearsal changes the scope.

A wave plan can be organised into phases: design approval, cutover planning, pre-migration preparation, cutover, post-migration support and wave closure. Set an expected duration for each phase so teams can plan and check progress; the phases are a planning example, not a fixed schedule.

AWS Prescriptive Guidance recommends keeping waves within 6 to 10 weeks, while noting that duration depends on effort and complexity.

Phases of a Cloud Migration Wave

Migration Wave Duration Guidelines

Prepare and close each cutover

Write a runbook for each move group. Name the current system of record, transfer method, source-write controls, final synchronisation, traffic change and application checks. Assign operators and a decision owner, with a time allowance and pause condition for significant steps.

A planned outage may simplify data consistency when writes can be stopped. A phased move requires the application, routing and shared data to support operation across both environments.

Rehearse the relevant sequence and record what the exercise did and did not cover. Keep the source usable for the agreed fallback period, subject to its data state.

After cutover, record completed user actions, data checks, incidents, outstanding defects and the handover owner. Mark unchecked conditions unassessed. Retire the old service only after the business and technical owners accept the new one and the data position is clear.

Readiness also depends on people and change controls. Microsoft Learn recommends distributing a schedule that sets out migration timing, expected service impacts, responsibilities, contingency arrangements and support contacts.

Confirm technical support for the full migration window, agree escalation paths and response expectations, and review roles, verification procedures, access and monitoring with support teams before work begins.

For a migration window that needs source-system stability, establish a change freeze and controls to prevent unapproved changes. For example, deployment pipelines can block releases to the source environment during the freeze period. Treat the freeze, support coverage and readiness review as explicit pre-cutover checks, with an owner responsible for confirming each one.

Pre-Cutover Readiness Checks for Australian Organisations

Key Milestones in Cloud Cutover Planning