Skip to content
status: steady

Microsoft Azure Consulting

Most Azure environments were never designed; they accumulated. A subscription per project, Owner handed to whoever asked, resources clicked together in the portal. Eventually the tenant is something everyone depends on and nobody would claim to understand.

Our Azure work usually starts in the middle of that story: a migration stalled at the file servers, a tenant where each subscription's name tells you which year it was created, RBAC granted person by person until the access model stopped matching the org chart. We put structure under it. Resources defined in Bicep or Terraform, access through groups, Azure Policy doing the nagging so a human doesn't have to.

A lot of this work lives in the awkward middle where Microsoft estates sit: hybrid identity, half-migrated file servers, the SQL Server that turned out to be load-bearing. We plan for that middle deliberately rather than pretending the end state arrives on schedule.

Who this is for

  • Microsoft shops moving on-prem workloads to Azure, with Active Directory and file servers complicating every step
  • Teams with a pile of ad hoc subscriptions, no management group structure, and RBAC assigned to individuals
  • Product companies that clicked their first environments together in the portal and now need them reproducible
  • Engineering managers with an Azure bill that grows every month and no way to tie it to teams or products
  • Anyone whose entire Azure knowledge sits in one person's head, and that person is leaving

Structure a small team can hold

Most tenant problems trace back to topology: subscriptions created ad hoc, policy applied nowhere, access granted person by person. We put the minimum structure under it that makes cost, policy, and access boundaries line up with how your teams work.

tenant rootmg: platformmg: workloadssub: connectivity + identitysub: prodsub: non-prodpolicy assigned at the group · RBAC through Entra groups · budgets per subscription
The amount of structure a small team can maintain. Not the forty-group enterprise reference.

Azure work we take on

01

Architecture consulting

Subscription topology is the decision that haunts you later. We design management groups, subscriptions, and resource groups so billing, policy, and access boundaries line up with how your teams work. We will also tell you when the unglamorous answer is right: App Service and Azure SQL cover more ground than most teams admit, and AKS is a commitment, not a default.

02

Infrastructure setup

New environments start as code, not portal clicks: a landing zone sized to your company rather than the full enterprise-scale reference, Entra ID groups instead of one-off role assignments, Azure Policy keeping names, tags, and regions honest. A ten-person team does not need forty management groups. We build the amount of structure you will maintain.

03

Migration

Moving from on-prem is rarely just a compute move; identity and data are the hard parts. We plan the hybrid period deliberately, because most estates live in it longer than intended: Entra Connect, DNS, private connectivity over ExpressRoute or VPN. SQL Server gets its own assessment, since Managed Instance, SQL Database, and SQL on a VM are genuinely different answers with different failure modes.

04

Infrastructure review

We take Reader on the subscriptions in scope and map what exists: resource groups nobody owns, disks orphaned by deleted VMs, the storage account made public in 2021 for a demo. You get a clear picture of the estate and a short list of fixes ordered by risk, sized so your team can schedule them.

05

Security review

Azure security problems are usually identity problems. We review Entra ID and RBAC: Owner grants that outlived their reason, service principals with secrets set to never expire, the places where a managed identity should exist and doesn't. Then network exposure, public storage accounts, and Defender for Cloud, whose findings are useful once someone separates real risk from noise.

06

Cost optimization

Cost work stands on its own as an engagement; you don't need anything else from us to book it. We go through Cost Management line by line: VMs that should be reserved or simply off, premium disks under dev boxes, Log Analytics ingesting gigabytes nobody queries, environments running all weekend for no one. Then budgets, alerts, and tagging, so the picture stays visible after we leave.

07

Infrastructure automation

Portal-built infrastructure makes every change a small act of courage. We move resources under Bicep or Terraform and run deployments through Azure DevOps or GitHub Actions, so the portal becomes read-only in practice. On the tooling question: if Azure is all you will ever run, Bicep is a fine answer; if a second cloud is plausible or your team already knows Terraform, use Terraform.

08

Performance

Azure performance problems are often tier and quota problems in disguise: an App Service plan one size too small, Azure SQL throttled at its DTU ceiling, a storage account at limits nobody knew it had. We measure first. Scaling up is easy; paying to scale the wrong resource is easier still.

09

Monitoring & observability

Most tenants have either no alerts or three hundred that everyone ignores. We consolidate Log Analytics workspaces, wire Application Insights into the services that matter, and cut the alert rules down to the set that means a human should look now. Ingestion pricing gets attention too, because Azure Monitor can quietly become one of your larger line items.

The course of an engagement

The full engagement model
  1. Read-only first

    We ask for Reader on the subscriptions in scope and map the estate as it runs: management group layout, RBAC, network topology, spend.

  2. A scoped plan

    We agree on one concrete outcome and write down how to get there, including the trade-offs and what we are deliberately leaving alone. If the right answer is a smaller engagement than the one you asked about, that's what we'll propose.

  3. The work, in your tooling

    Changes go through your repos and your pipelines as pull requests your team reviews. Nothing is clicked into production, and nothing lives in a consultant's private tenant.

  4. Handover

    We finish with documentation that matches the tenant, runbooks for the failure modes we know about, and a walkthrough of everything we changed.

Questions we get

What access do you need to our tenant?
We start with Reader, granted through Privileged Identity Management so it is time-bound and logged. A PIM-eligible Reader assignment at subscription or management-group scope covers most review work; no long-lived credentials, no service principals with standing secrets. When build work follows, changes land as pull requests in your repos, so write access to the tenant itself is rarely needed.
We are half on-premises with Active Directory everywhere. Is that a problem?
No, it is the normal case. Most Azure estates we see are hybrid: AD on-premises, Entra Connect syncing identities, workloads split across both. We work with that reality rather than pushing a cloud-only migration you did not ask for. Understanding your sync topology and trust boundaries comes first, which is exactly what the read-only phase is for.
Bicep or Terraform?
Whichever your team can maintain after we leave. Terraform if you span clouds or already run it elsewhere; Bicep if you are Azure-only and want first-party tooling with no state file to look after. We work in both and have no stake in the argument. If you have existing modules, we extend them rather than proposing a rewrite.
How is Azure work priced?
Fixed-scope for reviews, a weekly rate for build work, and a defined end either way. The longer answer, including what happens when scope moves, is on the How we work page.

Pricing shapes and numbers are on Pricing; NDAs, timezones, and offboarding are on How we work.

What we typically work with

Compute & platformAKS · App Service · Azure Functions · Container Apps · Virtual Machine Scale Sets
Data & storageAzure SQL Database · SQL Managed Instance · Azure Database for PostgreSQL · Cosmos DB · Blob Storage · Azure Cache for Redis
Networking & identityVirtual Networks · Private Endpoints · Application Gateway · Azure Front Door · Azure Firewall · Entra ID · ExpressRoute
Operations & governanceBicep · Terraform · Azure DevOps · GitHub Actions · Azure Monitor · Log Analytics · Application Insights · Azure Policy · Defender for Cloud · Cost Management

When the engagement ends

  • Your subscriptions, your repos, your pipelines. There is no Statvik-hosted tooling and nothing you have to keep paying us for.
  • Handover includes documentation that matches the tenant as it is, plus runbooks for the failure modes we know about.
  • Ongoing help is available if you want it: a retainer, periodic reviews, or nothing at all. Plenty of clients need exactly one engagement, and we tell them so.

Problems this maps to

The migration that stalled in the hybrid middle

The move to Azure started eighteen months ago. Compute went first and went fine. Then came the file servers, the line-of-business app with the vendor agent, and the SQL Server nobody fully owns, and the migration quietly stopped. Two estates now run in parallel, each billed in full, and every change has to be made twice.

Field notes on this

Talk to us about your tenant.

A short email about your setup and what's not working is the best start. We'll say plainly whether we can help, and what it would take.

hello@farzanfa.com · +91 88918 87223 · Kerala, India · working worldwide · reply within one business day