Planning a migration timeline

Phases and realistic durations

These are typical ranges from engagements we have run. They assume a team with capacity to work on the migration rather than fitting it around a full roadmap.

• Briefing and scoping. Two to four weeks, including the control responsibility matrix and network plan.
• Allocation and provisioning. Two to six weeks depending on allocation year and hardware profile.
• First workload cutover. Four to eight weeks. Longer than later ones because this is where dependencies surface.
• Subsequent workloads. One to three weeks each once the pattern is established.
• Decommissioning the source. One to two weeks after the final cutover, plus whatever your own retention policy requires.

The two steps that run long

First, outbound dependency discovery. Teams consistently underestimate how many outbound destinations a mature workload has accumulated. Where egress was open by default, nothing ever forced anyone to write them down. Budget real time here and do the discovery while the old environment is still running.

Second, evidence collection for the assessor. If your own authorization has to be updated to reflect the new hosting environment, that runs on your assessor's schedule rather than yours. Start the conversation at scoping, not at cutover.

If a specific date drives the whole programme, such as a contract option exercise or an authorization expiry, say so during the briefing. It changes how we sequence allocation.