Skip to main content

Kettering General Hospital migration to the Cloud case study

Kettering General Hospital (KGH), part of the University Hospitals of Northamptonshire NHS Group, set out their ambitions in 2019 to be the most digitally enabled hospital group in England by 2023.

Themes
  • Cloud native
  • Cloud First policy
  • Digital strategy 
  • Implementing cloud-based innovations for patients
  • Transforming the IT estate and removing on premise data centres
  • Staff upskilling
  • Cloud provider: Microsoft Azure

With over 4,500 staff, the trust provides acute healthcare services across their main hospital site in Kettering and satellite outpatient facilities within the Northamptonshire area.

Cloud migration was a pivotal component of the trust’s new digital strategy. They worked with their technology partner, Phoenix to transform their IT estate and develop a hybrid cloud migration approach. This saw them decommission up to half of their physical VMware host servers and unleash many of the capabilities offered by cloud.


KGH’s key drivers for cloud migration

A more flexible way of provisioning infrastructure

One of the trust’s main motivations for cloud migration was to switch to a more agile and responsive way to be able to use their services. The conventional way of procurement meant the trust had to size infrastructure based on a three-to-five-year capital depreciation model. This meant they had to size their infrastructure in line with existing demands, as well as forecast for any anticipated growth over the subsequent years, or face being constrained during that investment cycle.

Jas Sagoo, who was the Lead Services Architect for University Hospitals of Northamptonshire and led on the migration explained: “A typical virtual host server and storage area network refresh would cost in excess of £1 million, which excludes costs for running the data centres. As a result, there was a lot of waste as we were pre-provisioning five years upfront for the anticipated growth. It worked out as an expensive way to provision storage which may not be used.”

The trust recognised the need for a more efficient way to procure services that would allow them to scale up to meet demand, whilst only incurring costs on what they consumed.

They wanted to move away from old legacy systems and use the most modern technology that would provide security and reliability. They also wanted to allow their IT Infrastructure teams the opportunity to learn new cloud skills to help retain their technical talent.

Preparing for cloud migration 

We recognised that our move to migrate to the cloud would be a journey. Our first step was to carry out a discovery of our current services to understand what was cloud ready in terms of its infrastructure as a service (IaaS). This helped us to determine which services we could lift and shift over to the cloud.

The trust also agreed that wherever possible, new services would be built directly in the cloud or procured as cloud-based services, therefore adhering to cloud native PaaS and SaaS principles.

Working with suppliers

KGH’s next step was to work with third party system suppliers to migrate locally hosted managed services (such as their EPR system) into the cloud. They also worked with smaller suppliers to produce a cloud migration roadmap – where this wasn’t possible, the trust looked at cloud ready vendors as part of their re-procurement process. To support their hybrid migration approach, they focused on migrating systems and services that ran from their VMWare environment. Other managed services were more challenging to migrate and therefore required more time to work through the process with their suppliers.


The migration process

The trust delivered a successful migration that was well managed with good technical delivery. The scope of servers however did change along the way, due to some services no longer being needed. In total, 14 servers were de-scoped and other new services were commissioned directly in the cloud.


Impacts

As a result of their migration, KGH have been able to make some significant progress in the following areas






Learning

Allow generous lead times for the procurement of network infrastructure

Procuring key network infrastructure (that enables direct connectivity to the cloud from the data centres), took considerable time.  Therefore, factor in a generous lead time of around nine months into any migration plans.

“When you place your order for your ExpressRoute, it’s also worth sizing up the firewalls at the same time as you need to have the connection and resilience in place before you are doing any live migrations”, adds Jas.

Explore potential funding streams offered by cloud providers

KGH were able to access funding from the Azure Migration and Modernization Program (AMMP) which was a flat amount given by Microsoft which helped to fund some of the professional services support (engineers on-site) for the live migrations via their partner Phoenix. During the cloud discovery phase, they were able to get an idea of the number of servers they were planning to migrate, and the funding was allocated accordingly from these plans.

“You need to make sure you have a clear idea of your consumption costs as the funding is time bound and normally needs to be drawn down within 12 months”, advises Jas.

Ensure you work with an accredited partner as your cloud provider

"We gained a lot of value from working with our partner Phoenix”, explains Jas. “They acted as a critical friend and were a real strategic partner. They also attended the weekly stand ups and helped our own infrastructure teams with skills development”.

Ensure you have the appropriate sizing and connectivity for cloud

“Getting the sizing is also important. However, we took a very broad-brush approach. The first thing we decided was the size of the circuit bearer which had to be 10GB to allow for future proofing”, adds Jas.

“Secondly, we had to consider how much bandwidth we were going to contract for, using a 10GB bearer. This was made a little easier by the options that Azure gave us at the time. The maximum size was 5GB (set by Microsoft’s data centres) and the minimum was 1GB. The cost differential between 2,3 and 5GB was minimal as the bulk of the cost is in the size of the bearer. We chose 5GB and this gave us confidence that we would not only be able to migrate effectively but also be able to upload data from our on-premise data sources to our Data Warehouse in Azure.”

In essence, the trust knew they needed to get better connectivity and decided to opt for the Azure Express route, enabling them to connect from their on-premise data centres to Azure’s virtual centres.

Last edited: 10 March 2023 3:11 pm