Windows and .NET estates
Existing Windows Server and .NET workloads, where licensing treatment, Active Directory integration and platform familiarity all point the same way.
Microsoft Azure consulting and architecture
Azure is frequently the right answer for organisations already running Microsoft identity and productivity platforms, and frequently chosen for that reason rather than assessed. We do both — and we earn nothing either way.
Overview
Azure's distinguishing characteristic in enterprise estates is integration with the Microsoft platform an organisation is usually already running. Where identity lives in Entra ID and productivity runs on Microsoft 365, Azure inherits an identity model, a compliance position and a commercial relationship that a different provider would have to rebuild.
That advantage is real and it is also how Azure gets chosen without being assessed. The workloads where it is genuinely strongest — Windows and .NET estates, hybrid connectivity to on-premises infrastructure, identity-centric architecture — are not every workload, and the incumbency argument does not extend to all of them automatically.
We design Azure estates and we say when Azure is the wrong choice. Since we hold no Microsoft partnership and take no commission, both statements cost us the same.
Enterprise use cases
Where we see this used to good effect, and what makes each case a fit.
Identity-centred architecture
Where Entra ID is already the organisational identity provider and extending it to workload identity and conditional access is the natural next step.
Hybrid estates
Organisations that will retain significant on-premises infrastructure for years, where hybrid connectivity and consistent management genuinely matter.
Regulated workloads with regional requirements
Where data residency must be demonstrable and regional capacity plus documented compliance positions are decisive.
Enterprise data platforms
Analytical estates built around SQL Server heritage, where the migration path and the skills already present reduce risk materially.
Line-of-business application hosting
The long tail of internal applications, where managed platform services remove operational work the organisation should not be doing.
Architecture
The decision that shapes an Azure estate more than any other is the subscription and management group structure. It determines how policy is inherited, how cost is attributed and how workloads are isolated, and it is genuinely awkward to change once workloads are running.
The second is networking. Hub-and-spoke topology, private endpoints and egress control are decisions taken early that constrain everything afterwards, and retrofitting private connectivity into an estate built without it is substantially more expensive than designing it in.
- Management group and subscription structure designed before workloads land
- Landing zone with policy, networking and identity applied automatically
- Private connectivity and egress control decided early, not retrofitted
- Region and availability zone strategy derived from stated recovery objectives
Best practices
The practices that separate Azure estates which stay manageable from those that do not are unremarkable and consistently skipped: everything defined in code, policy applied at the management group rather than per resource, and tagging enforced at creation rather than reported on afterwards.
The one most often skipped is naming and tagging discipline. It appears trivial until cost attribution, security review or an incident requires knowing what a resource is for and who owns it — at which point the answer is a spreadsheet nobody maintains.
- Infrastructure defined in code, with drift detected rather than assumed absent
- Azure Policy applied at management group level, not per subscription by hand
- Tagging enforced at creation so cost and ownership are answerable
- Managed identities in place of secrets wherever the service supports them
Security
Azure's security posture is dominated by identity. Entra ID is the control plane, and over-permissive role assignments — particularly at subscription scope — are the most common serious finding we see.
The second is network exposure. Services default to public endpoints in several cases, and an estate built without a deliberate position on private connectivity accumulates internet-reachable resources nobody intended to expose.
- Role assignments scoped to resource groups rather than subscriptions by default
- Privileged Identity Management for standing administrative access
- Private endpoints and disabled public network access as the default posture
- Defender for Cloud findings triaged by exploitability rather than by severity alone
Scalability
Azure scales well when the architecture permits it, which is a different statement from the platform scaling. Stateless services, externalised session and a data tier that is not the constraint are properties of your design rather than of the provider.
Subscription and service quotas are the practical limit most organisations meet first, and they are per-region and per-subscription rather than global. Discovering that during a peak is avoidable by checking it during design.
- Horizontal scale verified by load test rather than assumed from the platform
- Quotas and limits checked per region and subscription during design
- The data tier assessed as the real constraint before application tuning
- Autoscale rules based on the signal that predicts load, not on CPU by default
Performance
Most Azure performance problems we investigate are architectural rather than platform-related: a chatty call pattern across a network boundary, a database tier under-provisioned relative to the application, or a cross-region hop nobody intended.
Service tier selection is the second cause. Several Azure services have tiers whose limits are not obvious until they bind, and the symptom is throttling that presents as intermittent application slowness rather than as an explicit error.
- Call patterns across network boundaries reviewed before capacity is increased
- Service tier limits understood, because throttling presents as slowness
- Data locality checked, since a cross-region hop is invisible in code
- Caching designed as architecture rather than added as a remedy
Integration
Azure integrates naturally with the rest of the Microsoft estate, which is its principal advantage and occasionally a trap: the easy path is not always the appropriate one, and coupling an application to a productivity platform can be difficult to unpick later.
For enterprise integration, the significant choices are between managed integration services and self-operated messaging. Both work; the difference is where the operational burden sits and how portable the result is.
- Managed versus self-operated integration decided on operational burden and portability
- Hybrid connectivity to on-premises designed rather than accumulated
- Event and messaging semantics stated: ordering, delivery and idempotency
- Coupling to productivity platforms treated as a decision with a switching cost
Operations
Azure operations are dominated by two things: what you monitor and what you spend. Azure Monitor and Log Analytics can ingest almost everything, and unconsidered ingestion is a common and avoidable line item.
The second is patching and lifecycle. Managed services move you off much of that burden, but retirement notices for platform versions arrive on Microsoft's schedule rather than yours, and an estate without an owner for those notices ends up doing forced upgrades under time pressure.
- Log ingestion and retention designed against investigation need and cost
- Alerting tied to business impact rather than resource utilisation
- Platform retirement notices given a named owner and a tracked backlog
- Cost allocation by tag and subscription, reviewed rather than merely reported
Governance
Governance on Azure works best as guardrails rather than as review. Policy that prevents a misconfiguration at creation is worth considerably more than a report identifying it afterwards, and it does not consume anyone's time per change.
Cost governance needs the same treatment. Budgets and alerts detect overspend after it has happened; policy restricting resource types, regions and sizes prevents a category of it entirely.
- Preventive policy at management group level rather than detective reporting
- Allowed regions, resource types and sizes constrained by policy
- Budgets and anomaly alerts with a named owner per subscription
- Exception path documented, because an unusable policy set gets disabled
Recommended industries
Sectors where this comes up most often, and the constraint that puts it there.
Industry
Healthcare
Interoperability between clinical systems, patient data privacy, and legacy platforms that cannot be taken offline.
IndustryBanking & Financial Services
Core system modernisation, real-time payment flows, and architecture that can evidence regulatory controls.
IndustryEducation
Student information systems, hybrid delivery platforms and sharply seasonal load.
IndustryGovernment & Public Sector
Procurement constraints, data residency, accessibility obligations and long-lived legacy estates.
IndustryManufacturing
Operational technology meeting information technology, supply chain visibility, and ERP estates grown by accretion.
IndustryEnergy & Utilities
Grid and asset telemetry, regulatory reporting, and operational systems that cannot tolerate an outage window.
Related services
The engagements this work is usually delivered within.
Cloud Consulting
Migration strategy, landing-zone design, cost modelling and the architecture decisions that determine whether cloud spend buys capability.
Enterprise Architecture
Target-state design, modernisation roadmaps, integration and cloud architecture, and the governance that keeps decisions consistent after the consultants leave.
Cybersecurity
Security architecture, assessment and compliance advisory, designed in rather than reviewed afterwards.
DevOps & Platform Engineering
Delivery pipelines, infrastructure as code, Kubernetes and the observability practices that make releases routine.
AI & Data Engineering
Data architecture, platform modernisation, integration and analytics — the foundations that have to exist before AI is a sensible conversation.
Managed IT Services
Application support, infrastructure management and incident response under defined service levels.
Frequently asked questions
It frequently is where Entra ID is already your identity provider, where you run Windows and .NET workloads, or where a substantial on-premises estate will remain for years. It is chosen for those reasons more often than it is assessed against them, and the two are not the same thing.
No. We hold no partnership with Microsoft or any other vendor, resell nothing and take no commission. Recommending against Azure costs us exactly what recommending it does, which is the point.
It is the subscription structure, networking, identity model and policy baseline that workloads land into. You need one if more than a couple of teams will deploy to Azure, because the alternative is each team making these decisions independently — and those decisions are the hardest to change later.
With allocation, so consumption has an owner. Until tagging is enforced at creation and cost is attributable to a team, optimisation is guesswork. After that the usual causes are non-production environments running continuously, over-provisioned database tiers and unconsidered log ingestion.
By isolation boundary and policy inheritance rather than by team convenience. Management groups carry the policy, subscriptions carry the isolation and the cost boundary, and both are awkward to restructure once workloads run in them — which is why it is worth doing deliberately at the start.
Yes, wherever the service supports them. They remove a class of problem entirely: static credentials that are stored somewhere, rotated rarely and occasionally committed to source control. It is one of the few security improvements that also reduces operational work.
As a default posture, yes, with deliberate exceptions. Several Azure services expose public endpoints by default, and an estate without a stated position accumulates internet-reachable resources nobody decided to expose. Retrofitting private connectivity later is materially more expensive.
Yes, and for many organisations a deliberate hybrid position is the correct destination rather than an unfinished migration. Azure is unusually good at this case. What matters is that it is chosen rather than arrived at by a migration that stalled.
Usually a chatty call pattern across a network boundary or service tier throttling, which presents as intermittent slowness rather than as an error. Adding capacity to either of those changes very little, which is why the investigation should precede the spend.
By giving retirement notices a named owner and a tracked backlog. They arrive on Microsoft's schedule rather than yours, and an estate without an owner for them ends up doing forced upgrades under time pressure — which is the most expensive way to do them.
Next step
Discuss an Azure architecture
A free first consultation covering your estate, your identity position and whether Azure is genuinely the right platform for the workloads you have in mind — from a party with no commercial interest in the answer.
No cost, no obligation. Pricing is transparent and includes GST.