Best practices for migrating between public clouds

Historically, cloud migration usually meant moving on-premises workloads to a public cloud, like Amazon Web Services (AWS) or Microsoft Azure. And because so many businesses were keen to get out of the on-prem infrastructure management business by moving to public cloud, there were plenty of guides and tools to help with an on-prem to public cloud migration.

But now that about half of enterprises have workloads in the public cloud, moving applications and data from on-prem server rooms or private data centers into a public cloud environment is no longer the crux of many cloud migration strategies. Instead, businesses are facing a new challenge: How to move workloads from one public cloud to another.

Unfortunately, because cloud-to-cloud migration is a more novel type of use case for many companies, fewer resources are available to help guide the process. While cloud providers offer some tools (like Azure Migrate, which can move AWS-based server instances into Azure, and AWS Server Migration Service, which can move them in the opposite direction) that can migrate certain types of objects between clouds, they often don’t address issues like reconfiguring complex networking setups or the need to move hundreds of terabytes’ worth of data over network connections that offer limited bandwidth. And few guides to cloud migration offer best practices on how to perform a cloud-to-cloud migration.

That’s why I’m writing this article — to provide guidance on how businesses can best approach the task of moving workloads from one public cloud to another. Having helped a number of enterprises plan and execute cloud-to-cloud migration projects, I’m familiar with the challenges that commonly arise, as well as how best to work through them.

Why migrate between clouds?

Before diving into tips on how to migrate from one public cloud to another, let me address an obvious question: Why might a business want to do this in the first place?

One common scenario is cases where a company that uses one public cloud acquires or merges with another one that uses a different cloud. After the reorganization, the IT department may decide to consolidate around a single cloud platform.

It may also simply be the case that a given cloud is no longer the best fit based on price, performance or data center locations, prompting an organization to move to an alternative public cloud platform.

You may also be wondering why a company wouldn’t opt for a multicloud strategy in which it keeps some workloads in one public cloud while placing others in a different one. That would eliminate the need to move all workloads from one cloud to another. Wouldn’t the flexibility of multiple clouds beat being locked into a single platform?

The answer is that, while multicloud certainly has its benefits (such as providing flexibility to pick and choose between more cloud service options, which can help optimize the balance between cost and performance), it also has drawbacks. One of the biggest is added complexity: More clouds mean more to monitor and manage, more tools to juggle, more potential performance and security incidents to troubleshoot and so on. Multiple clouds also typically require the availability of IT staff who are proficient in each cloud environment; it’s challenging to find engineers who are experts in more than one cloud. For these and similar reasons, it sometimes makes more sense to get out of one public cloud entirely rather than try to operate across clouds.

The challenges of cloud-to-cloud migration

At first glance, moving from one public cloud to another may not seem especially difficult. All public clouds offer the same core types of services, and they all operate based on the same concepts.

Yet, when you dive into the details of a migration plan, you start to realize that public cloud platforms are not as consistent as they might seem. On top of that, there are additional challenges that can complicate or slow down migration.

1. Service feature differences

Although the basic types of services that public clouds offer are the same, their implementations are different — which means you can’t simply lift-and-shift a workload from one cloud to another and count on it working flawlessly. You may need to overhaul configurations.

As an example, take CosmosDB and DynamoDB. These are both managed NoSQL databases on Azure and AWS, respectively. At a high level, they do the same thing. But under the hood, they handle operations like replication and indexing in different ways. They are also priced differently, and there is no guarantee that a configuration that optimizes performance for one offering will yield the same results for the other. For these reasons and more, you can’t just pull data out of Cosmos and dump it into DynamoDB. You have to perform a complex migration process that requires taking the data offline, transforming it and then moving the results into DynamoDB. You may also need to make significant changes to your database configuration and your data structures.

2. Latency challenges

How fast it takes to move data within a public cloud depends in significant part on where a given workload or service is located within that cloud. Moving data between cloud regions when the regions are on the same continent will generally involve less latency than transferring data across the world, for example.

Since the regions of each cloud provider are different, latency could become a problem following a cloud migration if you’re not strategic about which regions you choose in the new cloud and how you configure them. Even if you choose regions located in the same parts of the world as those you used in the original cloud, intra-cloud latency rates could vary because each cloud provider’s specific data center locations are different.

Latency problems may also arise when an organization uses SaaS services or on-prem applications that are not hosted in the cloud, but that need to send or receive data from resources hosted in the organization’s public cloud environment. In that case, the proximity of each cloud provider’s data centers to the location where SaaS and on-prem resources are hosted can impact transfer network speeds and delays — so it’s essential to understand cloud dependencies and interdependencies across the organization’s entire IT estate.

3. Rebuilding automations

Cloud providers offer automation tools that help integrate workloads and move data. Unfortunately, they usually depend on tools (like AWS Config, CloudFormation or SNS, to name just some examples from the AWS cloud) that work only on one cloud, and that depend on configuration settings and languages specific to that cloud.

Here again, the result is that you can’t simply move your automation tooling from one cloud to another. You need to translate or rebuild it — unless the tooling happens to consist of third-party, cloud-agnostic solutions, although even in that case, you may still have to update your configurations because what works in one cloud may not work in another.

4. Cost variations

Cloud pricing details can vary significantly from one cloud to another, even for comparable types of services. As a result, a workload configuration that is optimal from a cost-performance standpoint on one cloud may prove suboptimal on another — meaning that you’ll end up wasting money if you don’t modify the configuration during the migration process by evaluating the new cloud’s pricing details.

5. Network bandwidth limitations

The simplest way to move data from one public cloud to another during a migration is to use a VPN connection. Unfortunately, VPN connections use the public Internet from the cloud providers, which limits data transfer performance. It can also prove much more expensive than a dedicated connection when moving large amounts of data.

For these reasons, if your cloud-to-cloud migration involves many terabytes’ worth of data, you could face major logistical and cost barriers.

How to streamline migration between public clouds

It would be nice if there were a magic bullet — or, at least, some “automagical” migration software — that would mitigate the cloud-to-cloud challenges I’ve just described.

Unfortunately, there’s not. Moving from one public cloud to another is complex, and requires a lot of time and effort,  no matter how you approach it.

However, techniques and best practices can help smooth the process as much as possible. Here’s what I recommend.

Plan, plan and keep planning

It’s impossible to overstate the importance of planning a cloud-to-cloud migration carefully. Formulate thorough plans, test them by performing a dry run migration with dummy workloads, figure out what didn’t work as expected and then reformulate your plans. The more time you spend on planning, the lower the risk that you’ll run into unanticipated roadblocks once you’re in the midst of a migration.

Establish realistic timelines

It’s important as well to set realistic expectations for timelines. Often, dictates on how long a migration should take come from leadership, who don’t always understand the intricacies of a migration project.

It’s better to be transparent upfront in saying that migration may take significantly longer than leadership would like, rather than promising a fast migration only to have to push back the timeline again and again once migration is underway.

Migrate non-critical workloads first

Once you begin executing a migration, it’s a best practice to start with non-critical workloads, like those that are in development and testing. If something goes wrong due to a planning oversight, it’s preferable to discover the issue when you’re moving something non-critical. Save your mission-critical apps and data for later stages of migration.

Pause new deployments

A critical, but easily overlooked, consideration during cloud migration is to ensure that you pause new deployments for applications, as well as platform modifications or configuration changes, during the migration period.

You don’t want your developers to deploy a new release of an app to one cloud while your IT team is in the process of moving the older version to another cloud. If you do, they’ll end up having to perform the migration all over again. Likewise, any changes applied to one cloud platform during migration will need to be reproduced in the new platform, adding unnecessary complexity.

To avoid this issue, make sure your development teams are looped into migration schedules and statuses.

Use interconnection services

While the Internet connections between public clouds are relatively slow, one way to boost bandwidth — and speed up migration — is to use a cloud interconnect. Interconnect solutions (such as Megaport, NuSummit and Equinix Fabric, to name a few examples) provide dedicated, high-bandwidth connections between clouds, allowing you to migrate data much faster.

Interconnects are not cheap, but you can turn them off once migration is complete, so there’s really no reason not to take advantage of this type of service as a shortcut that speeds up cloud-to-cloud migration.

Cloud-to-cloud migration: A complicated but essential process

In a perfect world, moving from one public cloud to another would never be necessary because the cloud currently hosting your apps and data would forever be the ideal fit for your organization.

But in the real world, it often happens that your current cloud is no longer the best cloud – and that you need to migrate to a new public cloud as a result. The resulting process is inherently complex, but with the right tactics — and plenty of careful planning — you can avoid the risks and roadblocks that complicate cloud-to-cloud migration projects.

Scott Wheeler is cloud practice lead at Asperitas. He helps organizations implement the most complex and demanding cloud solutions, and utilize hybrid and multi-cloud to increase innovation, reduce time to market, contain costs and deliver enterprise-scale security.