Cloud Adoption Framework Series - Part 2: Plan
Welcome back! In Part 1 we explored the Strategy pillar, where we clarified why your organisation is adopting the cloud.
Today we switch gears from aspiration to action and look at the Plan pillar of Microsoft’s Cloud Adoption Framework (CAF). This phase turns high-level intent into an executable roadmap, aligning people, processes and technology for a predictable, value-driven migration.
What is the Plan Phase?
The Plan phase converts strategic goals into an iterative cloud adoption plan - essentially a living backlog that your teams can execute, measure and refine. Typical planning activities centre on four exercises:
- Digital-estate inventory & rationalisation
- Initial organisational alignment
- Skills-readiness planning
- Building the cloud adoption plan itself
By the end of the phase you’ll know what to move, how to move it, who will own the work, and when each iteration should land.
Key objectives
- Catalogue & assess every workload, application and data asset.
- Prioritise business-critical workloads for early wins.
- Choose rationalisation paths (the 5 Rs: Rehost, Refactor, Rearchitect, Rebuild, Replace).
- Align teams & budgets with the plan backlog.
- Close skills gaps before launch.
- Establish timelines, sprints and release criteria.
Why is Planning Important?
| Benefit | Why it matters |
|---|---|
| Bridges business & tech | Maps outcomes to specific delivery tasks, budgets and KPIs. |
| Manages risk & cost | Rationalisation and inventory prevent “lift-and-hope” migrations that bleed cash. |
| Enables agility | Iterative releases replace long waterfall cycles, embracing cloud’s pay-as-you-go model. |
| Drives stakeholder confidence | A transparent backlog shows leadership exactly where money and effort go. |
What to Look Out For
| Pitfall | The Gotcha | Counter-Measure |
|---|---|---|
| Incomplete inventory | Shadow IT and low-value apps sneak through, derailing later waves. | Use automated discovery and SME interviews to surface hidden assets. |
| Unrealistic timelines | On-prem lead-times differ vastly from cloud; sprint burn-down suffers. | Validate estimates with pilot workloads; buffer for rework. |
| “Big-bang” mindset | Sequential waterfall plans recreate old constraints. | Adopt agile iterations and incremental releases. |
| Skill gaps ignored | Teams stall mid-migration, outsourcing spirals. | Build a skills-readiness plan with targeted training early. |
| Missing business case | Finance pulls funding when ROI is opaque. | Tie every backlog item to Strategy-phase business outcomes. |
What You Need to Do
Confirm prerequisites
Ensure motivations, business outcomes and governance guardrails from Strategy are documented and approved.
Inventory & rationalise your digital estate
- Discover all servers, apps, data and dependencies.
- Dependencies especially are key - you really don't want to migrate a SQL DB to Azure to then find that the application is still sitting in your on-premises datacentre where the latency is now 10-15 times more than what it was and now data is 'tromboning' your link
- Group servers together into migration batches that have a heavy reliance on each other
- Apply the 5 Rs to each workload:
- Rehost (lift & shift)
- Refactor
- Rearchitect
- Rebuild
- Replace
- Capture results in an adoption backlog (Azure Boards, Jira, etc.).
- This could also be a spreadsheet if you are more comfortable using this type of tool! (Did this for a customer with 6,000 workloads, which worked surprisingly well!!)
When looking at the 5 Rs in step 2, do not underestimate how long the other options may take if they are not rehost. Some applications may also not be able to be refactored or rearchitected, or those options may take significant development time. I have seen a lot of success in where customers have done a very quick rehost of their services to Azure, and then refactored and rearchitected them afterwards.
☝️ It is key to ensure you do this as soon as you have finished the migration. You are spending money on services that can be refactored and rearchitected to use PaaS services rather than costly IaaS services.
Prioritise workloads
Select the first 10 workloads that give maximum business value with manageable complexity.
Align assets & organisation
Map supporting assets to each workload, assign Product Owners, and establish a RACI matrix so accountability is clear.
Create a skills-readiness plan
Identify competency gaps (e.g., IaC, FinOps, security) and schedule training, labs or partner support before migration waves begin.
Establish iterations & release plans
Define sprint length, Definition-of-Done, and release milestones. Resist the temptation for one giant cutover - embrace incremental change.
Estimate timelines & secure budget
Use T-shirt sizing or story-pointing to forecast effort. Link estimates to cost models so finance sees the runway up front. You may also want to consider the options around creating a FinOps team here to ensure that cloud spending doesn't quickly spiral out of control!
Conclusion
The Plan phase is where cloud ambitions become an actionable, budgeted roadmap. Investing time here prevents chaos later and accelerates time-to-value when migration starts.
In Part 3 we’ll dive into the Ready pillar, where we’ll build the landing zone that will host your newly planned workloads.