Azure Lab Services retirement: build, buy or blend your replacement?

Microsoft will retire Azure Lab Services globally on 28 June 2027. For universities using the service, the practical deadline may arrive much sooner, depending on their academic calendar, procurement process and change windows. The next step is to decide which workloads to build, which to buy and where a blended model makes sense.

Microsoft’s decision to retire Azure Lab Services on 28 June 2027 has created a fixed date for universities around the world. But working towards the final service date would leave little room for procurement, migration, testing or unexpected problems. Each institution should work backwards from the start of its first affected teaching period and aim to have its replacement tested and ready before students depend on it.

For many Australian institutions, that could mean being ready before semester one begins in February 2027. Universities in other regions will need to set an equivalent deadline around their own academic calendar.

Universities using Azure Lab Services may need to complete procurement, security review, integration, migration and a meaningful pilot before they can transition. Academic calendars, staff availability and institutional change freezes will vary by region, but in every case the available window is likely to be considerably tighter than the retirement date suggests.

The service deadline is global, but the practical deadline is local

Microsoft will support existing Azure Lab Services deployments until 28 June 2027. After that date, universities will no longer have access to their lab accounts, lab plans or labs, although images stored in Azure Compute Gallery will remain available.

Microsoft recommends beginning retirement planning now, including assessing pricing differences, securing the necessary compute capacity and evaluating Microsoft and partner alternatives.

For universities, the academic calendar is likely to matter more than the final retirement date. A cutover after teaching has begun could put live courses at risk. Institutions should therefore work backwards from the first teaching period that could be affected, allowing sufficient time for procurement, technical evaluation, integration and testing.

In Australia, readiness before semester one in February 2027 may be the appropriate target. In other regions, universities should identify their own equivalent point of no return and build the transition plan around it.

A realistic plan needs to move quickly. Discovery and workload profiling should begin immediately, with procurement running alongside technical evaluation. Any pilot should be completed early enough to resolve issues before the replacement is used for a live teaching period.

This is an operating model decision

It is tempting to treat retirement as a product replacement exercise.

But that misses the bigger decision.

Virtual labs sit across teaching, identity, networking, software licensing, accessibility, student support and cloud cost management. The right replacement depends on which of those responsibilities a university wants to retain and which it is better placed to transfer to a provider.

In a recent CAUDIT members-only webinar for higher education technology leaders across the region, NashTech and partner Apporto discussed three credible paths. Although the discussion was framed around the needs of CAUDIT members, the underlying choices apply to universities globally:

• Build. Run a purpose-built platform in the university’s own cloud tenancy. This offers the greatest control over images, networking, identity, data residency and the cost model. It also leaves the institution responsible for engineering, upgrades, monitoring, support and out-of-hours cover.
• Buy. Adopt a managed platform designed for education. This can provide predictable pricing, browser access, central image management and a supported upgrade path, but gives the institution less control over the underlying stack.
• Blend. Use a managed platform for standard teaching labs and build the exceptions that genuinely require bespoke infrastructure. This can balance cost certainty with control, provided the boundary between the two models remains clear.

There is no single right choice for every university. Universities with a complex Azure setup and the skills to manage it may choose to build a replacement. Others may find that running standard teaching labs takes up valuable technical time without adding much value. Many universities will need a mix of both approaches.

Five factors to consider

When considering what path your university should take, consider the following five factors.

Compare the cost to run each option, not only the licence or cloud charge. Include engineering time, image pipelines, security, idle capacity, support, monitoring and the cost of maintaining overlapping services during transition. For a self-built platform, cloud discounts and automatic shutdown can reduce consumption, but only if somebody actively manages them each semester.

Ask who will respond when a lab fails the evening before an assessment or during a peak teaching week. A build is more credible when the institution has a stable platform team with sufficient cover. If the current service depends on one specialist or has no out-of-hours roster, a managed option may reduce a material operational risk.

Assess data residency, patching, audit evidence, access controls and the effect of losing key technical knowledge. Some research workloads or institutional policies may require bespoke controls in the university’s own tenancy. Standard teaching labs may be better served by making a provider accountable for routine platform security and availability.

Test the service from the user’s perspective. Can students use it on a laptop over home Wi-Fi? Does it work with the institution’s learning management system and single sign-on? Can academics request an updated image in days rather than weeks? Accessibility and support need to carry as much weight as infrastructure design.

Look beyond the immediate Azure Lab Services replacement and consider the university’s wider and longer-term virtualisation requirements. This may include proctored assessments, cybersecurity and networking labs, research environments and other virtual desktop use cases. Procurement timelines may make it difficult to address or consolidate all of these requirements as part of the initial transition, but they should still be considered when selecting the next platform. The right solution should address the immediate Azure Lab Services requirement while providing the flexibility to support a broader range of education-specific use cases over time.

Why a blended model may suit many universities

A blended model recognises that teaching labs and advanced research have different needs. Standard course software, cybersecurity teaching, research desktops and online assessments can often use an education platform. Research that needs powerful GPUs, large datasets or custom networks may be better suited to Azure Virtual Desktop in the university’s own cloud environment.

This approach means the internal team has fewer systems to manage, while keeping control where it matters. It also avoids putting specialist research into a standard service or rebuilding every teaching lab because a few need custom features.

How NashTech and Apporto can help

One option for universities moving away from Azure Lab Services is Apporto, an education-focused transition partner included in Microsoft’s retirement guidance. Its managed, browser-based platform supports virtual computer labs, cybersecurity labs, digital workspaces and controlled assessment environments without requiring the institution to build and manage the full platform itself.

NashTech is working with Apporto to support universities in Australia. Apporto provides the managed platform, while NashTech helps institutions understand their workloads, integrate the service, manage migration and build specialist Azure environments where required. Universities outside Australia should speak to the team about support available in their region.

What higher education leaders should do now

The most important step is to replace a single estate-wide assumption with evidence about individual workloads. Universities should:

• Identify every active lab and image.
• Map its users and teaching calendar.
• Record its compute and licensing requirements.
• Separate standard teaching needs from genuine exceptions.

Acting now

The next consideration is timing. Universities should factor procurement, technical evaluation and piloting into their transition planning from the outset. In our experience, a proof of concept will typically form part of the broader evaluation and procurement process rather than happen independently of it. With the Azure Lab Services retirement deadline approaching, institutions should allow sufficient time to evaluate potential solutions, complete their procurement and security requirements, and validate the chosen platform before moving into live teaching. 

Finally, the pilot should recreate real conditions with a real cohort, representative devices and connectivity, live learning management system and identity integration, academic image changes, peak usage and support outside the core working day.

A deadline can prompt a better design

Retiring Azure Lab Services creates pressure, but it also gives universities an opportunity to look beyond a like-for-like replacement and consider their wider virtualisation requirements. The goal should be to give students reliable access, give academics a workable service, and direct scarce engineering capacity to workloads where institutional control adds value.

This is also an opportunity to consider requirements that may currently sit across different platforms, such as Citrix for virtual desktops, Cisco environments for networking labs, and Respondus for controlled or proctored assessments. Rather than evaluating the next platform solely against today’s Azure Lab Services workloads, universities should consider what other education-specific use cases they may want it to support over time.

This is where the breadth of the Apporto platform becomes relevant, with virtual computer labs, cybersecurity and networking labs, research environments and Exam Space providing a broader education-focused proposition.

We recognise that procurement timelines may make it difficult to consolidate all of these environments as part of the initial Azure Lab Services transition. However, the opportunity for future consolidation should still be considered when selecting the next platform, even if those workloads are migrated at a later stage.

If your university is planning its move away from Azure Lab Services, NashTech and Apporto can help you profile the estate and compare build, buy and blended options against your academic calendar, operating capability and student needs. Speak to the NashTech higher education team.

Azure Lab Services retirement frequently asked questions

Microsoft will retire Azure Lab Services globally on 28 June 2027. Universities should aim to have a replacement tested and ready before their first affected teaching period. For many Australian institutions, this may mean being ready before semester one begins in February 2027.

Universities can build their own platform with NashTech, buy a managed service such as Apporto or combine both approaches.

3. When should universities start planning?
Now. Institutions need to allow time for workload discovery, procurement, security and technical assessment, integration, migration and testing under real teaching conditions.

Apporto provides the managed virtual lab platform. NashTech helps universities assess workloads, plan the move, integrate the service and build specialist Azure environments where needed.

NashTech is proud to be a Microsoft Solutions Partner across Infrastructure (Azure), Data and AI, Security and Digital and App Innovation (Azure), with advanced specialisations in Migrating Enterprise Applications to Microsoft Azure and Kubernetes on Microsoft Azure. Visit NashTech in the Microsoft partner marketplace for more information.