Azure grew out of Microsoft 365, and the seams show
Most Azure estates started as an extension of the corporate tenant rather than as a platform, and inherit its assumptions.
Resource groups accumulating without a management-group hierarchy, and nobody certain which subscription a workload should live in.
No clear boundaryEntra ID roles handed out permanently instead of through PIM, guest accounts nobody has reviewed, and Conditional Access nobody wants to touch.
Standing accessReservations and Savings Plans bought against a workload that has since changed shape, and no tag policy to attribute the rest.
Growing, unattributedA domain controller in a VM, an ExpressRoute nobody has re-tested, and on-prem dependencies that only surface during an incident.
Undocumented couplingWe run Azure. Getting you onto it is a separate job.
Where this sits relative to the work either side of it, so you can tell what you are and are not buying.
Cloud Enablement
Landing zones, migration and the architecture that should exist before anyone operates it.
Go to the pageAzure, operated
Day-to-day operation of an Azure estate: identity, governance, network, patching, backup, cost and on-call. Continuous rather than scoped.
Platform
When teams should be self-serving through golden paths rather than raising tickets.
Go to the pagePlenty of clients buy one layer and run the rest themselves. That is a normal outcome, not a half-sale.
What running Azure actually involves
Governance and subscriptions
Management groups with a hierarchy that means something, Azure Policy for the rules you want enforced rather than documented, Bicep or Terraform through reviewed pipelines for landing new subscriptions, and Defender for Cloud recommendations triaged rather than ignored.
Identity
Entra ID done deliberately: PIM for privileged roles so access is time-bound, Conditional Access policies written down and tested, managed identities instead of service principals with secrets, and an access review that actually runs.
Network
Hub-and-spoke with Virtual WAN or peering, Private Endpoints for PaaS services that should not be public, Application Gateway or Front Door at the edge, and NSG rules someone can explain.
Compute and workloads
App Service, Container Apps, AKS or VMs chosen for the workload, with autoscaling, Reserved Instances and Spot where each genuinely fits.
Data, backup and recovery
Azure SQL or PostgreSQL Flexible Server with a rehearsed restore, Recovery Services vaults with immutability where retention matters, and a documented recovery objective rather than an assumed one.
Cost and observability
Cost Management wired to the teams causing the spend, tag policy enforced by Azure Policy, plus Azure Monitor, Log Analytics and Grafana with alerts that mean something and runbooks behind them.
Investigate, implement, hand over
What is genuinely running: accounts, workloads, identity, network, backups, cost, and how a change reaches production today. You get a written picture of the current state and a scope in priority order — what is dangerous, what is expensive, and what can wait.
The priority items, in sequence, as code in your repositories. Rehearsed in the lower environments first, with the rollback run rather than described. Nothing goes in that your own engineers cannot read.
Runbooks, architecture decisions and the reasoning behind them, written down. A working session per area with your team. We stay on-call afterwards only if you want us to.
Microsoft runs the platform. Count what is left.
This is the honest version of a comparison most pages skip. The provider takes real work off you — and it takes one layer, not the stack.
Microsoft Azure
The physical estate, the hypervisor, the PaaS control planes and the SLAs behind them. Microsoft does this well, and it is genuinely worth paying for.
What is left
Management-group and subscription design. Entra ID roles and Conditional Access. Network topology. Patching. Backup and rehearsed restore. Observability. Cost. And every workload running on top.
What you are actually choosing between
| Option | Left as code | Runs day to day | Actively cuts cost | Security you can evidence | No key-person risk | Best fit when… |
|---|---|---|---|---|---|---|
| Hire in-house | the work is genuinely continuous — then hiring is the right call. | |||||
| Generalist MSP | you only need the lights kept on. | |||||
| Leave it alone | nothing has broken, been audited, or been queried yet. | |||||
| OpsHero | the work comes in bursts and has to outlast us. |
Managed Azure is not right for everybody
If Azure is genuinely just a few VMs and a SQL database, and your IT provider already patches them, a managed engagement is probably the wrong purchase. The point at which this pays is when identity, governance and cost stop fitting in one person's head. We would rather say that on a page than halfway through an engagement.
None of it is true yet. Worth a conversation.
Your answers stay in your browser.
The ones people actually ask
Our IT provider already looks after Azure.
Then the useful question is what they own. Patching VMs is not the same as owning governance, identity boundaries, cost attribution and rehearsed restores. If those are still unowned, that is the gap.
Do you work with our existing Microsoft agreement?
Yes. You keep your own licensing and billing relationship with Microsoft or your reseller. We are not in the middle of it.
Terraform or Bicep?
Either, and we will say which we think fits. Bicep is a reasonable choice for an Azure-only estate with a Microsoft-centric team; Terraform wins as soon as a second provider or a broader toolchain is in play. What matters is that one of them describes the whole estate.
Can you take over an estate somebody else built?
Yes, and it is the normal case. An undocumented tenant is the engagement, not a reason to be embarrassed.
Will we be locked in?
Your repositories, your subscriptions, your tenant — documented and reproducible. Nothing we build depends on us still being here.
Talk to an Azure engineer
Not a salesperson. You will get a read on your estate, the specific risks in it, and what the work would involve.
- A written picture of what is actually running, and what state it is in
- The risks in priority order — dangerous, expensive, and can wait
- What the work would involve, and in what sequence
- Everything delivered into your own repositories and cloud accounts