AWS Government, Education, & Nonprofits Blog

Five Lessons Learned by an Education Service Agency Migrating School Districts to AWS

Southwest MiTech is an IT support consortium in Michigan under the Kalamazoo Regional Education Service Agency (KRESA) that provides top-to-bottom technology services for KRESA and the districts they serve. Early last year, KRESA was facing tight budgets and increasingly rigorous security and compliance requirements, yet they still were under pressure to scale their infrastructure and provide a disaster recovery (DR) environment.

Southwest MiTech knew they needed to find KRESA a scalable, reliable, and secure cloud infrastructure that would collectively save them hundreds of thousands of dollars and their IT teams countless hours of work.

Below Michael Coats, the infrastructure manager for Southwest MiTech, shares how they went about selecting a cloud provider and migrating KRESA’s services to the cloud, lessons they’ve learned along the way, and where they plan to go from here.

  1. Explore your options: My initial thought was, ‘Of course we’re going with Azure. That’s the next step.’ But I thought I should at least take a look at Amazon Web Services to check it off my list, do my due diligence. I realized Amazon’s infrastructure was miles ahead and it wasn’t a hard sell with the combination of AWS’ infrastructure, features, and affordability.
  2. Get buy-in and training: It is critical to get administrative buy-in. Moving infrastructure to the cloud can be a big paradigm shift for education, so it is important to talk through what it means to move from the CapEx model of infrastructure purchases and refreshes to the OpEx, pay-as-you-go model as it may affect budgeting. The other piece of management buy-in is the need for training. Make sure to set aside some time and maybe even some budget dollars for training. There are many AWS training opportunities out there and you don’t want to make infrastructure changes without knowing what you’re getting into.
  3. Design for future growth: You may not think you need to scale right now, but you should design your implementation for future growth and additional workloads. For example, initially we thought we could use a simple VPC and subnet layout and doing anything larger would needlessly complicate things. Once we started looking at Elastic Load Balancers (ELB), we realized that they needed to have the load-balanced instances in separate Availability Zones (AZ), which required separate subnets. This design helps with proper failover; in the event one AZ goes down, the ELB will be able to utilize the other nodes in the other AZ.
  4. Create a migration plan for every server in your environment: Every onsite host we manage, regardless of which physical district it is in, is managed by vCenter. I exported a list of every virtual machine (VM) we managed and plugged it into a spreadsheet. I then identified what type of migration will happen to every VM. My motto is: ‘do it once, do it right, and do it to scale.’ I don’t have the time to redo things, so we want to make sure we do it right the first time. Our districts really rely on us to be the experts. And if you don’t do it to scale, you can’t do it economically.
  5. Don’t lose the bigger vision: Our mission is to empower teachers to transform student learning through technology integration. Step one was to get the right infrastructure set up. Step two was migrating to the cloud with no disruption to the 25,000 students and 5,000 staff we serve. And step three is to work with even more schools to unlock the innovation possible with cloud computing. I am proud of how we have been able to move our districts into the future faster by adopting our cloud-first initiative.

Learn how to get started on AWS by checking out our educator’s guide, which highlights how to set up and manage your AWS accounts, as well some best practices for getting started.