- ✓Cloud migration is rarely as simple as lifting and shifting existing applications to the cloud unchanged: most applications require some degree of modification, refactoring or replacement to operate effectively in a cloud environment.
- ✓The 6Rs of cloud migration (Rehost, Replatform, Repurchase, Refactor, Retire and Retain) provide a useful framework for categorising the migration strategy for each application in a portfolio.
- ✓Data migration is often the most complex and risky aspect of a cloud migration project, particularly for organisations with large volumes of legacy data, complex data relationships or strict data residency requirements.
- ✓Legacy systems that were not designed with cloud deployment in mind can present significant technical and cost challenges during migration, and realistic assessment of these challenges upfront is essential for accurate project planning.
- ✓Risk management in cloud migration projects should cover technical risks, data integrity risks, business continuity risks and the risk of cost overruns: each should be assessed, prioritised and have specific mitigation plans in place before migration begins.
Listen to the full episode inside the course. Enrol to access all 80 episodes, plus assignments, tutor support and Student Finance funding.
Start learning →Alex: Hello and welcome back. Today Sam and I are looking at the real challenges of cloud migration, because we've established why organisations want to move to the cloud, but the actual journey is rarely straightforward. Sam, what makes cloud migration hard?
Sam: The fundamental challenge is that most organisations have decades of accumulated infrastructure and applications that were built for an on-premises world and were never designed with cloud deployment in mind. Moving them to the cloud isn't simply picking them up and putting them down somewhere else: it often requires significant re-engineering, which takes time and skill and introduces risk.
Alex: Let's talk about the 6Rs framework, which provides a vocabulary for thinking about migration options.
Sam: The 6Rs are a taxonomy of migration strategies. Rehost, sometimes called lift and shift, involves moving an application to the cloud without changing it significantly. It's the quickest approach but often fails to realise the full benefits of cloud. Replatform involves making some optimisations as you migrate, like moving from a self-managed database to a cloud-managed database service, without fundamentally changing the architecture. Repurchase means replacing an existing application with a cloud-native SaaS alternative. Refactor means redesigning and rebuilding the application to take full advantage of cloud-native architectures like microservices and serverless. Retire means decommissioning applications that are no longer needed. And Retain means deliberately keeping certain applications on-premises, at least for now.
Alex: What makes data migration particularly challenging?
Sam: Several things. The sheer volume of data can make the physical transfer slow and expensive: large organisations may have petabytes of data that can't be moved over a network in any reasonable timeframe, requiring physical transfer using hardware appliances. Data relationships and dependencies between systems can be complex: you need to understand exactly which systems depend on which data before you can migrate anything safely. And data residency requirements may constrain where certain data can go, which complicates the migration architecture.
Alex: What about the risk of disruption to the business during migration?
Sam: This is the most significant operational risk. Business continuity during migration requires careful planning: most migrations use a period of running old and new systems in parallel, synchronising data between them, before cutting over. The cutover itself is the highest-risk moment and should ideally happen at a low-traffic time with a tested rollback plan in case something goes wrong.
Alex: And cost overruns seem to be very common in cloud migration projects.
Sam: Almost universal in large projects. The reasons are consistent: underestimating the complexity of the existing environment, underestimating the data migration effort, underestimating the application refactoring required, and the ongoing cost of running both old and new environments simultaneously during the migration period. A realistic budget needs contingency, not just for technical issues but for the business change management costs that are often forgotten in migration planning.
Alex: Really important practical knowledge. Thanks, Sam. We'll close out Unit 6 with a look at cloud security and compliance.