How to Prepare for Cloud-to-Cloud Migration

Oh yes. It’s happening. Consider making it a part of your overarching cloud strategy to make the process less painful.

What do the following have in common? Salmon, Canadian Geese, Monarch butterflies, and applications.

If you guessed all of these are things that migrate from one place to another, pat yourself on the back.

Now, usually when we talk about cloud migration we’re talking about going from on-premises to off. With good reason. There’s plenty of data (our own included) that indicates a rise in the adoption of public cloud usage. What we almost never talk about is the migration that occurs in reverse. I can hear the cries of “Heresy!” now, but let’s be realistic – it happens, and more often than you might think.

For example:

42% of respondents who adopted a public IaaS in production indicated that “they intend to migrate from their current strategy, either within the next four years or as an ongoing process.” 70% of those “anticipated moving to a hybrid cloud rather than switching exclusively to a private cloud solution.” 

The reason? The most common factor was reducing costs (67%) followed by security and stability. That’s borne out by stories like this the one about Pubmatic’s migration from public to private cloud. Costs were a major driver.

But others are migrating in the opposite direction, as we’ve all heard. A lot. 57% of those using a private IaaS platform “intend to migrate to a public or hybrid cloud with 77% of those respondents indicating that they plan to adopt a hybrid approach.”

Their rationale? Scalability (71%) followed closely by flexibility. Costs came in third, at 50% of respondents.

Scalability drives folks to the public cloud, and long term costs appear to drive them back home to a private cloud.

The reality is that most organizations are neither a “public cloud” shop nor a “private cloud only” shop. They are multi-cloud, even after they move apps back and forth. The reality can be proven by examining development trends, like those reported by Cap Gemini in its “Cloud Native Comes of Age” report which noted that “One-sixth (15%) of respondents’ firms’ new applications are built today in a cloud-native environment.”

Now, if 15% are cloud-native, that implies the other 85% are not. That probably includes mainframes. And client-server. And three-tier, web apps. Oh, and microservices in containerized environments, too.

The modern enterprise organization is not only multi-cloud, it’s multi-generational in terms of its application architectures.

Which means the chances that you will migrate some sort of app from on-premises (private) to off-premises (public) or vice-versa is pretty good – because there are more of them than there are cloud-native apps. What’s important, then is to incorporate that premise into your cloud strategy. In other words, you need to understand what you can do up front to make the (perhaps inevitable) process less painful.

Prepping for Cloud-to-Cloud Migration

One of the first things to consider is the expected life span of the app you’re moving. If it’s long term, it’s a candidate for cloud-cloud migration in the future. If it’s not – because it’s promotional or marketing or event-based – then you can skip right on to the end of this list and deploy. 

Now that you’ve determined the app is going to be longer-lived, you should think about how you’re going to scale and secure the app.

The quick (and easy) answer if the app is cloud-native is “we’ll use services from the cloud-provider.” That’s a valid option, just as “we’ll use what we’ve always used” is a valid option if the app is going to live in an on-premises private cloud. However, both options are fraught with potential risk downstream that you’ll be unable to smoothly migrate the services and/or policies from one cloud to another. It’s time to take a hard look at what you’re using now for scale and security and determine whether those application services can migrate along with your app – in both directions.

Given that enterprises use an average of 16 application services to deliver and secure their apps, this is an area that can significantly impede your ability to support apps that may migrate, never mind supporting them in a multi-cloud world. Note that some of those 16 services will need to be cloud-native services. Basically, if you look at at your data path as being comprised of corporate, shared application services and per-app services, you can begin to see that the architectural division closely matches that of the line drawn by public cloud providers at the infrastructure layer. It’s not a perfect division, but it does provide a logical separation that offers guidance on which services need to be “multi-cloud” and which ones you can rely on cloud native or traditional data center services.

The more consistency in the application services you use across clouds, the easier it is to migrate between the two (or three or four or more) because there’s less tying you down. This approach has the added benefit of extending automation efforts to reach the public cloud and relieve the business, at least, of operational costs associated with maintaining separate operational staff and procedures.

Cloud was inevitable. So is multi-cloud. Which ultimately means there will be migration between them. Being attentive to dependencies and using cross-cloud application services before the initial decision on where the app should be deployed is made can make the process less painful.

Make the idea, at least, of cloud-to-cloud migration part of your top-level cloud strategy. Being prepared can save you from a painful (and costly) migration later on.