For teams already living in Microsoft 365, not starting from zero

Azure Cloud

Azure rarely arrives on a blank estate; Microsoft 365, Entra ID and existing licensing are already there before the first subscription opens. This practice builds the tenant around that estate rather than beside it, so identity, policy and cost stay coherent as more of the organisation joins.

Talk to UsScope the Work
AI augmented, human governedEvidence before estimatesYour IP from day oneOne accountable owner per engagementFounded in 2011. Part of the Vinove Group500+ full-time engineers, as of September 2026NASSCOM member
Watch · the 90-second brief

How an Azure tenant decision actually gets made

Subscription hierarchy, identity federation and the governance a growing tenant needs.

90 secWatch without filling in a form.
An Azure tenant and subscription hierarchy under review.90 secSample frame · video pending

01Before a second subscription opens

Governance is cheaper before sprawl than after it

One ungoverned subscription is forgivable. Ten, each with its own naming and access rules, is not. Four questions settle how much structure the tenant needs now.

How many subscriptions does governance actually require?

Environment and business-unit splits usually drive the count more than headcount does. A single small team rarely needs more than two.

Does the workload need Entra ID integration from day one?

Anything customer-facing that touches identity should federate early. Retrofitting single sign-on onto a live application is riskier than building it in.

Which compute service fits the team's operational appetite?

App Service suits teams wanting less to manage. AKS suits teams already comfortable running Kubernetes and wanting full control.

What does your existing Microsoft licensing already cover?

Enterprise Agreements often include capacity nobody is using. Checking that before buying new commitments avoids paying twice for the same seat.

Azure App Service against Azure Kubernetes Service
App ServiceAKS
Control modelManaged platform, less to configureFull Kubernetes API, more control
Operational loadLow, updates handled for youHigher, cluster upgrades are yours
Team fitTeams wanting to ship quicklyTeams already running Kubernetes elsewhere
PortabilityTied to Azure's platformPortable to other Kubernetes clusters
Best forWeb apps and APIsComplex, container-native workloads

02Agreed before rollout starts

The ledger that keeps Azure work honest

Every Azure engagement fixes what you bring, what changes, what returns, and what never moves out of your control regardless of the tenant shape chosen.

  1. Your side

    You bring

    • The business units and environments Azure needs to serve
    • Any existing Microsoft 365 or on-premises Active Directory
    • Budget range and the rollout timeline
  2. Our side

    We build

    • A management group and subscription hierarchy by unit and environment
    • Azure Policy guardrails applied at the right scope
    • A naming and tagging convention the whole tenant follows
  3. Your side

    You receive

    • A documented tenant structure your team can extend
    • Policy assignments enforcing the guardrails agreed
    • An onboarding path for the next subscription

Never leaves you

  • The Microsoft licensing relationship and its renewal terms
  • Final approval over every policy and management group
  • Ownership of every subscription inside the tenant

Where the line sitsWe design the tenant boundary. The Microsoft relationship and every policy decision stay yours to approve.

03From tenant model to first workload

Four stages, each closing on something you can inspect

Azure engagements drift when identity decisions get made informally after subscriptions already exist. Each stage in this system closes on an artefact ready for the next one.

  1. Model the tenant boundary

    Management groups, subscriptions and naming conventions are chosen against your actual business units, not a generic enterprise template.

    A tenant structure with reasons attached

  2. Federate Entra ID deliberately

    Conditional access and single sign-on are built against your real risk profile, not copied from a default security baseline.

    Identity wired into the estate

  3. Roll out policy without breaking access

    Each policy wave is tested against existing workloads before it applies tenant-wide, so nobody loses access mid-rollout.

    Governance applied in ordered waves

  4. Hand over the operating model

    Runbooks, policy documentation and the subscription onboarding path move to your team, so growth after handover needs no further calls.

    A system your admins can operate

04What actually drives the number

Four drivers, not a flat rate card

Azure work is priced against the assessment, not a template, because these four factors change effort by multiples.

Driver 01

Subscriptions and management groups already in play

A greenfield tenant is faster to structure than one with a dozen subscriptions built by different teams over time.

Driver 02

Depth of Entra ID and Microsoft 365 integration

Basic single sign-on costs less than hybrid identity federation across on-premises Active Directory and multiple applications.

Driver 03

Governance and policy remediation scope

A tenant with existing policy conflicts takes longer to clean up than one being governed from its first subscription.

Driver 04

Existing licensing and reservation commitments

Enterprise Agreement terms and reserved capacity already purchased change which architecture is cheapest to run today.

05Evidence and proof

Tenants that survived their own audit.

Azure proof here is a tenant an auditor and an admin can both make sense of. Every record waits for written client approval before production.

Explore case studies
An Entra ID conditional access policy under audit review.
Koru Health · Healthcare product, US

A patient records platform passed audit on its first Azure review.

Koru Health needed Entra ID federation that satisfied a healthcare auditor before launch. Conditional access and logging were proven against the audit checklist before go-live.

Audit findings on first review
Zero
Time to federation sign-off
Five weeks
Sample · pending client approval
A management group hierarchy governing nineteen Azure subscriptions.
Pillar Learning · EdTech, US

Nineteen subscriptions were governed without a single outage.

Pillar Learning had grown into a tangle of subscriptions with inconsistent access rules. A management group rollout brought policy in without interrupting any live course platform.

Subscriptions brought under governance
19
Service interruptions during rollout
Zero
Sample · pending client approval
Portrait of a VP of product reviewing an Azure governance report.

Our own IT team could explain the tenant structure to auditors afterward. That handover mattered more to us than the build itself.

Anika RaoVP Product, Koru Health
Sample · pending client approval

06Read this first

When Azure engineering is the wrong spend

Paying for a tenant redesign when one small team runs one workload would cost more than it returns. The exits are marked before the pitch. When the work is justified, it runs against Entra ID, management groups, Azure Policy, App Service and AKS.

  • You run one workload for one small team

    A single subscription with light governance may already cover it. Tenant-wide structure solves a scale problem you may not have yet.

  • The need is broader platform flexibility

    When workload portability across clouds matters more than depth on Microsoft's stack, a platform-agnostic route fits better than an Azure-only build.

    Kubernetes practice

  • Your own engineers already run Azure well

    If your team already owns Azure architecture and just needs more hands, hiring Azure developers fits better than adding a delivery layer.

    Hire Azure Developers
Engagement shapes for Azure work
ShapeBest whenYou directWe carry
Scoped buildThe tenant model is settledPriorities and rollout orderGovernance and integration delivery
Delivery podThe model will evolve with learningProduct decisions each cycleEngineering, quality, releases
Team extensionYour leads already run Azure wellArchitecture and standardsNamed engineers and continuity

07Straight answers

Asked before an Azure rollout begins.

Not answered here?

Ask us directly Or scope the work first
How is this different from general DevOps consulting?

This practice engineers the Azure tenant itself: subscriptions, Entra ID, policy and licensing. DevOps consulting builds the pipelines and release practice that run on top of whatever tenant already exists.

Do you integrate Azure with an existing Active Directory?

Yes, through hybrid identity federation sized to your actual directory structure. The goal is one coherent identity model, not two directories that quietly drift apart over time.

How many subscriptions should a growing company run?

Usually split by environment and business unit rather than by a fixed number. The right count depends on how many teams need isolated billing and access, not a rule of thumb.

Can you take over an Azure tenant another vendor configured?

Yes, starting with a governance and identity review rather than a rebuild pitch. Many inherited tenants need policy and access cleanup, not a full redesign from scratch.

What does Azure consulting cost?

Scoped engagements are priced against subscription count, identity complexity and governance scope uncovered during assessment. A monthly delivery commitment then carries the work through rollout.

Do you also work with our existing Microsoft licensing?

We check what an Enterprise Agreement already covers before recommending new spend, though the purchase and renewal decision stays with whoever owns that relationship.

Will this lock us out of also using AWS or GCP?

No. A well-governed Azure tenant does not prevent a later multi-cloud decision, though depth on one provider first is usually the more defensible order.