The Common Thread in University IT Projects

Key Takeaways

• Six UK universities’ published infrastructure case studies, at Leicester, Royal Holloway, Birmingham City and Cranfield, share a pattern: none of them modernised proactively. Every one of the four was forced into the decision by something external, a departing member of staff, a lease running out, a building earmarked for redevelopment, or a seasonal capacity crunch, and the modernisation followed as a consequence, not a strategic choice made in isolation.
• At the University of Leicester, that trigger was fear rather than a specific failure. Systems Specialist Mark Penny described a backup architecture where losing a single media server could have knocked out backup and restore access “for potentially weeks,” a risk that never actually materialised but drove the university to replace ten individual media servers with a shared Cloudian object storage platform, cutting rack space in half.
• A second Leicester project shows the same institution hitting the identical pattern twice. The university’s load balancers had been “built years earlier on open-source software by technicians who had since left the university,” Penny said, leaving a system nobody still on staff fully understood. The replacement wasn’t a strategic upgrade; it was a response to institutional memory walking out the door.
• Royal Holloway and Cranfield were both driven by harder deadlines. Royal Holloway’s legacy hardware carried “various legacy dependencies” that made routine support difficult while raising energy costs, and it moved to HPE dHCI under a consumption-based GreenLake model, cutting its data centre footprint 75% and energy use more than 72%. Cranfield’s original decision came from hardware, licence and support contracts approaching renewal at the same time one of its two data centre buildings was scheduled for redevelopment, forcing the question rather than inviting it.
• For a UK C-suite, the useful pattern across these four case studies isn’t which vendor or platform they chose, Cloudian, HPE, Nutanix, all appear once. It’s that each institution’s own account describes the trigger as external and largely outside its control, and that the resulting projects still delivered large, measured gains, 50% space savings, 75% footprint reduction, 80% less time spent on infrastructure management, once forced. The lesson isn’t to wait for a crisis. It’s that a board reviewing its own infrastructure roadmap should ask which of its systems are quietly waiting on the same kind of external trigger, a departing engineer, an expiring lease, a contract renewal, rather than assuming it will choose the moment itself.

Read individually, these are six unremarkable-sounding infrastructure stories: a university replaces some servers, another moves to the cloud, a third builds a backup site. Read together, four of them, at Leicester, Royal Holloway, Cranfield and Birmingham City, tell an identical story about why the decision actually got made, and it’s rarely the reason the resulting case study headline suggests. The other two, Oxford and Kingston, are useful precisely because they don’t fit the pattern, and the difference is worth naming.

Leicester, twice: what happens when the person who built it leaves

The University of Leicester’s first infrastructure overhaul wasn’t triggered by a failure. It was triggered by the university recognising how bad a plausible failure would be. Under its previous architecture, ten media servers each individually maintained backup and index data on SAN-based hardware; losing any one of them could have meant weeks without backup or restore access for the devices it served. “We wouldn’t be able to continue backing up data, access backups or conduct restores until we replaced the hardware and spun up the system again, a process which could have taken weeks. Fortunately, we never faced this situation, but we knew we had to make a change,” said Mark Penny, the university’s Systems Specialist. Leicester replaced the setup with Cloudian HyperStore object storage across 12 HPE Apollo servers, cutting the rack space needed for 2.5 petabytes of usable storage from 48U to 24U, a 50% saving, chosen over an open-source alternative and a more expensive commercial rival partly because Penny could install and test it himself on a laptop in 15 minutes.

The university’s second, related project shows the same forcing pattern playing out again, almost immediately after the first. Having replaced the storage layer, Leicester still needed load balancers reliable enough to keep it running, and its existing ones were “home-grown, built years earlier on open-source software by technicians who had since left the university,” in this publication’s own account, leaving a system nobody currently on staff could confidently maintain. Penny ran a proof of concept with Cloudian’s HyperBalance appliances and didn’t look further: “We were impressed by how easy it was to set up the load balancer solution and get going… We didn’t look at anything else.” The result now balances traffic across 15 HPE Apollo servers, handling 3.3 gigabytes of storage per second at peak without measurable performance loss. Two separate Leicester projects, two separate forcing events, neither one a proactive strategic decision made on the university’s own timetable.

Royal Holloway and Cranfield: deadlines set by leases and buildings, not by IT strategy

Royal Holloway University of London’s legacy infrastructure had accumulated “generations of hardware with various legacy dependencies,” making day-to-day management harder than it needed to be while a large data centre footprint drove rising energy costs, in the university’s own description of the problem. Working with Wavenet and HPE, Royal Holloway replaced it with a virtual infrastructure platform under HPE’s consumption-based GreenLake model, cutting its data centre footprint by 75%, its VMware socket count by 85%, and its energy use by more than 72%. “A modern, world-class university needs server infrastructure future-proofed for the cloud age,” said Zoë Faiz, the university’s Assistant IT Director.

Cranfield University’s original decision had an even more concrete deadline attached. Its intensive IT needs had been running on two ageing data centres built on traditional three-tier server architecture, with hardware, software licences and support contracts approaching renewal at the same time one of the two buildings was scheduled for redevelopment. “We took this opportunity to look at the whole infrastructure stack and all the overheads the servers brought from a management point of view,” said Edward Poll, Cranfield’s Head of IT Infrastructure. Working with CDW, the university moved to a Nutanix hyperconverged platform, chosen specifically for its flexibility to incorporate VMware and adapt to future financial and technical change. Cranfield’s relationship with that same setup continued into a 2024 technology refresh, this time on a rolling four-year cycle the university maintains deliberately rather than reactively, completed in four weeks with no user downtime and sustaining the 80% reduction in infrastructure management time the original deployment had already delivered.

Birmingham City University: the trigger was a calendar, not a crisis

Birmingham City University’s version of this pattern is the clearest example that the forcing event doesn’t have to be a technology failure at all. BCU’s largest annual opportunity to fill course places is its clearing period, a predictable, recurring calendar event that nonetheless required robust infrastructure to handle a surge in student applications without downtime. The university had previously used a seasonal hot-standby facility from Wavenet, staffed for 200 contact centre workers during clearing, and chose to convert it into a permanent, year-round work area recovery centre securing around half a petabyte of data across 400 virtual machines. “Having Wavenet as our partner means everything,” said Matt Peers, BCU’s Senior Project Manager. “The inclusion of work area recovery is essential for continuous and trusted connections during clearing.” The initial engagement led to a five-year contract, and the trigger, in this case, was entirely predictable and recurring rather than an emergency, which is itself a useful variant of the same underlying pattern: a known, calendared pressure point forcing a decision that a general sense of “we should modernise” never quite had.

Oxford and Kingston: the same broad category, and neither one fits

Two other university Microsoft 365 case studies this publication has covered, at the University of Oxford and Kingston University, sit under the same general “university IT overhaul” umbrella as the four above, and deliberately don’t share the forcing-event pattern. Oxford’s Microsoft 365 governance project was driven by an organisational reality, a decentralised federation of 39 colleges needing local autonomy within a coherent central structure, not a departing engineer or an expiring lease. Kingston’s data migration was driven by data volume and disruption risk, a genuinely large, ongoing logistics problem rather than a single triggering event. Neither university’s own account describes a forced hand the way Leicester’s, Royal Holloway’s, Cranfield’s or Birmingham City’s do. That’s a useful negative case: not every university IT project in this publication’s archive was reactive, which makes the four that were stand out more clearly as a real pattern rather than something true of university IT projects generally.

What a UK C-suite should actually take from reading these six together

The pattern worth taking from this isn’t that reactive infrastructure decisions turn out badly, all four forced projects here delivered large, specifically measured improvements once undertaken. It’s that four separate UK universities’ own published accounts each independently describe the same structure: a real, often quantifiable improvement that only happened because something external forced the timing, a person leaving, a lease or contract expiring, a building being redeveloped, a calendared seasonal peak. None of the four case studies describe an infrastructure team identifying the opportunity on its own initiative ahead of that trigger. For a UK board reviewing its own technology estate, the practical question these six case studies together suggest isn’t whether to modernise, it’s which systems are currently being kept running only because nothing has yet forced the decision, the equivalent of Leicester’s departed technicians’ home-grown load balancer, quietly working until the person who understood it was no longer there to ask.