How to run a university cloud lab pilot

What should a cloud lab pilot test?

A pilot should test fit under real conditions, not features under demonstration. Features can be verified in an afternoon; what only a pilot reveals is how the platform behaves on provisioning day, what students on their own devices and home connections actually experience, how much support load lands on whose desk, and what a module genuinely costs to run.

Concretely, a pilot worth the name observes: the lecturer workflow from template to taught session; a full-cohort provisioning day; student access from off campus and from the weakest devices in the cohort; behaviour through an assessment deadline; at least one mid-module environment change; at least one deliberate failure and recovery; and the measured usage that turns cost models into cost facts.

Which modules make good pilot candidates?

Pick modules where the environment problem is real and the teaching is otherwise stable. A module being redesigned at the same time contaminates the evidence — you will not know which change caused what.

• A genuine environment pain point — local-install chaos, locked-down lab machines, or a specialist stack students cannot run themselves
• A weekly practical component, so the platform is exercised continuously rather than twice a term
• A committed module leader — pilots run on lecturer engagement, and a conscript will quietly revert to old methods
• An assessment inside the pilot window, because deadline behaviour is a primary thing being tested
• Ideally a pair of modules covering both operating-system families — one Linux, one Windows or mixed — so the evidence covers the portfolio
• Stable module content — not a course being rewritten in the same semester

Who should be involved, and how many students?

Three constituencies must all be present — the lecturer who teaches, the IT team that would own the service, and the students who use it — plus a named decision-maker who will attend the final review. Pilots fail structurally when any of these is missing: IT-only pilots prove infrastructure and ignore teaching; lecturer-only pilots delight one enthusiast and terrify the service desk later.

• Module leader — owns the environment design, teaches with it, reports the teaching experience
• IT or infrastructure owner — owns identity, security review, usage limits and the operational verdict
• Named support contact — first line for students during the pilot, logging every issue and theme
• The student cohort — preferably the whole enrolled cohort rather than volunteers (see the section on unrealistically easy pilots)
• Procurement or finance observer — so the cost evidence is collected in the form they will later demand
• Provider counterpart — one named person on the vendor side, if a vendor is involved

On numbers: enough students to make provisioning day and timetabled concurrency real. As an illustration only — not a requirement of any platform or of Education Host — a single module cohort somewhere between twenty and sixty students is a common shape: large enough to stress the mechanics, small enough to support closely. The right size is whatever makes the evidence transfer to your real portfolio.

How long should a pilot run?

A full teaching block, including an assessment period — for most UK institutions that means a term or semester. Shorter pilots systematically mislead: a fortnight of smooth sessions says nothing about week-one provisioning, reading-week idle costs, deadline-night load or end-of-module teardown, which is where lab services actually earn or lose their keep.

Where a full block is impossible, compress deliberately rather than accidentally: stage a synthetic provisioning day, a synthetic deadline and a forced failure into the shorter window, and treat the cost data as indicative only. Duration itself is something to agree during scoping — with Education Host or any provider — rather than a fixed number.

What should happen before students are invited?

Students join a working service, not a test. Everything on this readiness checklist happens in the staff-only stage — inviting a cohort into an unfinished pilot burns goodwill you will not get back, and contaminates the student-experience evidence.

• Identity decided and tested — institutional sign-in (for example Microsoft Entra ID, where the platform and deployment support it) or pilot accounts, chosen deliberately
• Security review completed — authentication flows, environment isolation, data location and acceptable-use boundaries signed off by the right people
• Module environment built as a template and tested end to end by the lecturer, running the actual first practical
• Access verified from off campus, on a low-powered or locked-down device, not just from a staff machine on campus ethernet
• Usage limits, schedules and idle controls configured — and the student-facing behaviour at a limit understood
• Support route named and published — who students contact, in what hours, with what escalation to the provider
• Data and retention agreed — what happens to student work and accounts when the pilot ends, in either direction
• A teaching backstop — if the pilot fails mid-term, how does the module continue? The old delivery method stays available until the pilot proves out
• Student communications drafted — what this is, why, what is expected of them, and where help lives

Read next: Student virtual environments with Microsoft Entra ID · Cloud lab security and governance

How should templates be tested, and what limits applied?

The template is the product students meet, so it gets its own test cycle: the lecturer runs every early practical inside a freshly deployed copy — not the machine the template was built on — and someone other than the author repeats the run with student-level permissions. Template preparation, cleaning and versioning are a discipline of their own, covered in depth in our reusable virtual machine templates guide.

Limits deserve deliberate testing rather than hopeful configuration. Set the sizes, schedules and quotas you intend for real use, then hit them on purpose during the staff stage: watch an environment auto-stop, watch a quota refuse a request, and check what the student would see. A limit whose failure mode is first discovered by a student at 11pm before a deadline was not a control, it was a trap.

Read next: Reusable virtual machine templates guide · How to control student cloud-computing costs

A sample staged pilot structure

The following staging is an example shape, not a required process — real pilots are agreed per institution around the academic calendar. What matters is the order: staff prove the service before students meet it, and failure is tested before the assessment window depends on it.

How should success be measured?

Against criteria written down at stage zero, grouped so every constituency sees its own evidence. Numbers gathered during the pilot beat impressions reconstructed afterwards — assign each measurement an owner on day one.

• Technical — provisioning completed for the full cohort on schedule; availability through timetabled sessions and the assessment window; resets and recoveries behaving as designed
• Lecturer experience — hours to build and deploy the environment; in-class time lost to environment problems versus the previous delivery; whether the lecturer could self-serve or queued on IT
• Student experience — time until every student was working in week one; off-campus and weak-device access rates; student-reported friction
• Support and operations — ticket volume and themes; who resolved what; anything that required the provider and how that went
• Cost and utilisation — measured environment-hours against the model; idle share before and after controls; a real cost per module delivered
• Security and governance — review actions closed; isolation and acceptable-use boundaries held; data handled as agreed

Write the thresholds down too — 'every student working by the end of the first session' is testable; 'students found it easy' is not. The costs guide covers how to turn the measured usage into a defensible budget for wider adoption.

Read next: University cloud lab costs guide

Don't run an unrealistically easy pilot

The most common pilot failure is succeeding at something too easy: a hand-picked module, a dozen volunteer enthusiasts, oversized environments, the vendor's best engineer on standby, and no deadline inside the window. Everything goes green, adoption follows — and the real estate of large cohorts, average devices and normal support discovers the problems at scale.

Design difficulty in deliberately. Use the whole enrolled cohort, not volunteers who self-select for capability and goodwill. Keep environments sized as you would really run them. Include the awkward module — the Windows-and-Linux mixed exercise, the big first-year cohort — not just the friendly one. And hold the provider to the support arrangement a real deployment would get, not pilot-grade heroics; ask them plainly what standard support would have done differently at each escalation.

Test failure and recovery on purpose

Term time will test failure for you eventually; a pilot lets you choose when. Schedule drills the way you would fire drills, with the lecturer's agreement, and document what actually happened rather than what the runbook says.

• Reset a student environment mid-session and time the return to work
• Break an environment properly — then recover it from the template rather than repairing it by hand
• Roll a template change back after deploying it
• Simulate a stuck student who cannot reach their own environment, and resolve it through the real support route
• Run one escalation all the way to the provider and observe response against the agreed arrangement

Recovery evidence is the difference between a platform that demos well and one you can rely on in week nine. If a drill goes badly, that is the pilot working — better now than during marking.

What should happen after the pilot?

Hold the decision meeting that was scheduled at stage zero, with the evidence pack and the criteria side by side, and make one of three calls. Proceed: criteria met — plan the widening (which modules next, procurement route, support model at scale) while the pilot configuration and templates are fresh. Revise: promising but specific criteria missed — change the named things and re-test narrowly rather than rolling forward on hope. Stop: must-have criteria unmet, support load unsustainable, costs materially off-model, or access inequitable for part of the cohort — say so plainly and keep the evidence.

Stopping is a success of the process, not a failure of nerve; it is precisely what the pilot was for. Whatever the decision, archive the evidence pack — measured usage, support themes, costs — because it is the foundation of either the business case or the requirements list for the next attempt.

How does a Cloud Pulse pilot work?

Education Host runs structured pilots on the lines this guide describes: a real module, agreed success criteria, and a scoped window agreed with the institution — the pilot programme page covers the process. The platform mechanics support the evidence-gathering directly: lecturers build and deploy the module template themselves, Pulse Manager shows every student environment live during sessions, and the drills above — resets, template updates, recoveries — are ordinary platform operations rather than staged exceptions.

Pilot work is not throwaway: pilot configurations carry forward into full deployments, so the templates and identity setup a successful pilot produces become the start of the real service. If you are weighing a pilot — of Cloud Pulse or anything else — the checklist and staging in this guide are the preparation either way.