First page of Microsoft's 100,000-partner directory, sorted by responsiveness Microsoft Solutions Partner — Security, Modern Work, Infrastructure, App Innovation Microsoft partner since 2006 1,100+ organizations under management
Home/Services/Azure Local (formerly Azure Stack HCI) Design and Deployment
Implementation

Azure Local (formerly Azure Stack HCI) Design and Deployment

IT Partner designs and deploys Azure Local — the platform Microsoft renamed from Azure Stack HCI at Ignite in November 2024 — for mid-size and enterprise organizations that need compute to stay on their own premises for latency, data sovereignty or regulation, but want it run from the Azure control plane. The engagement covers capacity sizing and the selection of validated hardware from the Azure Local catalog (you buy it from your OEM), network and storage design, Active Directory or local-identity preparation, Azure Arc registration and the cloud deployment from the Azure portal, Azure Local VM management through Arc, optional Azure Virtual Desktop and AKS, migration of your Hyper-V or VMware virtual machines into the new instance, and an operations handover your team runs the platform from. Projects are quoted per estate — one written fixed price per instance and site after a scoping call, starting from $9,500 — and a single-instance deployment typically runs about six weeks once the hardware is racked, managed by Roman Sotnik. The hardware, Microsoft's per-physical-core Azure Local subscription and any Azure services you attach are your own purchases, billed by your OEM and by Microsoft, and are not part of our fee.

Timeline 6 weeksService owner Roman SotnikMicrosoft AzureAzure LocalAzure Arc

What this engagement is

Three kinds of estates arrive at this page. The first is a Hyper-V cluster on Windows Server 2016 hosts — extended support ends on 12 January 2027 per Microsoft's product lifecycle, and the 2012 R2 hosts still behind it lose Extended Security Updates on 13 October 2026 — where the hardware is due anyway and nobody wants to hand-build another failover cluster. The second is a VMware estate facing a renewal after Broadcom's licensing changes, with a board asking why the hypervisor bill climbed for software that runs Windows VMs. The third was never a cloud candidate: a plant floor or clinical system that cannot tolerate WAN latency, a data set that regulation keeps on the premises, a site with thin or intermittent connectivity, or an estate whose auditors want the data on one side of a sovereignty line and the control plane on the other. All three want the same thing — Microsoft's hypervisor, storage and networking stack on hardware they own, managed from the Azure portal like everything else — and that is what Azure Local is. Azure Local is Microsoft's Azure Arc-enabled infrastructure platform: Hyper-V, Storage Spaces Direct (or, in a disaggregated design, an external SAN), software-defined networking, and an Azure-delivered operating system that Microsoft updates as one solution on a monthly release train — release 2608 is current at the time of writing, and since release 2504 every new deployment runs the 26100 build line, the same OS generation as Windows Server 2025. The instance registers with Azure Arc, so its VMs, Kubernetes clusters, updates, monitoring and policy live in Azure Resource Manager alongside your cloud subscriptions. Microsoft bills it per physical core per month to your Azure subscription, and supports it only on hardware in the Azure Local catalog — validated nodes, integrated systems and Premier Solutions from Dell, HPE, Lenovo and other OEMs — which you buy from the OEM against the bill of materials we specify. We start with an honest platform decision, because Azure Local is not the answer for every estate. If the workloads can simply move to Azure, we say so and route you to the migration pages. If you hold Windows Server Datacenter licences with Software Assurance and have no appetite for a cloud control plane, a Windows Server 2025 failover cluster is a legitimate alternative and we scope that instead. If the driver is a VMware renewal, the design document sets out per workload whether Azure Local, Azure or retirement is the cheaper home. Once Azure Local is the answer, the design covers the things that are expensive to change after the first VM lands: capacity in cores, memory and usable storage after resiliency overhead; machine count and topology — a single machine, a two-machine switchless instance with a cloud witness, a three- or four-machine switchless instance, or a switched hyperconverged instance of up to sixteen machines, with rack-aware and disaggregated SAN designs for larger footprints; the Network ATC intents for management, compute and storage, with RDMA storage networking at 10 GbE minimum and 25 GbE or better recommended, two storage VLANs, jumbo frames and a management subnet with the contiguous addresses the deployment needs; identity — the Active Directory organizational unit and deployment account the instance is joined with, or the local identity with Azure Key Vault option Microsoft made generally available in release 2604 for sites that do not want a domain-joined platform; the Azure side — subscription, region, resource group, the Key Vault that holds deployment secrets, the witness storage account and the roles the deployment identity needs; outbound connectivity, with Azure Arc gateway to shorten the list of endpoints your firewall must allow; and the security posture the platform applies by default — TPM 2.0, Secure Boot, BitLocker and Microsoft's hardened baseline — with the exceptions your applications force written down rather than assumed. Then we deploy: the operating system installed on each machine, every machine registered with Azure Arc, Microsoft's environment checker run until it is clean, and the instance created from the Azure portal or an ARM template and validated against the design before the first workload arrives. Post-deployment we stand up Azure Local VM management through Arc — custom location, logical networks, an image library, VMs created from the portal, CLI or templates — connect Azure Update Manager for solution updates, wire Azure Monitor Insights and alerting, and enable Defender for Cloud where the design calls for it. The migration wave moves your VMs in: Microsoft's Azure Migrate path for VMware sources is generally available, Azure Migrate for Hyper-V sources is in preview at the time of writing, and we choose per VM between Azure Migrate, a controlled export-and-import of virtual disks, or a rebuild — with test migrations, a cutover runbook and rollback for each wave. Optional Azure Virtual Desktop session hosts and AKS clusters on the instance are designed and deployed as scoped add-ons. We hand over with an as-built document, an operations runbook and a recorded walkthrough that your team — or our managed service — runs the platform from. Hardware procurement is yours, ongoing operations after handover are a separate engagement, and moving workloads to the public cloud is its own page.

Success criteria

01The Azure Local design document — platform decision, capacity model, machine count and topology, network intents and VLAN plan, identity model, Azure resources and roles, security exceptions and migration waves — is approved in writing before hardware is ordered.
02The bill-of-materials brief matches a configuration in the Azure Local catalog, and the delivered hardware passes Microsoft's environment checker with no unresolved blockers before deployment starts.
03The instance is deployed from the Azure portal or an ARM template to the approved design, reports healthy in the Azure portal, and its machines, storage pool and logical networks match the as-built document.
04Azure Local VM management works end to end: a VM created from the Azure portal on the agreed logical network boots, is reachable, and is patched and monitored through the Azure tooling in the design.
05Every in-scope VM has been migrated in its planned wave, tested by its application owner and signed off, with the source VM retained for the agreed period before deletion.
06Solution updates, monitoring alerts, backup and the operations runbook have been demonstrated to your team in a recorded handover session, and acceptance has been signed.

What you receive

Azure Local design document: the platform decision (Azure Local, Azure or a Windows Server 2025 cluster — per workload where they differ), capacity model with resiliency overhead, machine count and topology, network design (Network ATC intents, VLANs, IP plan, RDMA settings and switch requirements), identity model, Azure resources and role assignments, security baseline exceptions, and a monthly cost model for Microsoft's Azure Local subscription, the Windows Server guest-licensing option and attached Azure services, built from Microsoft's published pricing.
Bill-of-materials brief for your OEM: the catalog configuration, per-machine CPU, memory, boot and data-drive layout, network adapters, and the firmware and driver baseline the OEM must ship — so quotes from Dell, HPE, Lenovo or another catalog vendor are comparable.
Site readiness checklist: rack, power and cooling assumptions, top-of-rack switch configuration (VLANs, jumbo frames, and the data-center-bridging settings RDMA needs where applicable), management subnet and DNS entries, firewall rules or Azure Arc gateway configuration, and the Active Directory organizational unit and deployment account — or the local-identity Key Vault setup.
Azure foundation for the instance: subscription and resource-group placement (a spoke in your landing zone where one exists), Key Vault, witness storage account, custom location, logical networks, and Azure RBAC assignments for platform operators and VM operators.
A deployed Azure Local instance: operating system installed, machines registered with Azure Arc, environment checker clean, cloud deployment completed and validated, solution updates connected to Azure Update Manager, Azure Monitor Insights and alert rules routed to your channel, and Microsoft Defender for Cloud enabled where agreed.
Azure Local VM management: image library, VM templates for your standard builds, guest management enabled for in-guest Azure extensions, and Windows Server guest licensing set up under the option you chose — Azure Hybrid Benefit for existing Datacenter licences with Software Assurance, or the per-core Windows Server subscription add-on.
VM migration: wave plan, Azure Migrate source and target appliances (VMware sources; Hyper-V sources where the preview is acceptable to you) or a scripted disk export-and-import, test migrations per wave, cutover runbooks with rollback, and a post-migration validation record per VM.
Optional, scoped in the same quote when you want them: Azure Virtual Desktop session hosts on the instance, and an AKS cluster enabled by Azure Arc on the instance.
Operations handover: as-built document, runbook (solution updates and maintenance windows, adding or replacing a machine, storage health, VM lifecycle, backup and restore, monitoring triage, cost levers), and a recorded walkthrough for the team that will run the platform.

How the work unfolds

Discovery and platform decision (week 1)

Inventory of hosts, VMs, cores, memory, storage and network from your Hyper-V or vCenter environment; workload requirements — latency, residency, attached hardware, licensing anchors; your Windows Server licensing position; and the connectivity and Azure foundation you already have. Output is the design outline with the honest recommendation per workload: Azure Local, Azure, a Windows Server 2025 cluster, or retirement.

Design and bill of materials (weeks 1–2)

The design document — capacity, machine count and topology, network intents and VLANs, identity, Azure resources, security exceptions, cost model and migration waves — which you approve in writing, and the bill-of-materials brief you take to your OEM. OEM lead time runs from here and sits outside the six weeks; the deployment weeks below start when the machines are racked and powered.

Site and Azure preparation (weeks 2–3, in parallel with hardware lead time)

Switch configuration to the design validated with your network team, Active Directory organizational unit and deployment account (or local identity with Key Vault), DNS entries, firewall rules or Azure Arc gateway, and the Azure side — subscription placement, resource group, Key Vault, witness storage account and role assignments.

Deployment (weeks 3–4)

Operating system installed on every machine, each machine registered with Azure Arc, Microsoft's environment checker run and every finding closed, the instance deployed from the Azure portal or an ARM template, and post-deployment validation — storage pool, networks, witness, update readiness — recorded against the design.

Platform services (week 4)

Azure Local VM management stood up — custom location, logical networks, image library, VM templates, guest management — with Azure Update Manager, Azure Monitor Insights and alerting, Defender for Cloud where agreed, the backup configuration in the design, and Windows Server guest licensing under your chosen option. Optional Azure Virtual Desktop or AKS add-ons are built here when in scope.

Migration waves (weeks 4–6)

A pilot wave first — a handful of low-risk VMs through Azure Migrate or disk export-and-import, test-migrated, cut over, validated by their owners — then production waves on the agreed schedule, each with a cutover runbook, rollback and a per-VM validation record. Source VMs are retained for the agreed period before deletion.

Handover (week 6)

As-built document and operations runbook delivered, recorded walkthrough for your platform team, open items closed, temporary access removed, and acceptance signed. Ongoing operations continue with your team from the runbook or under a separate managed-service engagement.

Prerequisites

Hardware from the Azure Local catalog, purchased by you from your OEM against our bill-of-materials brief and racked, cabled and powered before the deployment weeks begin — Microsoft supports Azure Local only on catalog hardware, and every machine in an instance must match.
An Azure subscription — pay-as-you-go, Enterprise Agreement or CSP (we can provision an Azure plan through our CSP) — in a region that supports Azure Local, with Contributor and User Access Administrator rights for the deployment, or approval for IT Partner to work under least-privilege, time-bound access you revoke at handover.
Active Directory Domain Services reachable from the site, with rights to create an organizational unit and a deployment account, or a decision to deploy with local identity and Azure Key Vault instead.
Outbound HTTPS connectivity from the management network to Azure — directly, through a proxy, or through Azure Arc gateway — and a network team able to configure the top-of-rack switches to the design (VLANs, jumbo frames and RDMA settings).
An inventory of the VMs to migrate with application owners who can test them, and administrative access to the source Hyper-V hosts or vCenter.
Your Windows Server licensing position — Datacenter licences with active Software Assurance for Azure Hybrid Benefit, or a decision to use the Windows Server subscription add-on — plus any SQL Server or third-party licences the migrated VMs carry; the Microsoft Volume Licensing page covers the licensing questions this raises.
A named platform owner who attends the design reviews and the handover, and timely approvals on the design document and each cutover window.

Who does what

IT Partner

  • Lead discovery, make the platform recommendation honestly, and produce the design document, cost model and bill-of-materials brief.
  • Prepare the Azure side, validate site readiness, and deploy the instance to the approved design from the Azure portal or an ARM template.
  • Stand up VM management, solution updates, monitoring, and the agreed security and backup configuration.
  • Plan and execute the migration waves with test migrations, cutover runbooks and rollback, and record per-VM validation.
  • Deliver the as-built document, runbook and recorded handover; raise risks, scope changes and platform constraints as soon as they are found; and remove any temporary access we were granted.

Your team

  • Procure the hardware from your OEM against the brief, and provide rack, power, cooling and switch configuration to the design.
  • Provide Azure, Active Directory, network and source-hypervisor access, and make design decisions when options are presented.
  • Own Microsoft's charges: the Azure Local per-core subscription, Windows Server guest licensing, Extended Security Updates where Microsoft charges for them, and any attached Azure services.
  • Supply application owners to test each migrated VM, and approve each cutover window.
  • Operate the platform after handover from the runbook, or contract managed operations separately.

What's not included

Hardware procurement, OEM support contracts, racking, power, cooling and physical cabling. We specify the bill of materials and check what arrives against it; you buy it from the OEM, and the OEM's warranty and firmware support remain yours.
Microsoft's charges — the Azure Local subscription billed per physical core per month, the Windows Server subscription add-on or your own licences, Extended Security Updates where Microsoft charges for them, Azure Virtual Desktop and AKS meters, Defender plans, log ingestion and Azure Migrate charges — are billed by Microsoft to your subscription. The design includes a cost model; Microsoft's meters are the bill of record.
Ongoing operations after handover — solution updates, capacity management, monitoring triage, on-call — which are available as a follow-on through Azure Resource Monitoring and Maintenance; 24/7 coverage is an optional extra-cost add-on.
Migration to the public Azure cloud. Workloads that should leave the building belong to VMware to Azure Virtual Machine Migration, Hyper-V to Azure Virtual Machine Migration or the Azure Migrate Discovery and Assessment front door — and the design document tells you which ones those are.
In-place upgrades of the guest operating systems you migrate. A Windows Server 2016 VM arrives on Azure Local as a Windows Server 2016 VM; upgrading it, or enrolling it in ESU through Azure Arc (Windows Server ESU Enrollment through Azure Arc), is separate work we can quote alongside, and the Windows Server 2016 End of Support Assessment and Roadmap is where an estate-wide disposition starts.
Application-level migration, database re-platforming, and fixes for problems the move reveals in the application itself.
Top-of-rack switch procurement and configuration beyond the design and a validation pass — your network team or vendor configures the switches to our specification; wide-area connectivity to Azure is the Site-to-Site VPN and ExpressRoute engagement where you need it.
Azure landing-zone build-out for the subscriptions the instance registers into — the Azure Landing Zone and Cloud Adoption Framework Implementation — and Azure Arc onboarding of servers that stay outside Azure Local, which is Azure Arc Hybrid Server Management.
Disconnected (air-gapped) operations, multi-rack instances and disaggregated SAN designs are scoped as their own projects: Microsoft ties disconnected operations to Premier Solutions hardware with a dedicated management cluster, and those estates need a design engagement of their own before a quote is honest.
Formal compliance certification and penetration testing — we build to Microsoft's security baseline and can arrange formal testing separately.

Limitations & technical notes

!The price is a floor, not a fixed fee: 'From $9,500' covers the smallest single-instance designs, and the written quote — per instance and per site — follows the scoping call. Machine count, migration wave size, AVD or AKS add-ons, and whether a landing zone and connectivity already exist move the number; per our standard terms the quote is fixed once agreed and you pay after you approve delivery.
!Six weeks is the design-through-migration window for a single instance once the hardware is racked. OEM lead time on catalog hardware runs before the deployment weeks and is outside our control; design and site preparation run during that lead time so deployment starts the day the machines are powered.
!Azure Local runs only on hardware in the Azure Local catalog, and every machine in an instance must match — same model, processors, adapters and drive layout. Reusing an existing server fleet is possible only if it is listed, and we check before you decide.
!Extended Security Updates on Azure Local are Microsoft's and follow Microsoft's April 2026 pricing change: per Microsoft's Azure Local documentation, ESUs for editions that left support before 1 April 2026 — Windows Server 2012 and 2012 R2 among them — remain available at no additional charge on Azure Local through Azure verification for VMs, while ESUs released after that date, including Windows Server 2016, are subject to Microsoft's standardized ESU pricing. Azure Local is a modern home for those VMs, not a way around the Windows Server 2016 ESU bill; we confirm the terms in force during design.
!Microsoft's Azure Migrate path into Azure Local is generally available for VMware sources and in preview for Hyper-V sources at the time of writing; preview features carry no Microsoft SLA, so for Hyper-V estates the design states per VM whether we use the preview, a disk export-and-import, or a rebuild.
!The instance needs outbound connectivity to Azure to deploy, bill and update. Fully disconnected operation is a separate Microsoft configuration on Premier Solutions hardware with its own management cluster and is scoped as its own project; sites with intermittent connectivity are fine within Microsoft's sync grace period, which we confirm in design.
!Machine counts and topologies are Microsoft's limits and move with releases: at the time of writing a hyperconverged instance runs from one to sixteen machines, switchless storage is limited to small instances with no scale-out, and larger footprints need rack-aware, disaggregated or multi-rack designs. The design states the ceiling you are buying into.
!Azure Local is updated by Microsoft on a monthly solution release train and each release is supported for a limited window; staying current is an operating commitment, which the runbook covers and the managed follow-on can carry.
!Microsoft's features, pricing, licensing terms — including Azure Hybrid Benefit and the Windows Server subscription add-on — and regional availability change; the design reflects the platform state at execution time, and this page is not the contract.

Frequently asked questions

What is Azure Local, and what happened to Azure Stack HCI?

Azure Local is the name Microsoft gave Azure Stack HCI at Ignite in November 2024. It is the same product line — Hyper-V, Storage Spaces Direct, software-defined networking and an Azure-delivered operating system on validated hardware you own — now positioned as Microsoft's Azure Arc-enabled infrastructure for on-premises and edge sites. Existing Azure Stack HCI 23H2 instances updated into Azure Local; since release 2504 new deployments run the 26100 build line, the same generation as Windows Server 2025, and the OEM licence formerly called the Azure Stack HCI OEM licence is now the OEM licence for Azure Local. If you are still searching for 'Azure Stack HCI', this is the page.

Azure Local versus Hyper-V on Windows Server — which should we run?

Both use Hyper-V. A Windows Server 2025 Datacenter failover cluster with Storage Spaces Direct is a perpetual licence you patch and operate yourself, managed with Windows Admin Center, Failover Cluster Manager or System Center — a good answer for teams that want no cloud dependency and already own Datacenter licences with Software Assurance. Azure Local is a per-core subscription billed through Azure, with an operating system Microsoft delivers and updates as one solution, VMs and updates managed from the Azure portal through Arc, and platform features a Windows Server cluster does not get — Azure Virtual Desktop session hosts, AKS enabled by Arc, Azure Policy and Defender integration, and the Azure benefits for guest VMs. Choose Azure Local when Azure is already your management plane and you want one way of working across cloud and premises; choose a Windows Server cluster when the site must run with no Azure relationship at all. The design document states the recommendation per estate, and we are comfortable recommending either.

Can Azure Local replace VMware?

For Windows and Linux virtual-machine estates, yes: the hypervisor becomes Hyper-V, vSAN's role is taken by Storage Spaces Direct or an external SAN, NSX-style network virtualization maps to Azure Local's software-defined networking, and Microsoft's Azure Migrate path for VMware sources into Azure Local is generally available — agentless replication with test migrations before cutover. What does not translate one-for-one is the surrounding ecosystem: backup products, monitoring agents, automation and third-party appliances need Hyper-V and Azure Local support, and VMs with hardware pass-through or vendor appliances delivered as OVAs are checked individually. The design document lists every VM with its disposition — migrate, rebuild, move to Azure, or retire — before you sign anything.

Do our Windows Server 2016 and 2012 R2 VMs get Extended Security Updates at no charge on Azure Local?

Only partly, and the difference matters. Per Microsoft's Azure Local documentation, ESUs for editions that left support before 1 April 2026 — Windows Server 2012 and 2012 R2 among them — remain available at no additional charge on Azure Local through Azure verification for VMs; that benefit runs until Windows Server 2012 R2 ESU itself ends on 13 October 2026 per Microsoft's product lifecycle. ESUs released after 1 April 2026, including Windows Server 2016 when its extended support ends on 12 January 2027, fall under Microsoft's standardized ESU pricing, so a 2016 VM on Azure Local is not automatically covered at no charge. Azure Local gives those VMs a supported, current platform to live on while you upgrade or retire them; it is not a way around the 2016 ESU bill, and we confirm the terms in force for your estate during design.

What does Azure Local cost to run once it is deployed?

Three lines, all Microsoft's or your OEM's rather than ours. The Azure Local service itself is billed by Microsoft per physical core per month to your Azure subscription at Microsoft's published rate. Windows Server inside the VMs is licensed either through Azure Hybrid Benefit — Windows Server Datacenter licences with active Software Assurance assigned to the machines, which under Microsoft's current terms can also waive the Azure Local host fee — or through the Windows Server subscription add-on billed per core per month; the design document models both against your licence position. Attached services — Defender for Cloud plans, log ingestion, Azure Virtual Desktop, AKS, Azure Migrate — are metered as they are anywhere in Azure. We deliberately print none of Microsoft's numbers on this page because Microsoft revises them; the cost model in the design carries the current ones.

Which hardware do we need, and can we buy it from you?

Hardware must come from the Azure Local catalog — validated nodes, integrated systems, or Premier Solutions with the OEM's deeper integration — from Dell, HPE, Lenovo and other listed OEMs, and every machine in an instance must match in model, processor, adapters and drive layout. We produce the bill-of-materials brief and check competing OEM quotes against it; you buy from the OEM, and the warranty and firmware support stay with them. Reusing existing servers is possible only if the exact configuration is in the catalog, which we check before you plan on it.

How many machines does an instance need?

One machine is supported and suits an edge site that accepts no host-level resilience. Two machines with a cloud witness in Azure give you host failover in a switchless design. Three or four machines still run switchless storage; beyond that the storage network goes through switches, and a hyperconverged instance scales to sixteen machines at the time of writing, with rack-aware, disaggregated SAN and multi-rack designs for larger footprints. The design sizes the count from your capacity, the resilience you want, and the storage overhead of the mirroring that resilience costs — usable capacity is a fraction of raw, and the model shows exactly which fraction.

Does the site need Active Directory?

Traditionally yes: Azure Local is deployed with an Active Directory organizational unit and a deployment account, and most estates with existing domain controllers deploy that way. Since release 2604 Microsoft also supports local identity with Azure Key Vault as a generally available option, so a site that does not want a domain-joined platform can deploy without Active Directory. We recommend one or the other in the design based on what already runs on the site and what the migrated VMs expect.

Does Azure Local need an internet connection, and can it run air-gapped?

A standard instance needs outbound HTTPS to Azure — directly, through a proxy, or through Azure Arc gateway, which shortens the endpoint list your firewall must allow — to deploy, report billing and receive updates; it keeps running through connectivity gaps within Microsoft's sync grace period. Fully disconnected operation is a distinct Microsoft configuration: it runs on Premier Solutions hardware with a dedicated management cluster that hosts a local Azure control plane, and it is designed and quoted as its own project rather than folded into this page.

How do our existing VMs get onto Azure Local?

Through waves. For VMware sources, Microsoft's Azure Migrate path into Azure Local is generally available: a source appliance on VMware and a target appliance on the instance replicate VMs without agents, and each VM is test-migrated before its cutover. For Hyper-V sources, Azure Migrate is in preview at the time of writing, so the design states per VM whether we use it, export the virtual disks and re-create the VM through Azure Local VM management, or rebuild. Every wave has a cutover runbook, a rollback path and a validation record signed by the application owner, and source VMs stay for the agreed period before deletion.

Can we run Azure Virtual Desktop and AKS on it?

Yes, both are scoped add-ons. Azure Virtual Desktop session hosts can run on Azure Local so users get desktops from the site with the AVD control plane in Azure — useful where the applications or data must stay on the premises; our Azure Virtual Desktop Implementation page describes the host-pool design we bring to it. AKS enabled by Azure Arc runs Kubernetes clusters on the instance, managed from Azure like any other Arc-connected cluster. Each is quoted in the same estate quote when you want it.

Why is the project quoted per estate rather than a fixed price?

Because a two-machine branch instance with ten VMs and a sixteen-machine datacenter consolidation with three hundred VMs, AVD and an AKS cluster are not the same project, and one price would be wrong for both. The scoping call captures machine count, sites, VM count and mix, add-ons, and what foundation already exists; the quote that follows is one written fixed price per instance and site — from $9,500 for the smallest designs — and per our standard terms you pay after you approve delivery.

How long does it take?

About six weeks for a single instance from design through the last migration wave and handover, once the hardware is racked: discovery and design in weeks one to two, site and Azure preparation in parallel with the OEM's lead time, deployment in weeks three to four, platform services in week four, migration waves in weeks four to six, and handover in week six. What stretches it is hardware lead time, a switch change that waits on a change board, or migration waves with many application owners to schedule.

What happens after handover?

Your team runs the platform from the runbook — monthly solution updates, monitoring triage, VM lifecycle, capacity — or we do under Azure Resource Monitoring and Maintenance as a separate engagement. Organizations that buy their Microsoft licensing through IT Partner get unlimited break-fix support during business hours at no extra charge; platform operations are a managed service, not break-fix, and 24/7 coverage is a paid agreement.

Is Azure Local right for a small office?

Usually not. This page is written for mid-size and enterprise estates — sites with dozens to hundreds of VMs, a real reason to keep them on the premises, and an OEM budget for catalog hardware. A ten-person office with a single aging server is nearly always better served by moving its workloads to Azure or Microsoft 365, and we will say so on the scoping call rather than sell you a platform you do not need.

Didn’t find your question?

Ask it here. A real engineer answers by email within one business day — and if it’s a good one, it becomes part of this page so the next person finds it.

Answered by a person, one time, to your inbox. Nothing you type here is published without a human reviewing and anonymizing it first.

Often combined with