Deciding whether an Azure workload can go live
A decision note for whoever signs the go-live. A free score built from the platform's own signals will tell you roughly where a workload stands. It will not tell you whether it can carry production traffic on the date you have committed to.
The decision, in short
Somebody senior has to say, on the record, whether the workload can go live or be accepted into operations by a named date. That is a judgement about consequences rather than a number: what the workload does, what it costs when it fails, and which gaps have to close before the date rather than after it.
A headline score is an input to that judgement and cannot be the answer, because most of the checklist it is scored against cannot be read off a machine at all.
Where this comes up
The date usually arrives before the certainty does. A launch is booked, operational ownership passes to another team, an acquisition hands the estate over, or a second incident turns the first one into a pattern.
An engineer runs a free assessment to see where things stand and gets a score. The score travels well: it fits in a message and it sounds like an answer. Then somebody has to sign, and finds that the score does not cover the questions the signature is actually about.
What the free taster establishes
The Azure Well-Architected Taster is free and open. It runs from your own Azure CLI in about a minute, and it builds a headline Well-Architected score from Azure Advisor signal and the Defender secure score.
- Deterministic and read-only, with no sign-up, and nothing leaves your tenant
- A real reading of configuration and telemetry across the five Well-Architected pillars
- Honest about its own ceiling, and it says so in every report it writes
- Enough to tell you roughly where you stand, and whether the gap is worth looking at properly
What this does not establish
- Most of the framework. At least 40 of Microsoft's 59 checklist recommendations cannot be read off a machine, leaving at most 19 that can - whether failure-mode analysis was done, whether data is classified, whether segmentation was deliberate, whether recovery targets match what the business can carry
- Whether a gap is a blocker. Severity in the abstract is not the same as must-close-before-the-date, which depends on the flows in scope and the operational requirements the workload has to meet
- Whether a tradeoff is a fault. Microsoft's framework says plainly that tightening one pillar costs another; a scan marks a deliberate decision as a failure
- Whether a recovery claim is true. From outside, an untested recovery plan and a tested one look identical
- What actually moved. Without a dated baseline, a later reading cannot show whether anything changed or only the signal did
Who usually owns this decision
The person who signs it - normally a head of platform or an engineering director. Whoever is accountable for the workload once it carries real traffic, and whoever will be asked afterwards what they knew at the time.
Where operational ownership is changing hands, the receiving team's owner belongs in the decision too: they inherit everything that is not fixed before the date. The engineer who ran the assessment supplies evidence and does not carry the consequence, which is the whole reason this note exists as something to forward rather than something to act on.
The bounded work DBHQ would take on
An Azure Well-Architected Review: one bounded workload, read-only access, and an engineering readiness recommendation for a named date. All 59 checks judged against your estate with the evidence for each, release or handover blockers separated from work that can follow the date, a prioritised backlog with owners, effort and acceptance conditions, and a dated baseline so a later review can show what moved.
You keep the launch decision; the review supplies the case for it. Remediation is quoted separately, and the backlog is yours to use with any delivery team.
A workload, and a date it has to clear?
Bring the workload and the date. You will get a straight answer on whether a readiness review is the right instrument, what it would cover and when it would report.
I reply within 24 hours
https://dbhq.uk/notes/azure-launch-readiness/ · dan@dbhq.uk