Cloud Migration

What is Cloud Migration?

Cloud migration is the process of moving existing application workloads to the cloud. It’s an integral part of cloud adoption for most organisations.

The Cloud Adoption Process

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:

Opportunistic

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.

Cloud-First

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.

All In

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.

Cloud-Native

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!

Cloud Migration Strategies

You 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

Lift & Shift

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.

Pros:

• Easy to get started with automated migration tools.
• Fast migration achieved by moving VM images to a cloud environment.

Cons:

• ‘Garbage in, garbage out’ – you move existing problems from on-premise to the cloud.
• You don’t leverage advanced cloud options like platform-as-a-service (PaaS) and software-as-a-service (SaaS) to lower costs, improve security and increase availability.
• Failure to optimise cloud images and cloud operations strategy results in high TCO.
• Opportunities to streamline the application portfolio are missed, resulting in duplication and waste.

Evolve

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.

Pros:

• Modernise your application portfolio, and your cloud operations strategy, on an application-by-application basis
• Leverage cloud vendor hosting services to improve availability, redundancy, security, monitoring etc.
• Use DevOps technologies like infrastructure-as-code, configuration-as-code and containers to lower TCO and operational overheads.
• Conduct an application portfolio assessment to identify outdated, unsupported and duplicated applications. (On average, 30% of applications can be decommissioned instead of migrated, saving time, effort and money.)

Cons:

• Slower than Lift & Shift so perhaps not suitable if you have extreme time pressure e.g. a datacentre exit deadline.
• Will uncover large amounts of technical debt that might need to be repaid as part of the migration e.g. unsupported applications or operating systems.
• Requires modern DevOps & Cloud skills which you may not hold in-house.

Cloud-Native

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.

Pros:

• A cloud-native rewrite of key applications almost always results in the lowest TCO. You can take advantage of new technologies (like serverless) and new application patterns (like microservices architectures).
• A phased approach is possible i.e. deconstruct an existing monolith over time into cloud-native services.
• You can provide exciting new features for customer by integrating new functionality (e.g. cloud-vendor AI/ML platforms) with your migrated or brand new applications.
• It’s possible to unlock new business models and revenue streams e.g. through a SaaS approach.

Cons:

• Any application development project is inherently risky (8% of Agile and 21% of Waterfall projects fail completely and ~50% are challenged on schedule, cost or scope).
• Third party software might not support a cloud-native approach. This may require integration of virtual machine-based infrastructure-as-a-service (IaaS) into your cloud-native strategy, which can be complex depending on the vendor.
• Good cloud-native software development entails the adoption of practices like Continuous Integration/Continuous Delivery (CI/CD) and Test-Driven Development (TDD). Not every Dev&Ops team has the right skills for this (although expert external support is available from Sourced Group).

Cloud Adoption Frameworks

Before you get started on your cloud migration process, take advantage of the excellent guidance available in cloud vendors’ Cloud Adoption Frameworks.

The Amazon AWS Cloud Adoption Framework

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.

Microsoft Azure Cloud Adoption Framework

The Microsoft Azure CAF offers a more linear step by step adoption process, underpinned by governance and management.

Well-Architected Framework

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.