Cloud migration is nothing new. But why does this make sense for universities specifically? And how might they go about it?
Why are universities moving to the cloud?
Cloud services offer a number of potential turnkey solutions for universities:
- Operations - Cost savings from closing down on-premise data centers, which can free up space for more classrooms/facilities
- People - Cost savings from a reduction in IT administration and support, meaning the university can invest elsewhere
- Maintenance - Cost savings from the reduced need for ongoing hardware and maintenance by moving student and faculty data and applications to the cloud
- Flexible - Potential to scale up or down as student numbers increase/decrease and server demand fluctuates
- Payment - Cost savings by paying only for the resources needed
- Scalability - The ability to meet the increasing high-performance demands of remote learning and teaching applications
- Disaster recovery - Fast data recovery in the event of an on-premise outage, keeping critical applications and services up and running
- Storage - Unlimited storage capacity to cope with exponential data growth and data regulations
- Big data - The ability to support research faculties and predict student success with the analysis of big data, machine learning, and the creation of data lakes
The migration checklist
Some of the key questions for universities wanting to migrate to the cloud include:
- Responsibilities - Who will determine who will lead and manage the project, who will be involved in the development, implementation, and testing of individual workflows/applications etc?
- Migration plan - Should you consider a phased approach to reduce your risks? What might this look like? Will you take a hybrid approach? Which components, applications, and services should you move first to establish a strong foundation? Will you switch over everything at once, or take a more piecemeal test-and-learn approach?
- App strategy - For each application, will you 'lift and shift' or rebuild specifically for the cloud? Which applications can't or shouldn't be moved? Do you want separate applications in separate clouds? Will you split your app load across different providers? Do you want to build platform agnostic applications so you have more flexibility to change cloud providers in the future?
- Providers - Which cloud provider(s) will you use? Bear in mind, each provider will have their own APIs to learn. On the flip side, however, aligning yourself with a single cloud provider means placing all your eggs in one basket and will lead to vendor lock-in - meaning you'll be fully committed to their offering and will lose any leverage to negotiate bespoke pricing. You'll also have to go through significant pain to rearchitect all of your applications if you want to move elsewhere.
- KPIs - What KPIs will you use to determine whether your apps are performing as expected? What is your tolerance for error? How will you know whether the migration is successful? What pre and post-baselines will you use? How will resource allocations be optimized?
- Training - What training is needed to make sure those involved have the skills and knowledge to make it happen?
- Data audit - Before you do anything, do you really know where all your data and workflows sit? What might your line-by-line data migration plan look like? How will data be collected and synced across your data centers and the cloud?
- Security and disaster recovery - How will you safeguard your data and ensure timely recovery in the event of a critical failure? How will you protect against accidental data loss and ransomware attacks?
- Timing - When should the activities take place? You may wish to plan for switch ons to take place at a time of low server demand e.g. during the quieter holiday months
- Stakeholders - How will you manage stakeholder expectations? There may be enthusiasm from senior leaders for the migration, but do they have a realistic understanding of how long the project will take? Are they prepared for any disruption that may be necessary? How will the plan be communicated across Departments? Who will be responsible for change management?
Finally, a sobering word from the VP of Information Technology and Chief Information Officer at Athabasca University (AU), Jennifer Schaeffer:
We didn’t just decide to move on a whim...While change is constant, change is also hard. I hear from my fellow CIOs that turning the tide to get teams to change process and adopt new technology is as much of a technological knowledge gap as it is an emotional one. But the payoff is vast.