Top Four Reasons Public Cloud Migrations Fail

July 17, 2016

Michele Borovac

An NTT Communication survey in Cloud Reality Check 2015 found that 41% of the 1600 ICT decision makers who responded thought that “migrating complex apps to the cloud is more trouble than it’s worth.” 47% said that they have “less control over application estate as it moves into the cloud.” Other industry publications express similar sentiments regarding cloud migration. There are many reasons for cloud migration failures, including bad planning, unrealistic expectations, poor project management and more. However, a common theme emerges across the industry: choice of tools for migration is a primary factor in the success (or failure) of migrating IT workloads to the cloud.

When an IT organization wants to engage in cloud migration, it’s important to plan and use the right tools. Shipping the on-premises IT environment to the public cloud is an operationally sensitive and sophisticated business process. Cloud migration typically affects all components in the enterprise’s data center facilities and resources, including production workloads, storage and compute, and supporting resiliency and security. Existing cloud migration tools and methods have serious, fundamental shortcomings, especially when used to migrate stateful enterprise applications. As a result, cloud migration is not successful for many cloud IT shops.

In this article we list four business and technical factors that may cause cloud migration to fail.

1. On-premises IT environments must be converted to in-cloud facilities. For example, a local, on-premises VM must undergo conversion to the target cloud environment (AMI in AWS for example). The process of converting a complete operational stack causes migration to become a one way event — applications are either in the cloud or on-premises. Once local VMs are turned to public cloud AMIs, it is nearly impossible to pull them back into the local data center; as converting back into local infrastructure is both complex and time consuming. Once VMs and data are settled in the cloud environment, they are also in a proprietary processing architecture and data format. This situation leads to a practical vendor lock-in with no simple way to smoothly move production workloads elsewhere, once migrated. Your public cloud infrastructure provider now owns and controls your data and processing facilities.

2. Compute (VM) and storage (VMDK) are tightly coupled.With existing technologies, cloud migration is an “atomic” event. Viable migration requires shipping full volumes of data in bulk operations, and processing cannot begin before the data is fully shipped and persistent in target formats. In addition to migrating and configuring the VMs, all the datasets consumed by the migrated IT applications must also be moved and converted to the appropriate IaaS storage formats. Shipping large datasets over WAN to the cloud, converting them to target storage formats is a lengthy process, and the system is not fully available to business applications until the process is successfully completed. A typical example: To transfer 10 TBs of data over a 20 Mbps network link takes 50 days, with the link 100% utilized.

Replication-based migration approaches will typically move a copy of the data, but keep the application running on premises. Changes accumulated during the transfer process will then require additional synchronization, taking yet more time and complexity. For a business critical, production workload, this is unacceptable. Furthermore, this process is inefficient, because in most situations, only a small portion of data is needed for business applications to function. Although most data is rarely accessed, cloud migration tools today are oblivious to data usage and, therefore, operate as if every last bit is an absolute necessity. For IT shops wishing to address this inefficiency and to conduct their business in an efficient hybrid cloud mode (where IT is divided between the cloud and the private data center), this is likely a show stopper.

3. Cost inefficiency due to expensive cloud block storage. While processing is billed on a pay-as-you-go basis (EC2 instances, for example), storage is billed by capacity and format. Unlike VMs, storage cannot be “turned off”—storage consumes cloud resources 24/7/365. Even if only a small portion of a dataset is used frequently, payment is for the full volume, as long as the dataset is stored in the cloud. Business applications mostly require block storage (EBS volumes, for example), which is the most expensive form of cloud storage. Due to availability requirements, with the current technologies, IT shops cannot keep their block datasets on-premises to be used by cloud VMs only when required. As a result, IT shops pay expensive high performance rates for rarely used storage, even when the storage-consuming applications are not running.

4. Control is delegated to cloud service providers. For many IT organizations, government regulations and industry standards are essential facets of doing business. In these situations, cloud storage of sensitive data may present issues. When datasets are migrated to the cloud, it becomes difficult, if not impossible, to verify compliance. Security and safety is out of the hands of the IT shops. For many businesses, this can be a show stopper, forcing them to forego the benefits of cloud IT due to compliance limitations.

Final Note

In many business situations, cloud migration initiatives fail due to the four significant factors presented. To plan a successful cloud migration, enterprises should consider their impact on existing and future IT operations and make sure to choose migration technologies that can help mitigate these risks and better support data center modernization goals.