Migrating workloads to public cloud

According to the 2018 International Data Corporation (IDC) Worldwide Semiannual Public Cloud Services Spending Guide, the market is expected to gain five-year compound annual growth rate (CAGR) of 21.9% with public cloud services spending totaling $277 billion in 2021. If that’s the likely forecast growth in five years, what will happen in a decade? The dominance of the public cloud appears likely.

As the public cloud becomes a multi-billion dollar business and the IaaS market share of computing continues to grow, enterprises are leveraging the public cloud more and more each year. But even though self-provisioning of new workloads in public clouds is simple, migrating existing services to the cloud requires more preparation. A common perception is that migrating existing workloads to the public cloud — especially those with a lot of data — is complex, time consuming and risky. With the right planning, however, enterprise IT organizations can rapidly establish good migration practices to accelerate migrations and lower risk. Plus, migration technology is evolving quickly to support the enterprise.

Read on for essential tips to guide IT organizations through the four key parts of the migration process: Assess, Plan, Migrate, and Optimize.

Phase 1

Assess: Lay the migration groundwork

First, identify your migration team. It is likely you’ll be working with other members of your organization, so determine who those stakeholders are now and what their respective levels of involvement will be. For example, involving people from the security and application teams early in the process can help you identify and remediate or bypass issues that might have otherwise occurred mid-migration. Educating these key players about your organization’s cloud strategy will help teams identify their roles in the overall migration effort.

Once you’ve figured out your team of internal stakeholders, identify the applications slated for migration. It’s likely that your enterprise has hundreds or even thousands of applications to migrate to the cloud, so where do you begin? Start by determining which applications should be moved to the cloud first.

There are many variables that will impact priorities, including identifying application dependencies, cloud-readiness, application SLAs, physical or virtual infrastructure, etc. Other variables that will also be crucial during the migration include server names, IP addresses, # of VMs per application, VM OS and service pack, CPU, memory, attached disk space, shared storage, databases (size and type), licenses, bandwidth usage, and integrations.

Due to all the information you’ll need for your applications, we recommend preparing a thorough questionnaire that outlines all of these crucial pieces of information. You can send this to application owners to help evaluate migration readiness but also to have key information easily accessible during the migration itself.

It is worth noting, however, that application owners may not even know all the required information which is why it is often invaluable to rely on a discovery and assessment platform that can automate this process. The end result will be a detailed overview of your IT landscape and estimates of what your on-premise versus cloud costs will be.

Phase 2

Plan: Pick your strategies

Applications

If you do your research on cloud migration you will find that there are essentially three cloud migration strategies that IT can use when moving to the cloud:

➊ Lift and shift (and possibly optimize, too): Redeploy applications to the cloud without making changes, or make select post-migration reconfigurations to take advantage of cloud-native tools (e.g., replace SQL with Google’s CloudSQL)

➋ Improve and move: Start taking existing applications and modernizing them on-prem before migrating them into the cloud (e.g., convert VMs to containers, then migrate those containers into Google’s GKE).

➌ Rebuild: Take existing applications that are too difficult to move and rebuild them from scratch in the cloud. In some cases, you might have an application that is simply too old to migrate, so rebuilding is your only real option.

All three options are viable, and in many cases you may end up leveraging all of them at different stages of your migration journey. Usually, though, the smartest and fastest strategy is to start with the first option and move applications into the public cloud first. Once apps have been migrated to the public cloud, IT can evaluate performance and optimize as appropriate. That could mean simple changes like adjusting instance sizes or changing some of the on-prem functionality to be more cloud centric (like the SQL to CloudSQL example).

Data

Migrating an application usually involves migrating all of its data along with it. Consider the amount of data associated with each application, where it is currently stored, and how frequently it is updated. If you are using the cloud for disaster recovery, it may be tempting to try and leverage those same disaster recovery solutions for cloud migration, too. But cloud migration is a significantly different use case. If you are moving live applications, consider solutions that were purpose-built to address the associated complexity of keeping application data synchronized during the migration and through cutover.