When we launched our GA release in 2013 we spoke with dozens of analysts, pundits and prospects about automated cloud migration and hybrid cloud as a new operating model. In those early days few believed that automated cloud migration was possible. Some of our first customers even confessed their initial disbelief, before a proof of concept was completed.
As a tech entrepreneur it was one of my most enigmatic -and educational- career moments. Across months of discussions clear patterns emerged. While some projects were successful, many more had failed; and when they failed there were usually one of three very common reasons. More about that later.
Early Adopters and Mixed Experiences
When it came to legacy workloads, those who had not tried had the usual reservations about the cloud, including unmet security and compliance requirements. Today there is a general consensus among experts that the cloud providers are offering superior infrastructure layer security to most organizations.
That explains why today more enterprises are looking to the cloud to increase agility and reduce costs. The challenges of cloud migration are then more relevant than they were two-plus years ago. So let’s review the things that went wrong when the early cloud migration pioneers experimented with first generation tools and partners.
Let’s first acknowledge the difficulties of migrating a legacy workload into the cloud. Cloud migration requires more than image or server conversion. There are usually numerous services that are necessary for a workload to run in the cloud; those services need to be extended into the cloud.
Extensive Manual Processes
Most data center environments are complex, especially those with hundreds of servers interacting with large databases and aging ecosystems of specialized network appliances. Adding to the complexity is a time factor.
Apps and databases are frequently updated. Many cloud migration tools do not support live migration, they require an app and database to be shut down before or during migration, which is akin to changing horses in the middle of the stream.
Without live migration, cloud migration costs and risks can increase significantly while in the midst of a project.
In the early days of cloud migration many IT execs cancelled projects because the initial costs outweighed the benefits. Those costs were high because of the hours required to discover all of the services and to manually create the scripts needed to extend those services into the cloud. Costs and risks escalated as new services were discovered and needed to be extended.
Without live migration support initial costs could pale in comparison to the midstream costs. So early migration projects were manually-intensive, expensive and risk-laden.
As the early tools were used for increasingly complex environments, the power of their automation capabilities were quickly degraded. In the wake of their deployments were a lengthy list of failures. You can watch my 3 minute interview with InformationWeek at Interop 2015 for more background.
So let’s get to the three reasons why your cloud migration project will fail, based on interviews with IT execs who were the early adopters of cloud migration for premise apps.
1) Inadequate Tools — (Tools that Require 100% Virtualized Workloads)
There were perhaps a dozen “automated” cloud migration tools being offered two years ago when we went GA, but most were developed based on virtualized platforms. As long as the environment was 100% virtualized, the critical discovery and duplication of app and services into the cloud could go smoothly. But add even a single physical server into the mix and the benefits of automation would be offset by escalating dependencies upon manual services and heightened deployment costs and risks.
While most of those vendors today claim to support physical and mixed environments, their track record is worth validating. It is usually a question of how much manual labor will be required. Then there is the live migration question, raised earlier.
To increase your potential for success you can ask your migration partner specifically about software-based discovery and provisioning, and the ability of their software to integrate with leading database front ends. Otherwise, cloud migration will continue to require extensive manual processes and could take weeks or even months for a project that could be completed in days and at a fraction of the cost.
2) Insufficient Service Extensions — (Especially Network and Security Services)
We recently conducted a survey of IT executives responsible for disaster recovery and 55% said that they would consider the cloud as a secondary data center if they could extend network and security controls into the cloud. As mentioned, the challenges for the early cloud migration efforts often involved the costs and risks required to manually extend these critical services into the cloud.
Today cloud providers support critical enterprise-grade services with robust APIs, so software that extends key services can help your team to implement them quickly and without as much effort. Integration with the APIs would also allow for advanced hybrid cloud operating models, including cloud DR and cloud dev/test.
3) All or Nothing Mindset — (Lift and Shift versus re-Architecting, etc.)
When discussing hybrid cloud operating models with the IT community we would always hear from a consultant who argued that all apps should be re-architected before being migrated to the cloud. Note: many of them were indeed cloud experts who offered services related to optimizing apps for the cloud, yet their point was and still is valid.
Some apps may experience degraded performance in the cloud yet others might see performance improvements, based on the nature of their existing environment. That is, performance can substantially improve without having to make the upfront investment in re-architecting the app. You can get both sides in a recent TechTarget article: When to Adopt the Lift and Shift Cloud Migration Model. Here is mine, from Kristin Knapp’s timely article on cloud migration:
“If your investment in a data center is costing you today twice as much as the cloud, why wait?” Ness said. Some CloudVelox customers will lift-and-shift an application to reduce on-premises infrastructure costs in the short term, and then re-architect the app after it’s in the cloud, he said.
The lift-and-shift model is also a solid choice for cloud disaster recovery, said Jonathan Feldman, CIO for the city of Asheville, N.C., who is also a CloudVelox customer.”
One of our early Fortune 1000 customers asked us to do a proof of concept for their 6TB Oracle ecommerce stack. After a week they were up and running in AWS; and the app environment was running better on the cloud than in their (albeit overburdened) native environment. They were quite surprised with the results as they had been told that they would have to re-architect their app AND that the entire cloud migration process would take between three and six months. Yes, their partner was using outdated cloud migrations tools and they would have had to pay the price.
There are certainly many other reasons a cloud migration project could fail. For example, there may be services running on premise that are not supported in the cloud you are targeting; or it could be something quite simple, like your app is not be licensed to run on the cloud. The best way to find out is to set up a technical briefing or even a no cost proof of concept. Then you can decide what kinds of solutions will work best and which will need to be re-architected or need extra professional services for unique compliance or security requirements.
==> Read about Cloud Migration success at InformationWeek.