We've written before about what the Azure Well-Architected Framework actually is — a trade-off tool, not a checklist. This piece is the operational sequel: how to run the review itself so it produces changed architecture instead of a scored PDF. Microsoft gives you the assessment for free on Microsoft Learn; what it can't give you is the meeting discipline around it. That's learnable, and it fits in two weeks.
Before the room: three decisions
Scope one workload. Not the estate, not the platform — one named system with an owner. “The claims-processing service,” not “our Azure environment.” The framework is workload-scoped by design, and so is accountability.
Write the business numbers down first. Tolerable downtime, data classification, cost ceiling, recovery objectives. Without them every finding is unfalsifiable — more redundancy is always “better” — and the review degenerates into gold-plating or shrugging. If nobody can state the recovery time objective, that is finding number one; stop and get it.
Book the four people who disagree. Application owner, platform engineer, security, and whoever sees the bill — live, in one session. The entire value of a review is the moment the person paying and the person on call discover they've been assuming different things. Run it async through a questionnaire and you keep the paperwork but lose the collision.
In the room: two hours, five pillars, honest answers
Work through the assessment's pillar questions together, with one hard rule: answer for what is deployed, not what is intended. The tool measures what you say — it has no way to check — and teams reflexively describe the aspirational state. “Are backups tested?” means when did someone last run a restore, not whether a policy document says quarterly.
Expect the pillars to fight — that's the feature, not a failure mode. Reliability wants multi-region; cost wants the idle capacity gone; security wants private endpoints; performance notices the latency. When two pillars collide, the question to settle is “which one are we trading away, and who signs for that?” Record the answer as a decision, not a gap: a consciously accepted single-region deployment with a rationale and an owner is architecture; the same fact discovered in an incident review is negligence. This decision log is the most valuable artifact the review produces — more valuable than the score.
After the room: cut to ten, assign, date
A review that generates forty recommendations generates zero changes. Rank ruthlessly: keep the findings that are cheap to fix or expensive to ignore, cut the tail, and leave with fewer than ten items, each with a named owner and a date. Put the decision log in the repo next to the architecture docs — it's the thing that stops next year's review from re-litigating this year's trade-offs from scratch.
Then sort what's left into two piles, because they have different fixes:
Workload findings — the recovery objective, the data model, scaling behaviour — belong to the application team and get fixed once, here.
Platform findings — identity and least privilege, network segmentation, encryption defaults, backup posture, cost tagging, log retention, allowed regions — will reappear in every workload review you ever run, because they aren't architecture problems. They're the absence of a governed foundation. Policy-as-code in a proper Azure landing zone makes most of this category structurally impossible to get wrong, which is why teams with a landing zone come out of reviews with short lists and teams without one keep buying the same findings repeatedly.
The cadence that makes it stick
Architecture drifts continuously — a workload that scored well in March is not the same workload after two quarters of hot fixes and one departed engineer. The sustainable rhythm we see work: a full facilitated review per critical workload annually, a lightweight re-check of the decision log quarterly (fifteen minutes: are these decisions still true?), and a review triggered by major change — new region, new data classification, 10× scale, or an AI workload landing on the platform.
The two-week version
Week one: pick the workload, extract the business requirements, have each participant run the Microsoft Learn assessment solo. Week two: the two-hour session, the argument, the decision log, the sub-ten action list. That's the whole method. The framework tells you what good looks like — the review, run this way, is what makes anyone act on it.
Deop facilitates Well-Architected reviews against real Azure estates and builds the governed landing zones that make the findings stick — CAF-aligned, as code, with Canadian data residency. See a public-sector example or explore our cloud architecture work.