Moving data from one cloud provider to another is not easy. Whether you’re dealing with gigabytes, terabytes or petabytes, cloud-to-cloud migration is a slow and expensive procedure. Nevertheless, there are times when it is worth the effort, and in some circumstances it may represent the only legitimate way forward.
Why consider a cloud-to-cloud migration?
The need to streamline operations following a merger or acquisition often results in business leaders looking at cloud-to-cloud migration. However, while it may seem like a rational step, it’s possible that the costs and disruption will outweigh any benefits. It’s important to fully understand what’s involved, then evaluate potential repercussions, before undertaking the move. Do you really need a wholesale move from one cloud provider to another? Or are there alternative approaches that could achieve the desired business outcome in a more effective way?
In some situations, the rationale for cloud-to-cloud migration is more clear-cut. It may be essential to meet business-critical requirements surrounding data residency or data sovereignty regulations. But the process still needs to be interrogated at the outset, and handled with care throughout.
What makes cloud-to-cloud migration so hard?
Cloud-to-cloud migration is not simply a case of transferring data from one cloud environment to another. There are technical matters to consider upfront as differences between resources on the two platforms may require new solutions.
Take load balancers. In AWS these are handled with an SSL termination process whereas in Azure an Azure Application Gateway (APPGW) is required. These are very different beasts. Even seemingly similar systems for use in container orchestration – such as the Azure Kubernetes Service (AKS) and Amazon Elastic Kubernetes Service (EKS) – can pose technical challenges. In AWS, Identity and Access Management (IAM) is generally used to control access, but in Azure this would be covered by Azure Active Directory (Azure AD). Any application moving from one cloud provider to another needs adapting to support the method used by the destination environment.
The end solution may look and work in a similar way regardless of where it’s hosted. However, getting it to perform well in the new environment requires change and compromise behind the scenes. And getting there is only half the story. Developers and operations engineers will also need to be reskilled so they can work with the new resources.
How do you decide if it’s worth the effort?
Decision makers need to determine whether the advantages of cloud-to-cloud migration outweigh the risks. Ultimately this comes down to the cost of the migration versus the perceived benefits.
A key factor here is the impact on the team. Consider what skillsets are already held in-house, as well as the repercussions of the move for staff training and (potentially) staff retention.
The maturity of existing cloud-based activity also has a bearing (see our blog on the four phases of cloud adoption). If lots of progress has been made modernising applications and introducing DevOps approaches such as CI/CD this adds further complexity. All the work completed to date will have to be unpicked. Any Infrastructure as Code (IaC) or Configuration as Code (CaC) will need to be rewritten for the new environment.
When we’re working with organisations facing this predicament, we find that an Inception Day orchestrated by one of our consultants enables more informed decision making. If it’s decided that cloud-to-cloud migration is probably the best way forward, a Well-Architected Review is the next step. This assesses current levels of cloud maturity and underpins the development of an effective migration strategy.
We’ve decided to go for it. Now what?
A cloud-to-cloud migration should be approached like any other cloud migration, leveraging guidance from providers’ Cloud Adoption Frameworks. It’s important to understand the target data, the high-level process for moving it and how this will be synchronised. Take time to understand how DevOps automation practices like IaC and CaC can accelerate the migration process. It’s worth looking at opensource multi-cloud tools like Terraform and Puppet, particularly if your teams already have experience with them and can transfer these skills to the new platform.
There will almost certainly be a period of dual-cloud operations where both the new and old environment are in use. Ensuring the appropriate tools and skills are available to manage this critical phase seamlessly and effectively is essential. A systematic approach to training will be needed to get teams ready for the new cloud environment.
Finally, don’t forget that the dual-cloud phase will result in increased costs. Talk to your cloud partner about initiatives that might offset some of this, such as AWS’ Migration Acceleration Program (MAP).
We’ve decided to forget it. What are the alternatives?
In many cases, alternative approaches can achieve the desired business outcome without the expense and upheaval of a cloud-to-cloud migration.
If cost optimisation was the initial driver for considering the move, there’s a wealth of options that can be explored. Running through a Well-Architected Review with a focus on cost will help identify opportunities for cost-saving on your current platform. Most cloud vendors offer enterprise agreements that can unlock further cost savings, especially in relation to legacy software. Implementing DevOps practices and rearchitecting for better performance in existing cloud environments can also overcome or compensate for some challenges.
Check out some of our previous blogs for inspiration:
Colin Barker’s recent post is worth a read if you’re weighing up the pros and cons of cloud-to-cloud migration. He looks at inherent issues with like-for-like comparisons and options for software licences as well as multi-year cloud deals.
Ed Pearson has written about practical ways to improve cloud cost control. He talks about the need to evolve and modernise applications to leverage the full benefits of cloud computing.
And Steve Thair champions product-centric IT as a way to make businesses more adaptive and customer-focused. This post covers everything from cohesion and collaboration to smarter budgeting and striking an effective balance between stability and innovation.