Most universities can move a substantial share of their physical computer-lab capacity to cloud delivery — practical computing modules often work better remotely than they did in the room — but very few can replace physical labs completely, and the credible end state is hybrid: a smaller physical estate doing what only rooms can do, with cloud labs carrying the workloads that never needed a specific desk. This guide covers which workloads move well, which should not move, the device, network, accessibility and assessment questions in between, and how to phase the change around hardware refresh points rather than forcing it.
Can physical computer labs be replaced completely?
Usually not — and a plan that assumes total replacement is a warning sign in itself. Some teaching depends on hardware that must be physically present, some assessment depends on controlled rooms, and some students depend on campus machines as their only reliable computing. What the evidence of the last few years does support is that a large share of computer-lab teaching was never really about the room: it was about a working environment, which can be delivered anywhere.
The productive question is therefore not 'can we close the labs?' but 'which workloads still need a room, and how much room do they need?'. Answering it workload by workload — rather than estate-wide in either direction — is what the rest of this guide is for.
Which workloads move well to cloud delivery?
The workloads that move best are the ones already fighting the physical model — software that takes hours to install, machines students break by using them properly, and rooms booked solid at ten past the hour.
- Software and web development — full toolchains delivered identically to every student, on any device
- Linux and Windows Server administration — students get root or Administrator on disposable servers, which locked-down lab PCs could never safely offer
- Cyber security and networking — isolated multi-machine environments that are actively safer in the cloud than on room networks
- Databases and data science — server-backed environments and pinned Python stacks without per-machine installs
- AI and Python teaching — consistent notebook and local-model environments at CPU scale
- General programming and computer science practicals — anywhere the requirement is 'the right environment', not 'this desk'
- Anything serving distance, blended or placement-year students — where the room was never reachable anyway
A pattern worth noticing: for several of these — systems administration, security, networking — cloud delivery is not a compromise version of the lab but an upgrade on it, because isolation and disposability were never really available on shared room PCs.
What can cloud labs not replace?
An honest list, because pretending otherwise wastes money and goodwill. Workloads in these categories should stay physical until something material changes.
- Specialist physical hardware — electronics benches, robotics, fabrication, audio and broadcast studios, medical simulators: the hardware is the teaching
- High-end local GPU and graphics work — heavy CAD, rendering and games development suites where dedicated workstations remain the practical economics, and latency-sensitive interactive graphics that suffer over remote sessions
- Software with local dongles or machine-locked licensing that cannot legitimately move
- Invigilated, locked-down examinations — remote alternatives exist but bring their own complexity; many institutions deliberately keep controlled rooms for exams
- Teaching where the room is the pedagogy — collaborative studios and pair-programming formats built around shared physical space
- The equity backstop — some students rely on campus machines, quiet study space and reliable connectivity that only a physical facility provides
That last item is easy to miss in an infrastructure conversation: for some students the computer lab is their best computer, their best internet connection and their workspace. Reducing lab estate without providing for them converts an estates saving into an attainment problem.
How do students access environments, and what about their devices?
Cloud-delivered labs invert the device question: instead of the university providing every machine, students reach hosted environments from their own — which works precisely because the environment runs server-side. Browser access is the baseline that makes this equitable, since it demands little of the device; a several-year-old laptop or a locked-down machine can carry a modern practical module.
But 'less demanding' is not 'no device needed'. A workable plan names its answers for students with unsuitable or no hardware: laptop loan schemes, retained campus machines and library provision as access points into the same cloud environments, and honest module-start communication about what students need. The point of the cloud move is that these backstops can be far smaller than a full lab estate — not that they can be zero.
What network, bandwidth and accessibility requirements matter?
On campus, the load moves from lab-room LANs to shared wifi: a timetabled session of ninety students in remote sessions is a concurrency event your wireless estate should be checked against, and lecture-theatre teaching with live environments needs the same thinking. Off campus, home broadband quality varies widely across any cohort — terminal-based work is forgiving, graphical remote desktops less so, and module design should account for both (our remote labs guide covers connectivity design in depth).
Accessibility must be tested, not assumed. Assistive technologies — screen readers, magnification, alternative input — behave differently through browser sessions and remote desktops than on a local machine, and institutions have anticipatory duties under the Equality Act 2010 that apply to teaching delivery however it is hosted. Test the real assistive-technology paths your students use before a module depends on the platform, and keep the individual-adjustments route open for cases the general provision does not cover.
Read next: Remote labs for distance learning guide
What does this mean for estates, continuity and resilience?
The estates conversation should be sequenced honestly: measured demand first, floor-space decisions second. Moving suitable workloads to cloud delivery reduces future dependence on refresh cycles and can free rooms for other use — but the numbers belong to your estates team and your measured utilisation, and any business case built on invented savings percentages deserves the scepticism it will get. Let a pilot and a year of real usage generate the figures.
Continuity cuts both ways and both deserve planning. Cloud labs keep teaching running when rooms cannot — building works, closures, transport disruption, or a cohort that was never on campus. Equally, they introduce a new dependency: when the platform or the network fails, the lab is down everywhere at once, so service status visibility, communication routes and a deadline-week incident plan become part of teaching continuity rather than an IT afterthought.
How should practical examinations be handled?
Decide the exam model explicitly rather than inheriting it. Continuous and coursework-based assessment moves comfortably — identical environments per student, frozen through the assessment window, are an integrity improvement on variable lab machines. Formal invigilated examinations are the hard case: remote invigilation and lockdown arrangements exist but add technical and policy complexity that many institutions reasonably decline.
The common hybrid answer is to keep a modest number of controlled physical rooms for invigilated practical exams — possibly running the same cloud environments on room machines, so the exam environment matches the teaching environment — while everything else moves. Whatever the choice, it should be made per assessment type, with academic regulations in the room, before the estate decisions that depend on it.
What support model does remote-first lab teaching need?
Replacing rooms replaces the support model that lived in them. The technician who walked over to a broken machine becomes remote triage: staff need console access into student environments to see what the student sees, students need self-service reset so routine breakage never becomes a ticket, and there must be a named route with realistic hours for everything else — including students working at night and at weekends, which lab buildings used to bound and cloud access does not.
Plan the transition for the people as well as the process: lab technicians hold exactly the skills remote lab support needs, and involving them early — in the pilot, in template testing, in writing the new runbooks — turns the change from a threat into a role.
What does a hybrid model look like?
A deliberate hybrid, five years in, typically looks like this: a smaller physical estate concentrated on specialist hardware, invigilated assessment and drop-in equity provision; cloud teaching labs carrying the practical computing portfolio; a standard desktop service (physical or VDI) for everyday applications; and remote delivery reaching the students who were never going to be in the building. Each workload sits where it belongs, and no service is impersonating another.
The design work is the allocation: an explicit map of which module practicals run where, owned jointly by IT and academic planning, revisited annually. Our VDI comparison guide covers the desktop side of that allocation in detail.
Read next: Virtual labs versus VDI guide
How should an institution phase the change?
Phase around refresh points and evidence, not around a big-bang date. Hardware ageing out is the natural decision moment — the question 'do we replace these hundred machines?' is far easier to answer well than 'shall we transform the estate?'.
- Inventory the portfolio — classify each module's practical work as clearly movable, clearly physical, or needs-testing
- Pilot one or two movable modules for a full teaching block, with success criteria agreed up front
- Move the clearly suitable workloads as their room hardware reaches refresh, rather than writing off working kit
- Run parallel capacity for at least a year — keep enough physical provision that a cloud problem is an inconvenience, not a crisis
- Measure real utilisation of both estates before any irreversible estates decision
- Shrink and repurpose gradually, keeping the specialist core, exam rooms and equity provision explicitly protected
The pilot is the hinge of the whole sequence — it converts this guide's generalities into your institution's evidence. The pilot guide covers how to run one that actually settles the question.
Read next: How to run a cloud lab pilot
A decision checklist
Before committing to reduce physical lab capacity, an institution should be able to answer yes — in writing — to each of these.
- Every module practical has been classified: moves, stays, or pilots first
- The honest cannot-replace list for our portfolio exists and estates decisions protect it
- Device and connectivity backstops for disadvantaged students are named and funded
- Assistive-technology paths have been tested on the target platform
- The examination model is decided per assessment type, with academic regulations involved
- Campus wifi has been checked against timetabled remote-session concurrency
- The remote support model is designed, staffed and has realistic hours
- A service-outage continuity plan exists for deadline periods
- Cost comparison covers both estates fully, including staff time, against measured pilot usage
- Parallel-running capacity is planned for the transition, with refresh points as the decision gates
Where does Cloud Pulse fit?
Cloud Pulse is built for exactly the movable share of this picture: the practical computing modules that need working environments rather than particular rooms. Lecturers define a module's environment once as a reusable template — Linux distributions, Windows Server, or multi-machine networks for security and networking work — and students reach identical environments through a browser from campus, home or anywhere else, with staff watching and supporting live. Environments follow the teaching block rather than the building's opening hours.
It does not replace the specialist hardware rooms, the exam halls or the equity provision — nothing cloud-based honestly does — but it is a strong candidate for the workloads your inventory marks as movable, and a pilot on one refresh-pressured module is the natural first step.