Which Windows Server workloads should stay on-premises in 2026?

Keep Windows Server on-premises when being local is part of the requirement, not simply part of the history. A site may need to keep working through a WAN outage; an application may need reliably low latency; or a service may be inseparable from equipment, drivers or software sitting in the building. In those cases, moving it elsewhere can make the service worse.

Everything else deserves a more demanding test. Does cloud delivery genuinely remove operational work, improve recovery and make access easier? Or does it leave the same fragile application in place, now dependent on a circuit, identity chain and monthly bill?

For most organisations, the answer is neither an all-local estate nor a clean sweep into Azure. It is a deliberate hybrid model: keep the small local core that has a proven reason to exist, use cloud services where their operating model is stronger, and manage both with the same discipline. Azure Arc supports that mixed approach for Windows Server through central inventory, policy and update services. Eligible Windows Server 2025 machines can also use Arc-enabled hotpatching, subject to the relevant platform requirements.

Which Windows Server workloads still have a strong case for staying on-premises?

Keep systems local if a site must function through an impaired internet connection. That includes servers controlling production equipment, warehouse or retail systems connected to on-site devices, building-management platforms, local print and scan workflows, and line-of-business software whose users cannot reasonably stop until connectivity returns. A second circuit is worthwhile, but it is not the same thing as designing a site to work autonomously.

Keep a close eye on latency-sensitive and high-volume workloads. Some applications make thousands of small calls between the client, file share and database. Others move large design files, images, video or machine data. Put only one tier in the cloud and a formerly dependable application can become mysteriously slow as chatty traffic crosses the WAN. Measure actual response time, IOPS (input/output operations per second) and throughput. A broadband speed test, or a supplier saying an application is “cloud ready”, is not evidence that the workload will perform well.

Specialist hardware and old software often remain local by necessity rather than preference. A Windows Server instance talking directly to serial devices, dongles, laboratory instruments, CCTV storage, industrial controllers or an unsupported driver stack may be a poor migration candidate. That does not make it a healthy long-term arrangement. The immediate priorities are containment, documented recovery and a replacement plan—not a heroic lift-and-shift.

There is also a valid resilience case for local compute. Microsoft’s documentation for disconnected Azure Local operations describes fully on-premises deployments designed to keep virtual machines, containers and local networking running without Azure or internet connectivity. That is a specialist option, not a general reason to buy hyperconverged infrastructure—systems that combine compute, storage and networking. But it makes the wider point clearly: at some sites, disconnection is an operating condition, not an exceptional disaster.

Should Active Directory domain controllers remain on site?

Usually, yes, where an office, site or facility still depends on traditional Active Directory Domain Services (AD DS) for Windows sign-in, DNS (the Domain Name System), Group Policy, file permissions, Wi-Fi, virtual private network (VPN) access, service accounts or local applications. A pair of properly placed and protected domain controllers gives the site a workable local route for authentication and name resolution when the WAN is unavailable.

That does not mean every domain controller belongs in the same building. An Azure-based replica can improve disaster recovery, and Microsoft supports running AD DS on Azure virtual machines. It still needs proper site design, DNS configuration, connectivity and availability planning. One domain controller in Azure is useful for recovery; it is not a substitute for local resilience.

Microsoft Entra ID is not a drop-in replacement for AD DS. Entra ID is the cloud identity control plane for modern applications and devices, while AD DS is built around domain join, LDAP, Kerberos, NTLM, trusts and Group Policy. Microsoft Entra Domain Services provides a managed subset of those traditional capabilities for Azure workloads, but with different administrative and synchronisation boundaries. Existing on-premises Group Policy objects, in particular, do not simply synchronise into the managed domain.

The practical direction is to stop creating casual new dependencies on AD DS while maintaining it properly for the services that still require it. Challenge new applications that demand LDAP queries, domain service accounts or Windows-integrated authentication before those dependencies become another decade-long migration problem.

Do file servers still belong on-premises?

The useful questions are specific: where will production data, backups and support access reside; what contractual and regulatory obligations apply; can the supplier meet them; and who is responsible for proving it?

Sometimes—especially when people and applications at one location need quick, consistent access to shared files. Computer-aided design (CAD) drawings, media assets, engineering projects and application data held in conventional SMB (Server Message Block) shares can be much happier on local storage than across a WAN. The same is true when a legacy application expects a nearby file path and behaves badly with cloud-storage abstractions.

But the conventional file server is no longer the default answer for ordinary office collaboration. Teams spread across several locations will often be better served by cloud-native collaboration tools or managed file services than by a central Windows share and a growing collection of VPN exceptions.

Azure File Sync is a useful middle ground where SMB compatibility and a local cache both matter. It keeps an Azure file share as the central copy while allowing a Windows Server to retain frequently used content locally. The important limitation is that tiered files may need recalling from Azure when opened. That works only if the connection and recall behaviour suit the job. A local cache is not an offline archive, and it should be tested with the real applications that scan, index or open large numbers of files.

What should usually move to Azure or another cloud platform?

Cloud is usually strongest where a workload is internet-facing, elastic, distributed or disproportionately difficult to run well in a small server room. Development and test environments, temporary project systems, externally accessible web applications, disaster-recovery copies, analytics jobs and services with sharply variable demand are common examples.

The stronger candidates are often the ones that can move beyond a Windows Server virtual machine altogether. A database that fits a managed service, for example, may shed operating-system patching, underlying cluster maintenance and some backup work. That is a real operational change. Running the same SQL Server build on an Azure VM may still be the right choice, but it is not the same simplification.

Compatibility must lead the decision. Microsoft’s SQL migration assessment tooling can compare Azure SQL Database, Azure SQL Managed Instance and SQL Server on Azure virtual machines, identifying blockers, sizing and estimated costs. Treat those figures as planning inputs rather than a procurement decision: estimates vary with region, discounts, storage, network traffic, availability design and the commitments the organisation actually makes.

When is a hybrid Windows Server model the better answer?

Hybrid is often the sensible answer when an application has tightly coupled local and cloud elements, or when the estate cannot be modernised in one move. A local database and application server might meet a site’s real-time requirements, while off-site backup, monitoring, security telemetry and disaster recovery sit in Azure. Branch offices may retain small file caches while users elsewhere reach the same data through cloud services.

It can also provide a controlled way out of old management habits. Azure Arc can bring on-premises Windows Server machines into a central management model without pretending they have become Azure VMs. That can help with inventory, policy, update coordination and selected security services. It also introduces an agent, permissions and an Azure dependency into the management plane. Those implications need proper assessment, particularly in isolated or sensitive environments.

Hybrid should describe an architecture, not excuse an accidental mixture. For every workload, document where it runs, where its data lives, what happens during a WAN outage, which identity service it depends on, and how it will be restored after a site loss.

How should virtualisation hosts be treated?

Keep local virtualisation where it hosts workloads that pass the local-resilience or latency test. That may mean a compact Hyper-V cluster, a single carefully protected host for a small site, or a broader platform where the organisation has the skills and a demonstrable need. Decide where the workload belongs before choosing the host platform.

Licensing, management familiarity and guest operating systems all matter. Hyper-V remains a natural fit for Windows-heavy estates, particularly where Microsoft management tooling and Windows Server licensing already form part of the operating model. Linux-first environments may reach a different conclusion; Hyper-V and Proxmox present different trade-offs for mixed infrastructure. Neither platform can compensate for an unclear workload strategy.

How should cost, sovereignty and skills influence the decision?

Do not compare a depreciated on-premises server with one month of cloud compute and call it a total-cost analysis. Compare the next three to five years of each viable design: hardware refresh, Windows and application licensing, backup, storage growth, internet links, power, rack space, support contracts, migration work, monitoring, security tooling and staff time. Include the cost of high availability in both places. A single local server and a resilient cloud design are not equivalent services.

For Channel Islands organisations, data location and supplier contracts deserve the same attention as technical fit. Data sovereignty is often used too loosely to be useful. Ask the practical questions instead: where will production data, backups and support access reside; what contractual and regulatory obligations apply; can the supplier meet them; and who is responsible for proving it? A local server does not automatically settle those issues, and a cloud service in a chosen region does not automatically settle them either.

Skills can be decisive. A small team may be safer with fewer locally hosted platforms, provided it understands the cloud service’s identity, network, backup and cost controls. Conversely, an organisation with mature virtualisation, storage and recovery skills may get excellent value from a modest local footprint. Keeping infrastructure merely because it is familiar is a poor reason. Moving it merely because cloud spend is easier to classify as operational expenditure is no better.

What should be reviewed before deciding to keep a server on-premises?

Review workloads, not individual servers in isolation. One virtual machine may belong to an application whose database, file share, authentication path and peripheral devices must move together. Azure Migrate supports assessment of application groups as well as individual machines, which is closer to how real dependencies behave.

• Service dependency: What users, devices, file shares, databases, DNS records, service accounts and third parties must be available?
• Failure mode: Can the site work for a day without its internet connection? Can the service run if the building is unavailable?
• Performance: Record peak and ordinary CPU, memory, disk latency, IOPS, throughput and network flows. Do not size from allocated virtual hardware alone.
• Data: Identify where primary data, replicas, backups and exports sit, plus the recovery-time and recovery-point objectives the business actually needs.
• Security: Check patching, privileged access, segmentation, endpoint protection and recovery credentials. Keeping a workload local is not a reason to exempt it from modern controls. Windows Server 2025’s stronger defaults around LDAP signing, Kerberos encryption and SMB encryption are relevant here, as set out in this Windows Server 2025 security baseline.
• Exit route: Name the trigger and target state: retain for three years, replatform, replace with SaaS (software as a service), retire, or move once a dependency has been removed.

What is the sensible 2026 endpoint for Windows Server infrastructure?

A smaller, better-defined on-premises estate is a sound endpoint. Keep Windows Server close to work that must remain local, resilient and fast. Move services that benefit from managed cloud delivery or broad remote access. Use hybrid operations to connect the two, but make every connection intentional.

The weak outcome is a collection of servers retained indefinitely because nobody owns the application, alongside cloud VMs that are simply more expensive versions of the same problem. Every retained server needs an owner, a patching and backup standard, a tested restore path and a date for the next review. This is particularly urgent for older operating systems: extended security updates can buy time, but they are not a modernisation plan. Windows Server 2016 ESUs through Azure Arc need a firm exit plan; they are a controlled runway, not a destination.