Cloud migration without ‘the fear’ – Practical insights moving a major VLE to AWS

Sometimes it’s easy to under-appreciate a virtual learning environment until you put it through a full cloud migration, modernisation, and the controlled chaos of peak student enrolment. 

Working with The Open University to migrate and modernise their Moodle-based platforms to AWS – including the core VLE, OpenSTEM Labs and OpenLearn – gave us a front-row seat to what it really takes to future-proof large-scale digital learning. 

This is not just a story about moving servers; it is about reshaping how learning experiences are delivered, operated and evolved.  

If you’re considering migrating your education platform to the cloud, here are some practical insights to help you approach the process with confidence and clarity. 

Start with outcomes, not infrastructure 

The Open University did not come to us saying, “We want Kubernetes” or “We want IaC”. 

They came with outcomes: 

• A better experience for hundreds of thousands of learners. 
• A platform that could scale with demand (without scaling cost the same way). 
• Less operational pain for internal teams. 
• Freedom to innovate on pedagogy and learning design, not patching servers. 

Keeping those outcomes front and centre informed every technical decision: 

• Moodle on AWS became the standard foundation across platforms – a common, modern architecture that could still be tailored for each use case. 
• Services were chosen and designed not because they were “shiny”, but because they supported reliability, scalability and maintainability for student-facing experiences. 

Domain knowledge is not a ‘nice to have’ – it is critical path 

You cannot redesign a VLE in a vacuum. 

Before touching Terraform, containers or deployment pipelines, we invested serious time in understanding: 

• How the core VLE, OpenSTEM Labs and OpenLearn are actually used. 
• When and where traffic spikes happen (think: enrolment windows, assignment deadlines, exam periods). 
• Which integrations, plugins and customisations in Moodle were mission-critical. 
• How academic and support teams work day to day. 

This domain knowledge shaped both architecture and automation decisions. For example: 

• Designing for spiky demand rather than flat averages. 
• Ensuring lab workloads and remote experiment access in OpenSTEM Labs could run reliably and responsively. 
• Preserving and improving the experience for millions of OpenLearn users while changing everything underneath. 
  

“Lift and shift” is rarely enough – modernise while you move 

The brief was not just to move existing workloads into AWS. The opportunity was to modernise them. 

Together with The Open University, we: 

• Reconfigured the Moodle build to work optimally in a cloud-native environment. 
• Introduced containers to give more flexibility, consistency and portability. 
• Adopted Infrastructure as Code (IaC) so the infrastructure is versioned, repeatable and auditable. 
• Built patterns and templates that could be reused across platforms, not reinvented each time. 

Yes, this takes more thought than re-hosting existing servers. But it is the difference between: 

• Running old problems on new infrastructure. 
• Versus actually reducing operational risk and unlocking new capability. 

Automation is not just about speed – it is about safety 

Automation often gets sold as “we can deploy faster”. 

We definitely saw faster – but the bigger win was safer. 

By automating infrastructure provisioning via IaC, deployments and rollbacks, and routine operational tasks, The Open University teams gained: 

• Consistency – no more “but it worked in staging?”. 
• Reduced human error – fewer risky manual changes at awkward hours. 
• Confidence to change – knowing deployments are repeatable and reversible. 

For a mission-critical education platform, this is huge. When learners are relying on the system for their courses, experiments and revision, you cannot gamble on error-prone manual processes. 

Cost effectiveness is designed, not discovered 

The old on-premise setup was: 

• Hard to scale efficiently 
• Expensive to over-provision “just in case” 
• Time-consuming to maintain 

On AWS, cost effectiveness came from deliberate design choices: 

• Autoscaling to match capacity to demand (particularly for known peak periods) 
• Right-sizing infrastructure based on real usage patterns 
• Using managed services which it freed up time and removed undifferentiated heavy lifting 
• Standardising as much as possible across VLE, OpenSTEM Labs and OpenLearn to reduce operational overhead 

The result is not just “the bill is lower”. It is that the university can invest more energy in student experience and innovation instead of infrastructure firefighting. 

A one-team model beats a handover every time 

This was not a “throw it over the fence to a supplier” engagement. 

We operated as one team with The Open University, which meant: 

• Shared context and visibility across teams 
• Joint decision-making around trade-offs 
• A focus on upskilling OU staff in both Moodle and AWS, not creating dependency 

The training element was intentional. We spent time on how: 

• The AWS infrastructure is structured and operated 
• Moodle has been configured and deployed 
• Automation and IaC fit into day-to-day workflows 

That shared ownership is what will keep the platforms healthy and evolving long after the initial migration.  

Cloud frees internal teams to focus on value, not plumbing 

One of the most satisfying outcomes of the project is also one of the simplest: 

Internal teams now spend more time on value-add tasks and less on keeping the lights on. 

By leaning into: 

• AWS managed services 
• A strong partnership and shared responsibility model 
• Automation of repetitive operational tasks 

The Open University can direct more energy towards: 

• Enhancing the learning experience 
• Innovating with new features and platforms 
• Supporting academic teams and learners more effectively 

Underneath all the tech, the biggest learning is this: 

Cloud migration is not an IT project. It is an experience, capability and culture project that just happens to use cloud as the enabler. 

 Thinking about your own VLE or learning platforms? 

If you are considering a similar move, here are three questions to start with: 

1. What exactly needs to be better for students and staff – and how will you measure that? 
2. Are you prepared to modernise while you migrate, not just relocate what you already have? 
3. How will you ensure your internal teams come out of the process more capable, not more dependent? 

If those questions resonate, your University is probably ready to do more than “move to the cloud”. You are ready to build a platform that genuinely supports the next generation of learning.