Knowing Your AVD and W365 Use Cases

Compelling Factors

At the time of this blog, it is December 2025: My phone does not have an AI agent to carefully curate Ferroque’s weekly reports and Visio diagrams into a beautiful annual summary, but if it did, surely one of this year’s project themes would be customers taking advantage of their M365 licensing and piloting their workloads on Azure Virtual Desktop (AVD) and Windows 365 (W365).

When you think about it, this is highly significant for several reasons. Migrating desktops to the cloud is nothing new, but in 2025, there was a perfect storm of customer justifications for migrating desktop workloads into Azure desktops:

• Licensing and Commercial Pressure
  • Broadcom acquisition impact on VMWare licensing.
  • Increased licensing costs and packaging complexity.
  • Desire to reduce overlapping vendor spend.
• Infrastructure Refresh Avoidance
  • Avoiding capital investment in new hypervisor hardware.
  • GPU scarcity and cost inflation.
  • Data center consolidation or exit strategies.
• Security, Identity, and Zero Trust Alignment
  • Tighter integration with Entra IS and modern authentication.
  • Reduced attack surface on endpoints.
  • Simpler alignment with Zero Trust principles.
• Workforce and Usage Pattern Changes
  • Growth of remote, hybrid, and distributed workforces.
  • Increase in contractors, partners, and third parties.
  • Shift-based and frontline work models.
• Disaster Recovery and Business Continuity
  • Desire for simpler desktop DR strategies.
  • Regional resilience and geographic flexibility.
  • Operational resilience without full platform duplication.
• Cost Model Preference
  • Shift from CapEx to OpEx.
  • Ability to right-size desktops over time.
  • Improved cost transparency.
• Strategic Alignment with Microsoft Roadmap
  • Confidence in Microsoft’s long-term investment in cloud desktops.
  • Simplification of vendor relationships.
  • Alignment with broader Microsoft security and AI initiatives.

Designing with Intent

Regardless of the drivers, most conversations about AVD and W365 begin with deceptively simple questions, typically along the lines of:

• “Should I use AVD or W365?”
• “When should I use Windows 365?”
• “How is Windows 365 different from AVD?”

Default design decisions are used when organizations make a cloud desktop decision before adequately defining target use cases, and those default design decisions can inadvertently become production architecture if/when redesign and redeployment are deemed too expensive or operationally difficult to complete. Over time, these default decisions often lead to cost inefficiencies, operational friction, scaling challenges, and user dissatisfaction; not necessarily because the platform failed, but because the original design intent was never clearly articulated and considered before build/deployment activities occurred.

AVD and W365 are both strategic Microsoft offerings, but they are not interchangeable. Each was built to address different scenarios under different constraints. Treating these products as equivalents or forcing one to behave like the other typically results in a compromised solution.

“Designing with intent” for AVD and W365 is no different from designing for other EUC technologies, wherein fulfilling end-user requirements and delivering a good user experience are of the utmost importance. In any EUC design effort, the user personas, endpoints, and peripherals drive the requirements for the overarching design. It has been our experience that when the user personas are defined up front, the best-fit platform(s) begin to come into sharper focus.

AVD and W365: Different Tools, Different Intent

AVD and W365 are often discussed as alternatives for delivering Windows desktops on Azure. While this is technically true, it is architecturally misleading. The two services are designed around fundamentally different assumptions regarding control, responsibility, and operational ownership.

Understanding those assumptions is critical because most design failures occur when an environment is built under the wrong model.

AVD Requires More Design Decisions

AVD is designed for scenarios in which organizations need to make and retain explicit architectural and operational decisions. Compared to W365, AVD requires more upfront and ongoing design choices, but in return provides greater flexibility in how VDI environments are built, scaled, and optimized.

In practice, choosing AVD means architects must deliberately design elements such as:

• Host Pool Architecture
  • Pooled/persistent versus personal/non-persistent desktops.
  • Multi-session vs single-session workloads.
  • Host sizing and user density assumptions.
• Scaling behavior
  • Power management schedules.
  • Scaling workloads to peak and off-hours usage.
  • Considerations for spikes in resource demand.
• Image lifecycle
  • VDI image update cadence.
  • Validation and rollout processes.
  • Rollback and recovery strategies.
• Networking and security integration
  • Virtual network design, routing, and DNS.
  • Integration with existing security controls.
  • Connectivity to on-premises private resources.

The above decision points heavily influence consumption costs, performance, and user experience. For organizations that have hosted carefully curated workloads on EUC platforms such as Citrix DaaS and are accustomed to the administration commitment of a similar application and desktop delivery platform, such workloads are often good candidates for migrating to AVD. For less complex workloads, a W365 solution may be a more appropriate delivery platform.

W365 Requires Fewer Design Decisions

W365 takes a deliberately different approach. It is designed to reduce the number of architectural decisions customers must make, favoring a pre-defined service model that prioritizes consistency, predictability, and operational simplicity.

With W365, architects do not need to design elements such as:

• Host pools or scaling logic.
• VM start/stop schedules.
• Session density or concurrency behavior.
• Infrastructure placement or capacity planning.

Instead, W365 provides a service in which:

• A cloud PC is provisioned per user (or per Frontline entitlement).
• Microsoft manages capacity and availability.
• Desktops are persistent and predictable by default.
• Lifecycle and policy are managed via Intune.

This approach aligns well with organizations that want desktops to behave more like managed endpoints rather than a platform that must be continuously tuned. The absence of infrastructure-level controls is intentional and removes an entire class of operational responsibility from IT teams.

Mismatched Platforms and Use Cases

A frequent pattern we see in the field is deploying AVD for use cases better suited for W365, such as:

• Always-on, dedicated desktops per user.
• Minimal operational overhead expectations.
• Rapid provisioning without platform planning.

While AVD can be adapted to approximate these outcomes, doing so often results in over-provisioned environments, unnecessary complexity, and less predictable cost behavior, the inverse mistake also occurs, of attempting to use W365 for scenarios that require infrastructure-level control, only to discover that those controls are intentionally unavailable.

In both cases, the issue is not the platform itself but a mismatch between the use case and the design intent. Here is the most important distinction to internalize:

• Choose AVD when your requirements demand architectural control and customization.
• Choose Windows 365 when your requirements favor simplicity and reduced design responsibility.
• Use both when different user populations clearly require different outcomes.

These choices determine how environments scale, how incidents are resolved, how changes are introduced, and the long-term sustainability of the platform. Misunderstanding this distinction at the onset almost always leads to re-architecture down the road.

The following table provides a side-by-side overview of AVD and W365 use cases.

When the Requirement is Apps, not Desktops

In some scenarios, instead of a full VDI desktop, the requirement is access to a small set of applications. W365 Cloud Apps (currently in preview) reflects Microsoft’s recognition that app-first delivery remains a strategic application delivery model, especially for frontline and task-based workflows.

Cloud Apps further reinforces Microsoft’s move toward right-sized access rather than one-size-fits-all desktops, and should be evaluated strategically and carefully aligned with usage and delivery scenarios.

Of course, publishing apps from Azure-hosted desktops is nothing new; this functionality has been available since AVD was first introduced. Across AVD and W365 platforms, there are important design considerations to keep in mind. Single-session/multi-session limits still apply to applications that are published to users.

• User and application density are extremely limited, with applications published on W365 instances at a 1:1 ratio.
• Increased user density is available with applications published on AVD session hosts, which can scale with changes in user demand throughout the day.

Operating Models Day-2 Reality

One of the most consistent predictors of success or failure in Azure-hosted desktop environments is not the platform choice itself, but whether the operating model matches the platform’s design intent.

AVD and W365 both deliver Windows desktops, but they assume very different day-2 responsibilities. When those responsibilities are not clearly understood or are underestimated, environments tend to degrade gradually rather than fail catastrophically. By the time issues surface, they are often expensive to correct.

A key differentiator is that AVD assumes the organization is prepared to operate a platform, not just consume a service. Beyond initial deployment, IT teams must continuously manage and coordinate several moving parts. Alternatively, W365 shifts the operational center of gravity away from infrastructure and toward endpoint, identity, and policy management.

The following table provides a side-by-side overview of AVD and W365 Day-2 operations.

Many struggling environments share a familiar pattern: the platform was chosen correctly for the use case, but the operating model was never adjusted. Common examples include:

• AVD environments are deployed by project teams and then transitioned to IT operations teams that lack the skills and/or tools to manage image lifecycle and cost optimization.
• W365 environments are expected to support highly customized workloads that require infrastructure-level tuning.
• Organizations adopting AVD without clear ownership of autoscaling, cost governance, and/or image management.

In these scenarios, over time, issues typically manifest as:

• Gradual performance degradation.
• Rising, unexplained costs.
• Security posture drift.
• Increasing operational friction.

These are not platform failures; rather, they indicate day-2 ownership was never fully defined.

Note that W365 offers a number of “Hosted on behalf of” architecture models, effectively attaching Azure services to a hosted subscription. Depending upon the model appropriate for the organization, the Network team must be engaged to assist with implementing and managing the W365 footprint.

Operating Model Precedence

The most practical design question is often not “Which platform fits the use case?” but is instead “Which platform fits the way we actually operate today, and the way we expect to operate two years from now?” In this context, the operating model should guide the decision of which platform to use.

Organizations that succeed with AVD typically:

• Have clear ownership for platform engineering tasks.
• Treat cost optimization as ongoing work.
• Accept complexity in exchange for control, or:
  • Employ AVD (or W365) add-on management tools such as Hydra or Nerdio.
  • Employ Infrastructure as Code/IaC (e.g., Terraform, Ansible, etc.) to automate deployment for AVD (or W365) workloads.
    • Note: IaC deployments can vastly simplify/ease efforts around workload management; however, the initial effort to implement an IaC solution is typically a very heavy lift and requires ongoing maintenance effort.

Organizations that succeed with W365 typically:

• They are already mature in endpoint and identity management.
• Value predictability over tunability.
• Prefer service ownership over platform ownership.

If operational practices are not part of the decision-making process, even a technically sound design often becomes unsustainable. Architects and engineers should treat operating model alignment as a first-class design element rather than an afterthought, for example:

• If the organization is prepared to operate a platform, AVD can be powerful and cost-effective.
• If the organization prefers to consume a service, W365 will almost always age better.
• If different teams or user populations operate differently, a mixed model often provides the most aligned and resilient design.

This distinction becomes increasingly important over time, because operating models tend to change more slowly than platforms. Platform choice should align with business requirements and should not conflict with operational practices and expectations.

Both AVD and W365 integrate into Microsoft’s broader management and security ecosystem, but their operational center of gravity differs:

• AVD assumes stronger cloud infrastructure and operational maturity.
• W365 shifts the focus toward identity, policy, and lifecycle management via Intune.

If an organization’s support structure cannot sustain the operational model, even a well-designed architecture will likely struggle as growth, shifts in security posture, and/or cost pressures occur. Many well-designed deployments fail because the operating model was not considered at the onset.

Decision Framework

By this point, the distinction between AVD and W365 should be clear: rather than competing models, they are delivery models optimized for different outcomes. The remaining challenge is turning that understanding into practical decisions that can be applied consistently.

The following table provides a simple framework to help architects and engineers make defensible choices quickly, without modeling every variable up front.

Consumption Cost v. Subscription Cost

While this blog has focused on use cases and design intent rather than cost optimization, it is still important to acknowledge that AVD and W365 follow fundamentally different cost models, and this distinction alone often influences architectural decisions.

AVD is primarily a consumption-based model. Beyond licensing eligibility, organizations incur costs based on Azure resources consumed, e.g., compute, storage, networking, and optional services. This model rewards environments that are well-architected, right-sized, and actively optimized, particularly where concurrency patterns allow for autoscaling and efficient host utilization.

Alternatively, W365 is a subscription-based model. Each Cloud PC (or Frontline entitlement) entails a predictable per-user monthly cost that bundles infrastructure, platform operations, and availability into a single charge. This predictability is often valued as much for budgeting and financial planning as for operational simplicity.

This becomes significant at the break-even point. In practice, organizations often find that:

• Always-on, persistent, per-user desktops tend to favor W365 from a predictability and planning perspective.
• Variable, bursty, or non-concurrent workloads can favor AVD, where consumption can be actively controlled.
• Shift-based and intermittent access scenarios increasingly align well with W365 Frontline, which changes the economics by aligning licensing to usage patterns (rather than to named users).

Importantly, cost outcomes are rarely driven by platform choice alone. They are the result of how closely the delivery model aligns with actual usage, how effectively environments are operated over time, and whether the organization is prepared to manage the cost levers exposed by the selected model.

A Note on Cost Models and Break-Even Considerations

Although this blog intentionally focuses on use cases rather than cost comparison, it is important to recognize that cost behavior follows design intent.

• AVD’s consumption-based model rewards environments with well-understood concurrency and disciplined operational practices.
• W365’s subscription-based model favors predictability, particularly for always-on or dedicated user scenarios.
• W365 Frontline introduces a different break-even point by aligning costs to non-concurrent usage.

In practice, cost outcomes are typically the result of how closely the delivery model aligns with real-world usage and how effectively the environment is operated over time.

Closing Thoughts: Designing for Sustainability, Not Just Deployment

AVD and W365 both solve real problems and do so best when applied to the right use cases, with the right expectations, and under the right operating model.

This use-case-driven architecture/design model has been reinforced through real-world design workshops and community working sessions, including discussions with Microsoft MVP Thomas Poppelgaard, whose expert guidance on positioning AVD and W365 as intentionally distinct tools continues to resonate in practice.

Ferroque Systems has the expertise and experience to guide organizations in determining the best-fit virtual delivery solution, including with AVD and W365, and to design, implement, and roll out such solutions, as well as to provide ongoing operational support and management. We would be happy to discuss how we can help.