Azure Landing Zone Chaos? Use CAF to Pick the First 3 Workloads

1. Introduction We’re promised six clean stages in Azure’s Cloud Adoption Framework: Strategy, Plan, Ready, Adopt, Govern, Manage. Sounds simple, right? Microsoft technically frames CAF as foundational phases plus ongoing operational disciplines, but let’s be honest — everyone just wants to know what breaks in the real world. I’ll focus on the two that trip people fastest: Strategy and Plan.

In practice, Strategy turns into wish lists, Ready turns into turf wars over networking, and Governance usually appears only after an auditor throws a fit. Subscribe at m365 dot show for templates that don’t rot in SharePoint.

So let’s start where it all falls apart: that first Strategy doc.

2. The 'Strategy' Stage Nobody Reads Twice The so‑called Strategy phase is where most cloud journeys wobble before they even get going. On paper, Microsoft says this step is about documenting your motivations and outcomes. That’s fair. In reality, the “strategy doc” usually reads like someone stuffed a bingo card full of buzzwords—digital transformation, future‑proofing, innovation at scale—and called it a plan. It might look slick on a slide, but it doesn’t tell anyone what to actually build.

The problem is simple: teams keep it too high‑level. Without measurable outcomes and a real link to workloads, the document is just poetry. A CIO can say, “move faster with AI,” but without naming the application or service, admins are left shrugging. Should they buy GPUs, rewrite a legacy app, or just glue a chatbot into Outlook signatures? If the words can mean anything, they end up meaning nothing.

Finance spots the emptiness right away. They’re staring at fluffy phrases like “greater agility” and thinking, “where are the numbers?” And they’re right. CAF guidance and every piece of industry research says the same thing: strategies stall when leaders don’t pin outcomes to actual workloads and measurable business impact. If your only goal is “be more agile,” you won’t get far—because no one funds or builds around vibes.

This is why real strategy should sound less like a vision statement and more like a to‑do list with metrics attached. One strong example: “Migrate identified SQL workloads onto Azure SQL Managed Instance to cut on‑prem licensing costs and simplify operations.” That sentence gives leadership something to measure, tells admins what Azure service to prepare, and gives finance a stake in the outcome. Compare that to “future‑proof our data layer” and tell me which one actually survives past the kickoff call.

The CAF makes this easier if you actually pick up its own tools. There’s a strategy and plan template, plus the Cloud Adoption Strategy Evaluator, both of which are designed to help turn “motivations” into measurable business outcomes. Not fun to fill out, sure, but those worksheets force clarity. They ask questions like: What’s the business result? What motivates this migration? What’s the cost pattern? Suddenly, your strategy ties to metrics finance can understand and guardrails engineering can build against.

When teams skip that, the fallout spreads fast. The landing zone design becomes a mess because nobody knows which workloads will use it. Subscription and networking debates drag on endlessly because no one agreed what success looks like. Security baselines stay abstract until something breaks in production. Everything downstream suffers from the fact that Strategy was written as copy‑paste marketing instead of a real playbook.

I’ve watched organizations crash CAF this way over and over. And every time, the pattern is the same: endless governance fights, firefighting in adoption, endless meetings where each group argues, “well I thought…” None of this is because Azure doesn’t work. It’s because the business strategy wasn’t grounded in what to migrate, why it mattered, and what to measure.

Building a tighter strategy doesn’t mean writing a 50‑page appendix of jargon. It means translating leadership’s slogans into bite‑sized commitments. Instead of “we’ll innovate faster,” write, “stand up containerized deployments in Azure Kubernetes Service to improve release cycles.” Don’t say “increase resilience.” Say, “implement Azure Site Recovery so payroll can’t go offline longer than 15 minutes.” Short, direct, measurable. Those are the statements people can rally around.

That’s really the test: can a tech lead, a finance analyst, and a business sponsor all read the strategy document and point to the same service, the same workload, and the same expected outcome? If yes, you’ve just unlocked alignment. If no, then you’re building on sand, and every later stage of CAF will feel like duct tape and guesswork.

So, trim the fluff, nail the three ingredients—clear outcome, named workload, linked Azure service—and use Microsoft’s own templates to force the discipline. Treat Strategy as the foundation, not the marketing splash page.

Now, even if you nail that, the next question is whether the numbers actually hold up. Because unlike engineers, CFOs won’t be swayed by slides covered in promises of “synergy.” They want to see how the math works out—and that’s where we hit the next make‑or‑break moment in CAF.

3. The Business Case CFOs Actually Believe You know what gets zero reaction in a CFO meeting? A PowerPoint filled with “collaboration synergies” and pastel arrows pointing in circles. That stuff is basically CFO repellant. If you want the finance side to actually lean forward, you need to speak in their language: concrete numbers, clear timelines, and accountability when costs spike. That’s exactly where the CAF’s Plan phase either makes you look credible or exposes you as an amateur.

On paper, the Plan phase is straightforward. Microsoft tells you to evaluate financial considerations, model total cost of ownership, map ROI, and assign ownership. Sounds simple. But in practice? Teams often treat “build a business case” as an excuse to recycle the same empty jargon from the strategy doc. They’ll throw words like “innovation at scale” into a deck and call it evidence. To finance, that’s not a plan. That’s the horoscope section wearing a suit.

Here’s the shortcut failure I’ve seen firsthand. A migration team promised cost savings in a glossy pitch but hadn’t even run an Azure Migrate assessment or looked at Reserved Instances. When finance asked for actual projections, they had nothing. The CFO torched the proposal on the spot, and months later half their workloads are still running in a half-empty data center. The lesson: never promise savings you can’t model, because finance will kill it instantly.

So, what do CFOs actually want? It boils down to three simple checkpoints. First: the real upfront cost, usually the bill you’ll eat in the next quarter. No fluffy “ranges,” just an actual number generated from Azure Migrate or the TCO calculator. Second: a break-even timeline that shows when the predicted savings overtake the upfront spend. Saying “it’s cheaper long term” doesn’t work unless you pin dates to it. Third: accountability for overages. Who takes the hit if costs balloon? Without naming an owner, the business case looks like fantasy budgeting.

CAF is crystal clear here: the Plan phase is about evaluating financial considerations and building a case that ties cloud economics to business outcomes. That means actually using the tools Microsoft hands you. Run an Azure Migrate assessment to get a defensible baseline of workload costs. Use the TCO calculator to compare on-prem numbers against Azure, factoring in cost levers like Reserved Instances, Savings Plans, and the Azure Hybrid Benefit. Then put those values into a model that finance understands—upfront expense, break-even point, and long-term cost control tied back to the workloads you already named in strategy.

And don’t stop with raw numbers. Translate technical optimizations into measurable impacts that matter outside IT. Example: adopting Reserved Instances doesn’t just “optimize compute.” It locks cost predictability for three years, which finance translates into stable budgets. Leveraging Hybrid Use Benefit isn’t just “reduced licensing waste.” It changes the line item on your quarterly bill. Automating patching through Azure reduces ticket volume, and that directly cuts service desk hours, which is payroll savings the finance team can measure. These aren’t abstract IT benefits—they’re business outcomes written as numbers.

Here’s why that shift works: IT staff often get hyped about words like “containers” or “zero trust.” Finance doesn’t. They respond when you connect those projects to reduced overtime hours, lower software licensing, or avoidance of capital hardware purchases. The CAF framework is designed to help you make those connections, but you actually have to fill in the models and show the math. Run the scenarios, document the timelines, and make overspend ownership explicit. That’s the difference between a CFO hearing “investment theater” and a CFO signing off budget.

Bottom line: if you can walk into a boardroom and say, “Here’s next quarter’s Azure bill, here’s when we break even, and here’s who owns risk if we overspend,” you’ll get nods instead of eye-rolls. That’s a business case a CFO can actually believe.

But the Plan phase doesn’t automatically solve the next trap. Even the best strategy and cost model often end up filed away in SharePoint, forgotten within weeks. The numbers may be solid, but they don’t mean much if nobody reopens the document once the project starts rolling.

4. The Forgotten Strategy That Dies in SharePoint Here’s the quiet killer in most CAF rollouts: the strategy that gets filed away after kickoff and never looked at again. The so‑called north star ends up parked in SharePoint next to HR handbooks, turning from playbook into wallpaper the moment the applause dies down. Meanwhile the actual project teams start chasing sidequests—subscription layouts, tagging debates, resource group hierarchies. Useful work, sure, but none of it proves the business case that was supposed to guide the migration in the first place.

I’ve seen it happen in embarrassing ways. One project team built a shiny deck full of buzzwords and slides so polished they could blind you. They fought over fonts, ran fake workflow demos, and ended with a file literally named “Version_final_FINAL2.” The irony? Nobody ever opened it again. Months of work instantly transformed into digital clutter that may as well have been an old cafeteria menu.

What’s going wrong here isn’t Microsoft’s framework. CAF doesn’t say “write a deck and forget it.” It says: motivate business outcomes, tie them to workloads, and keep those outcomes visible through the Plan and Ready phases. The breakdown is on us. Many strategies stall because leaders don’t keep them active, don’t measure outcomes against their review cycles, and never connect them to the operating rhythms leadership already lives by. CAF itself warns about these antipatterns and makes it clear—if you don’t feed the strategy back into planning and governance, it will die.

Here’s the fix, and it’s not complicated: turn the strategy doc into something operational. Every single motivation should map to four things—one workload, one Azure service, one metric, and one review cadence. Example: “Migrate Payroll SQL database into Azure SQL Managed Instance, reduce server maintenance hours by 20, track progress in quarterly ops reviews.” There’s nothing abstract about it. Workload named, service picked, metric in sight, meeting cadence assigned. That’s how a doc stays alive instead of fading out in SharePoint.

CAF’s guidance backs this up. The Plan phase pushes you to run financial models that leadership will understand. The Ready phase demands landing zones configured against actual use cases. Both expect you to revisit and update the business outcomes regularly, not just hold onto static slides. Tie the technical KPIs directly into the reporting rhythm leadership already trusts—month‑end budget calls, sprint demos, or quarterly objectives reviews. Do that, and the strategy gets pulled back on stage every cycle instead of rotting in the archives.

The danger of ignoring this is simple. If strategy isn’t brought forward, governance shows up too late. And when governance arrives after the fact, it isn’t guidance; it’s emergency duct tape. By then, costs have spiked, teams are improvising controls, and leadership is side‑eyeing IT like the whole CAF exercise was theater. Nobody wins in that firefight.

So here’s a pro tip: don’t overcomplicate it. Start small. Pick one outcome from your strategy—just one—and write the sentence that links outcome to workload, metric, and owner. Then, slip that sentence into the board pack or ops review deck your leadership already sees every month. That tiny move puts your strategy back in the bloodstream of the organization, and once it’s circulating, it won’t die quietly in a SharePoint folder.

Get that right, and you escape the “forgotten doc” trap. But survival here only puts you on the launchpad for the next challenge. Because even when strategy stays alive, there’s a fresh failure waiting in the Plan phase. That’s when people stretch “define scope” until it balloons into something that looks less like a project plan and more like a world hunger initiative. And that’s where things get messy fast.

5. Scope Creep: When CAF Promises to Solve World Hunger CAF’s Plan stage looks harmless on paper: “define scope and align resources.” In reality, that’s the moment your migration plan balloons. A small ask like “move a couple of apps” quickly mutates into ERP, analytics, collaboration tools, and, because someone once read a Gartner slide, VDI too. Before you know it, you’ve promised to fix every IT headache in the organization—usually without writing a single step that might actually get done.

I’ve watched meetings derail in the same predictable pattern. Someone suggests migrating Exchange. Another exec chimes in: “If we’re touching that, let’s throw in ERP.” A third piles on analytics, and by the time identity management gets added, the plan reads like an infomercial: “but wait, there’s more!” More scope, more dependencies, and less chance of actually finishing even the first item.

The most disastrous version is when leadership declares, “We will migrate all current and future workloads.” That’s not ambition—it’s self-sabotage. Teams can’t figure out where to begin, budget owners stop paying attention, and IT staff quietly keep workloads running in basements because at least those are tangible. If your scope reads like a 10-year master plan to end world hunger, you’re not even moving file shares to Azure.

And it’s not just cynical war stories here. Research and CAF guidance both make the same point: “big bang” migrations push failure risk way up. Phased approaches and targeted pilots succeed more often because they’re narrow, measurable, and survivable. Leaders can sign off on backup workloads or a SQL pilot. They won’t buy into a 200-slide pitch where “phase one” already spans the entire company. Scope credibility matters as much as technical feasibility.

Picture giving your CFO a timeline that claims in twelve months you’ll migrate every production app, rebuild analytics, redesign WAN, and train the entire staff. That’s the kind of fantasy that gets rejected before slide two. Everyone in the room knows you’ll blow deadlines in weeks, not months, and your credibility dies right there. Once that happens, even modest asks look suspect. You’ve poisoned your budget runway.

The safer play is targeting workloads that hit three criteria: visible, high value, and low-integration pain. That’s where the CAF Plan phase shines when done right. Backup and disaster recovery is the poster child. Use Azure Site Recovery to take something critical but isolated, and suddenly you can show measurable uptime improvements and compliance reports without touching half the org. Another smart step: move a single SQL workload with Azure Hybrid Benefit—a narrow, well-bounded project that’s easy to measure. If you want to flex engineering skills, containerize one customer-facing app in AKS and prove shorter release cycles. Each one of these ties directly to CAF’s intent: manage scope, validate landing zones, establish patterns you can expand later.

That’s the rhythm CAF wants you to follow. First: migrate one workload. Second: validate your landing zone and governance model against it. Third: expand to the next logical set of workloads with each success building momentum for budget and buy-in. It’s practical, proven, and resilient against the scope creep monster.

And here’s the kicker—every extra scope item you add poisons your timeline. ERP drags integration and licensing into the trenches. Analytics overhauls spawn committees. VDI sparks vendor wars. Each item multiplies dependencies, and instead of delivering one clean success, you’ve got three teams trapped in perpetual planning workshops. The outcome? Zero visible wins.

Nobody’s saying think small forever. CAF is designed for full enterprise transformation. But it assumes you climb there step by step, not jump the whole ladder. Give leadership narrow, high-value outcomes, and you turn strategy into actual track record. Over time, those victories compound. That’s how a plan stays credible.

Bottom line: narrow scope equals faster wins, and faster wins unlock budget for phase two. That’s the loop you want to build.

Of course, cautioning about scope doesn’t stop the next derailment. Even when the tech makes sense, even when the landing zone is ready, the weak link is often people. And that’s the challenge CAF diagrams rarely capture.

6. Why People, Not Tech, Derail the CAF CAF loves to talk about landing zones, governance, cost controls, and security guardrails. All good things. But here’s the bit you don’t see on those tidy diagrams: the people angle. The tech usually stands up in record time. The humans running it? That’s where progress grinds to a halt. I’ve never watched a migration collapse because Azure dropped dead. Every single one fell apart because teams argued over ownership, or leadership assumed roles would sort themselves out.

Case in point: one org I worked with hit every milestone on the tech side in two months flat—landing zones deployed, guardrails enforced, dashboards glowing with more metrics than anyone could read. Then, dead stop. Why? Networking and security locked horns over who owned Identity and Access Management. Weeks of turf war passed—network said IAM was theirs, security said absolutely not. Developers sat idle. Timelines slipped. CFOs lost patience. The infrastructure was solid, but the people alignment was nonexistent.

And that mess isn’t rare. Surveys and CAF guidance consistently warn that adoption hurdles come more from people, processes, and skills gaps than the tech itself. “Organizational misalignment” sounds like buzzword bingo, but it’s real: unclear accountability, missing skills, everyone pointing fingers while the project stalls. Microsoft even calls this out—CAF has whole sections on organizational alignment and skills readiness. Ignore it, and no amount of cloned governance templates from GitHub will save you.

These gaps show up in painfully obvious ways. You ask ops to containerize workloads and they’ve never touched AKS. You expect finance to track spend but they don’t even know where Cost Management lives in the portal. Someone has to own IAM, someone has to own patching, someone has to own billing. If names aren’t written in ink, when things go sideways every group suddenly claims they were “support only.” Translation: your landing zone becomes a fancy but ownerless playground, and your cloud bill triples before anyone admits responsibility.

The fix here is as much about structure as tools. CAF recommends creating distinct teams—Cloud Strategy, Cloud Adoption, Cloud Governance, Cloud Operations—so ownership is clear across functions. A practical way to do that is forming a Cloud Center of Excellence. Don’t let “excellence” fool you; this isn’t some ivory tower. It’s a cross-team crew where networking, security, devops, ops, and finance all sit together and hash out how strategy turns into action. Their job: keep decisions connected between the business goals and technical execution, and make sure no workload or bill slips through the cracks.

To make it concrete, here’s the bare minimum membership that works: one rep covering security/identity, one from networking/ops, one from finance. Between them, you lock three things down—an IAM owner, a billing owner, and a patching/operations owner. If those three are named, escalations don’t turn into finger-pointing festivals. Instead, they get routed fast to the right person. Without that, you’re one outage away from people shrugging under fluorescent lights while workloads hang. Pro tip: name those owners in ink before you sign a single Azure subscription.

Now, timing matters too. Too many shops wait until the Govern or Manage phases to think about alignment, which is about three months too late. CAF literally tells you in its Plan and Ready docs to map out training needs, identify skill gaps, and assign roles early. That’s the boring upfront work that keeps “governance” from feeling like duct tape slapped on after the main building already burned down. If you bake people alignment in the Plan stage, and run skill uplift in Ready, CAF actually lands the way Microsoft advertises it.

Because the truth is, pejorative as it sounds, office politics will always beat clean diagrams. A security team that sees cloud as a threat will stall everything until leadership forces their hand. Ops groups terrified of automation will cling to manual reboots like it’s still 2008. And yes, some leaders still think progress equals 30-minute PowerPoint updates. Those problems don’t show up in CAF charts, but they kill momentum if you skip alignment. The safety valve is putting names to roles and giving the CCoE authority to settle turf wars before they stall the whole migration.

Bottom line: the weakest link isn’t Azure—it’s people working out who owns what. If you solve that with clarity, structured teams, and skill-building tied into Plan and Ready, CAF finally works the way the documentation promises. Skip it, and your landing zones and “strategy docs” will be just another museum exhibit in SharePoint.

And that’s the hard edge to remember as we wrap this up: CAF works, but only if you do the unglamorous part—shrink the wish list, build the numbers finance will trust, and keep strategy tied to execution through the people.

7. Conclusion So where does all this leave us? CAF isn’t a magic wand—it’s a framework you actually have to work. The takeaways are simple. First, make strategy measurable: tie every outcome to a concrete workload and the Azure service that supports it. Second, build a business case finance will actually sign by using Azure’s cost levers like Hybrid Benefit, Reserved Instances, and real numbers from Azure Migrate. Third, fix the people piece early—set up a Cloud Center of Excellence and name owners before launch.

Do one action in the next 48 hours: write a single sentence that links a business outcome to an Azure service and name its owner. Slide that into next week’s board pack and you’ve already beaten most stalled strategies.

Subscribe Newsletter at m365 Dot Show or Follow us on the M365.Show LinkedIn page for Livestreams with world leading MVPS. And keep your CAF doc where it belongs—in the board pack, alive as a dashboard—not buried as SharePoint clutter.