Azure Well-Architected Review with Remediation Sprint

Microsoft did. The Azure Well-Architected Framework is Microsoft's own guidance for designing and operating workloads on Azure, organized into five pillars: reliability, security, cost optimization, operational excellence and performance efficiency. Microsoft publishes the framework, the per-pillar guidance, the maturity models and the assessment that scores against it. We are not selling you our private opinion of what good architecture looks like — we are running Microsoft's, thoroughly, against your workload, and then fixing the top of the resulting list.

Take it yourself if that is all you need — it is free on Microsoft Assessments and we will point you at it on the discovery call. What the fee buys is the difference between a questionnaire and a review. The assessment is about sixty questions answered by whoever fills in the form, and it is worth precisely as much as the honesty of those answers; teams reliably grade themselves generously on the questions they are least sure about. We answer them from evidence instead — deployed topology, Advisor, Defender for Cloud, monitoring and backup configuration, cost data — with the people who run the workload in the room to be challenged. Then five engineer-days of the findings get implemented. The self-assessment produces a score. This produces a shorter backlog.

Take Microsoft's if you can get it. Microsoft describes the Azure Expert Assessment as a no-cost review by Azure Certified Experts covering cost management, security and reliability, with customers self-nominating through an online portal; eligibility and terms are Microsoft's and they change, so confirm the current position with your Microsoft account team. Three honest differences. It is a review with recommendations — the hands-on remediation in your subscription is still yours to schedule, whereas here five engineer-days of it happen inside the engagement. It covers three pillars in Microsoft's own description; this covers all five, including operational excellence and performance efficiency. And it runs to Microsoft's queue and eligibility rather than to your date. If both are available to you, the sensible move is to take Microsoft's first and bring us the output — we build on it rather than repeat it, and more of the three weeks goes to fixing things.

A workload is one system that delivers a business capability and is operated as a unit — the customer portal, the claims pipeline, the data platform behind reporting — including its compute, data, networking, identity and operational tooling. In practice it is usually a resource group or a small set of them. It is not 'our Azure tenant' and not 'everything in the production subscription'. We agree the boundary in writing on day one, including which shared services (a hub network, the Microsoft Entra ID tenant, a central Log Analytics workspace) are dependencies we take as given rather than things we review. If you need several workloads reviewed we quote per estate, and if you are not sure how many you have, that is a good use of the free discovery call.

Approved, low-blast-radius, high-value fixes get made in your environment, under your change process. Typical items: closing an availability-zone or redundancy gap where the SKU supports it, enabling backup on resources that never had it and proving one restore, adding diagnostic settings and the specific alert rules that would have caught your last incident, right-sizing over-provisioned compute and databases, removing public endpoints and tightening network security groups, moving secrets into Key Vault and connections onto managed identities, clearing orphaned disks, public IPs and stale snapshots, and applying tags and budgets. Every item is proposed with its change plan, blast radius and rollback, and nothing is touched until you approve it in writing. What does not fit this shape — code changes, re-architecture, anything needing a window your business will not grant — stays on the backlog with an estimate.

Then they do not happen in the sprint, and you know that at the point of approval rather than at the end. Every backlog item carries an effort estimate before you choose, so the list you approve is one that fits, and we work highest-value-first inside it. Anything that does not fit is estimated, sequenced and priced separately — another sprint, a scoped project, or work for your own engineers. The cap is what keeps the fee fixed and the promise honest. An uncapped 'we will fix whatever we find' would have to be either a much larger number or a much smaller amount of fixing.

Only changes you have approved in writing, one item at a time, inside your change process and your maintenance windows. Each proposed change comes with what it touches, its blast radius, the rollback and whether it needs a restart or a window. The review itself needs read-only access; write access is granted for the sprint window, scoped to the agreed resources, and revoked at the end. Where a change cannot be made safely in production without a rehearsal, we say so and it stays on the backlog. Nothing in this engagement requires you to accept an unreviewed change.

Likely, on the items that map to them — but we do not promise a number and no target score appears in the quote. Azure Advisor scores your resources in the same five categories as the framework, calculated largely from the proportion of healthy resources against the applicable ones, so fixing real findings tends to move it. The score is a proxy, though: it responds to resource state, and some of the most valuable findings in a review — a recovery path nobody has tested, a dependency nobody documented, an alert nobody would answer — move no score at all. We would rather fix the thing than farm the metric, and anyone guaranteeing you a score is telling you which of the two they are doing.

Some of them do, and the backlog tells you which before you approve anything. Zone redundancy, backup, longer log retention, private endpoints, premium tiers and additional Defender for Cloud plans all cost money — that is what buying reliability and security looks like. Others go the other way: right-sizing, idle and orphaned resources, storage tiering. Every item carries its cost direction. And Microsoft's meters are Microsoft's: Azure consumption, Defender for Cloud plans, Log Analytics ingestion and backup storage are billed by Microsoft to your subscription, not by us. Our fee is fixed and does not vary with what the changes cost or save.

It answers a different question. The Azure performance and cost optimization assessment is a short, low-cost review of an Azure environment for efficiency that hands you recommendations and changes nothing. The Azure Cost Optimization and FinOps Assessment goes wider and deeper on money across the estate and sets up the practice that keeps it optimized. This engagement asks whether one workload is well built across all five pillars — cost is one fifth of it — and ends with approved fixes applied rather than recommendations delivered. If your only problem is the bill, buy one of the cost services instead: they will serve you better and cost less, and we would rather say that here than after you have paid.

Microsoft Defender for Cloud CSPM is a continuous, estate-wide security posture program — plans enabled, recommendations triaged on an ongoing basis, compliance standards tracked over time. This is a point-in-time review of one workload across all five pillars, of which security is one, and we read your existing Defender for Cloud data rather than standing the program up. They fit together: a review that finds real security debt in one workload frequently ends with a recommendation to run CSPM properly across the estate, and the report will say so where the evidence points that way, even though it is a different engagement with a different fee.

Often, yes — and the review will tell you honestly which order to work in. If the workload's problems are mostly foundational — no subscription topology, no policy baseline, no consistent identity or network model — a Well-Architected review will keep producing findings that share one root cause, and the right answer is the Azure Landing Zone and Cloud Adoption Framework implementation first. But a workload that grew organically inside an imperfect environment can still be made materially safer and cheaper in three weeks, and that is often what a team needs before it can fund the larger program. Describe the situation on the discovery call and we will tell you which we would do first, including when the answer is 'not this one yet'.

For the review: Reader on the workload's subscription or resource groups, Cost Management Reader for the spend data, and a Defender for Cloud reader role for the security findings — all read-only, all through your own identity governance, and just-in-time elevation through Microsoft Entra ID is welcome. For the sprint only: contributor-level rights scoped to the agreed resources, granted for the sprint window and revoked at the end. We do not need and will not ask for Owner or User Access Administrator on your subscription, and if someone offers them we will decline in writing. Everything we see is treated as confidential.

For one bounded workload, yes — provided the interviews happen in week one. Scope, evidence, assessment and backlog take the first two weeks; the sprint runs in the third alongside your change windows; the closing report and walkthrough land at the end. The thing that stretches the timeline is not the analysis, it is approvals — if the change list waits a week for a change advisory board, the sprint compresses. That is why we book the sprint window with you at kickoff, and where your process genuinely cannot approve inside the window we agree a later sprint date in writing rather than rushing changes into production.

All of it, and yes. The assessment milestone is saved under your own Microsoft Assessments sign-in, so you can re-run the review next quarter and measure the movement without us. The findings report, the backlog with its estimates, the change and rollback plans and the before-and-after evidence pack are working files handed over with nothing proprietary holding them. Run the residual backlog with your own engineers or another provider if you want to — that is a legitimate outcome, and the report is written to be used rather than to be re-sold.