Ready to migrate to the cloud? This guide outlines key steps and important considerations.
If you’re new to the cloud, read ‘what is cloud computing?’ first, then come back for more detail on cloud migration steps.
Cloud migration is the process of moving existing application workloads to the cloud. It’s an integral part of cloud adoption for most organisations.
Cloud migration is just one part of cloud adoption. So, before we drill down into the mechanics of cloud migration, it’s worth understanding how it fits with the bigger picture.
Most organisations go through four phases of cloud adoption:
Many cloud journeys begin with a standalone digital project. A new solution is built in the cloud because it provides fast and cost-effective access to compute resources. The activity is often ringfenced, so the main IT department doesn’t get involved.
In large organisations this ad hoc approach is often replicated multiple times. Different teams select different cloud providers, resulting in a ‘multi-cloud’ scenario.
Eventually these opportunistic cloud experiments reach a tipping point. Rising costs coupled with security and compliance concerns, or strategic need for a more coherent cloud strategy, drive a transition to the cloud-first phase.
This is where all new projects are deployed on cloud by default. And it usually sets the clock ticking on datacentre use.
From here, you need a clear strategy to underpin decisions such as which cloud migration steps to take when.
Establishing a Cloud Centre of Excellence (CCoE) is widely regarded as the best way to maximise benefits. (Although we prefer the term ‘cloud enablement team’.)
Training is important too. A cloud-first strategy should be linked to clear plans for skills development and change management.
By now, you’ll be developing engineering principles for the deployment of applications on the cloud. This is good. But realise that flexibility and pragmatism will be needed during ‘all-in’ cloud adoption.
Ultimately, large-scale cloud migration becomes inevitable.
This phase often dovetails with cloud-first. And pressure can mount, especially if there’s a hard deadline linked to datacentre renewal dates.
Assessing the application portfolio helps determine the right migration strategy for each application. Sometimes it’s better to retire an application instead of migrating it. Or you might opt for a two-step process of ‘migrate first, modernise later’ for some workloads. Just make sure you have sufficient funding to ‘modernise later’. Otherwise you may end up with an out-of-date, costly and labour-intensive cloud application portfolio.
The cloud-native phase involves building or rebuilding applications from scratch to leverage all the cloud capabilities on offer.
Much of the time, cloud-native strategies have two goals: to add new capabilities and reduce total cost of ownership (TCO).
Going cloud-native brings many benefits, particularly in relation to TCO. But it’s important to walk before you run. So, hone skills on simpler jobs before tackling more complex applications. There are many application architecture choices available for cloud-native software development, and making the wrong choice can be expensive!
Read our cloud migration whitepaperYou may have heard of Gartner’s 5 and AWS’s 6 ‘R’s of cloud migration’.
With so many potential cloud migration processes to choose between, it can be hard to know where to start.
To help with this, we group the various cloud migration types into three migratory paths. Each has pros and cons, and you’ll probably use all three to some extent for different applications
This is what Gartner and AWS refer to as ‘rehosting’. It’s the quickest and simplest route to the cloud, involving bulk replication of existing (normally virtualised) infrastructure onto an infrastructure-as-a-service (IaaS) hosting platform.
Lift & Shift is a familiar option for those from a traditional infrastructure background. Sometimes it’s the only viable option if there’s a datacentre renewal date looming or an imminent need for a hardware refresh.
The main drawback of Lift & Shift is that you replicate existing problems in the new cloud environment. On top of that, hosting costs will almost certainly be higher until you modernise. Nevertheless, it’s a safe and reliable first step to the cloud as long as you review applications later and take steps to modernise where needed.
Tip: DevOps approaches to building out the ‘cloud landing zone’ help reduce TCO and improve future manageability when you migrate to the cloud using Lift & Shift.
Evolve is the middle ground between Lift & Shift and a full rebuild. It encompasses various cloud migration approaches, referred to by Gartner and AWS as ‘replatforming’, ‘revising’ and ‘refactoring’.
With this type of cloud migration, you rebuild the core hosting infrastructure so it’s optimised for the cloud, then re-deployapplications into the new cloud environments.
This strategy is application-centric. It means you fully examine each application workload and decide the right cloud-optimised hosting and management strategy to meet its needs while optimising long-term ROI.
This presents an excellent opportunity to embrace DevOps patterns, practices and tools. Applications might be containerised with Docker and managed by Kubernetes. There could be a shift to PaaS options like Azure Web Apps or AWS’s Elastic Beanstalk. An ‘everything-as-code’ approach might be used to redeploy applications in freshly defined, immutable VM-infrastructures using tools like Hashicorp Terraform and Puppet Enterprise.
The Evolve pathway may require some code changes to optimise an application’s fit for the new hosting model, for example improving reliability, operability or hosting costs. But it avoids large-scale rearchitecting or significant recoding.
Existing codebase can be reused in the more cost-effective cloud environment and you don’t need to dramatically reskill dev teams or adopt new languages or frameworks. However, upfront expense is higher than with Lift & Shift.
Unfortunately, the Evolve pathway invariably uncovers large amounts of technical debt.
A common example is the discovery of applications or operating system versions that are no longer supported by their vendors. These will need to be modernised during an Evolve migration. Also, it’s often the case that many applications are poorly documented, and nobody is exactly sure how to re-deploy them.
This level of technical debt is usually due to long-term under-investment in IT, particularly in the decade after the 2008 Global Financial Crisis. When you migrate to the cloud, the debts become due, which can be a cause of migration budget blow-out.
To fully exploit everything the cloud has to offer, you need to rewrite applications for the new environment. This maximises both developer and operational productivity, unlocking better agility, scalability and speed-to-market. But the stakes are high. Going cloud-native requires major redevelopment, which is risky when you consider the tendency of software projects to run over time and budget.Many organisations migrating to the cloud start out with the idea that they will go cloud-native all the way. They want to rearchitect everything, move to microservices and rip out all the technical debt that’s putting systems at risk.
But then reality hits.
It’s rare for in-house teams to combine intimate understanding of core applications with deep knowledge of the target cloud platform. Coupled with the scale and complexity of legacy systems, this makes a rapid transition to 100% cloud-native unattainable for most.
Before you get started on your cloud migration process, take advantage of the excellent guidance available in cloud vendors’ Cloud Adoption Frameworks.
The AWS CAF offers six perspectives on cloud adoption outlining what you need to consider as part of your cloud journey.
Three of the six perspectives are not technology related. They focus on the business, people and organisational governance changes required as part of cloud adoption. This is a powerful aid to land the message that cloud isn’t just technology but has ramifications for the relationship between technology and the wider business. This is why we believe that cloud adoption is a great time to introduce DevOps into your organisation as part of a wider IT transformation agenda.
The Microsoft Azure CAF offers a more linear step by step adoption process, underpinned by governance and management.
Both cloud vendors offer best practice guidance for the build and management of application workloads in the cloud. This is presented via the Well-Architected Framework. AWS and Azure use the same five pillars: Operational Excellence, Security, Reliability, Performance Efficiency and Cost Optimisation.
You might be wondering which migration strategy is the right one for you. Read the next tutorial in our Cloud series, What’s the Best Way to Migrate to the Cloud? This tutorial will take you through the best way to move to the Cloud.
This was part two in our Cloud tutorial series
Read the other parts here:
Read this whitepaper to learn how to supercharge your Cloud migration with DevOps.
This diagram helps to understand the 3 common pathways to the cloud - lift & shift, evolve and “Go Native” (rebuild).
In this live webinar a DevOpsGroup panel discuss the five essential characteristics of cloud computing that make you 23 times more likely to be an ‘elite’ performer.