+44 (0)1482 770583
hello@systechitsolutions.co.uk
In short: How moving a client from Azure Virtual Desktop to Windows 365, and fixing long-standing shared mailbox faults, drove priority-one incidents to zero.
The challenge
The client was running Azure Virtual Desktop but living with recurring instability and a steady stream of priority-one (P1) incidents. Persistent shared mailbox problems were disrupting day-to-day work, and the environment carried more management overhead than the business needed.
Azure Virtual Desktop is a capable platform, but it is a platform rather than a product: host pool sizing, image management, autoscaling rules and session host patching all have to be designed and then maintained. Where that ongoing ownership is thinner than the design assumed, instability tends to follow, and it usually presents as a stream of user-facing incidents rather than as an obvious infrastructure fault. The harder question in these situations is whether the platform is genuinely wrong for the business or whether the configuration around it was never finished.
What we did
- Assessed real usage and recommended Windows 365 Cloud PCs for predictable, per-user desktops
- Migrated users from Azure Virtual Desktop to Windows 365 in a phased, low-disruption cutover
- Diagnosed and fixed the underlying shared mailbox configuration issues
- Brought devices and identity under managed control with Intune and Conditional Access
- Put ongoing monitoring and management in place to keep the environment stable
Establish what the users actually need
The starting point was real usage rather than the existing design. Where a workforce is stable and each person needs a consistent desktop, the flexibility of a fully configurable virtual desktop platform is capability nobody is using but everybody is maintaining. That pointed towards Windows 365 Cloud PCs and their fixed, per-user model.
Migrate in phases, not in one cutover
Users moved from Azure Virtual Desktop to Windows 365 in a phased, low-disruption sequence rather than a single switchover. Phasing does two things: it keeps the blast radius small if something behaves unexpectedly, and it lets the process be refined on the least critical group before it reaches the most critical one.
Fix the faults rather than migrating around them
The persistent shared mailbox problems were diagnosed and corrected at the configuration level. This distinction matters, a migration that carries an unresolved fault across to a new platform simply relocates the incident queue, and the new platform then takes the blame for a problem it did not cause.
Bring identity and devices under managed control
Devices and identity were brought under Intune and Conditional Access. A desktop platform is only as stable and as secure as the identity layer in front of it, so this is treated as part of the same piece of work rather than a follow-on project.
Keep it stable after go-live
Ongoing monitoring and management were put in place so drift gets caught early. The point of the migration was to reduce the number of things that need watching, not to move them somewhere new and stop watching them.
The results
- Priority-one incidents fell to zero across the first six months on Windows 365
- The long-standing shared mailbox issues were resolved for good
- Simpler, fixed per-user cost and far less day-to-day management overhead
Priority-one incidents fell to zero across the first six months on Windows 365, and the shared mailbox issues that had been disrupting day-to-day work were resolved for good. Alongside the stability, the commercial and operational picture simplified: a fixed per-user cost that finance can forecast, and far less day-to-day management overhead for the team.
What we would tell you before you start
Match the platform to how the business actually works
Flexibility you do not use is not free. Where headcount is stable and needs are uniform, a fixed per-user desktop removes an entire category of design and tuning work.
Resolve underlying faults before you migrate
A migration is not a fix. Faults carried across to a new platform tend to be attributed to the migration, which makes the new platform look like the problem.