What is your best (or worst) cloud migration story?
Sure, everyone’s moving to the cloud. But as any respectable IT guy will tell you, that’s easier said than done.
According to the 2017 Cloud Migration Survey Report published earlier this year, the biggest challenges companies still encounter when trying to migrate servers to the cloud include minimizing downtime, staying within budget, and preventing performance disruptions. Additional challenges include minimizing data loss, maintaining high security standards, and the technical difficulties of migrating legacy applications and databases.
With so many challenges, it’s critical to make sure you know what you’re doing before launching a migration project. That’s why we’re publishing a five-part Expert Roundup Series on Cloud Migration.
Part 2: What Is Your Best (or Worst) Migration Story? (see below)
What is your best (or worst) cloud migration story?
All of my best stories are intrapreneurial teams working outside of traditional corporate policies in order to deliver game-changing capability to the company. All my worst stories are associated with following a “lift and shift” strategy to migrate a legacy application to the cloud.'Best #migration stories are teams working outside traditional policies' @Kevin_Jackson Click To Tweet
James Bond Cloud Chief Technologist at Hewlett Packard Enterprise (HPE)
As with any IT migration project, there are many successes and some failures we can all learn from. The most important thing I would note is that cloud migration “failures” I’ve observed often have nothing to do with the actual cloud or technology. Rather, the failures were based on other factors, such as:
- Inability to change legacy processes
- Limited understanding of legacy applications, architecture, and usage patterns
- Insufficient internal skill set and understanding of application assessment and cloud migration strategies
One story I will share is based on a U.S. government organization (specific organization name withheld) that spent several million dollars and 18+ months deploying a large private cloud.
While the organization labeled this internal cloud a “community cloud” for use by numerous departments and sub-agencies, one IT department performed all of the planning and eventual operations for this new cloud. None of the sub-agencies were involved in the planning or requirement analysis but were instead informed about the new cloud service and expected to use it.
By essentially ignoring the sub-agencies (and their individual IT departments) who would be the primary users of the new cloud, the cloud services deployed ended up being too expensive (internal chargeback costs) and too generic in capabilities (i.e. just a basic VM-based IaaS service rather than platform and application-centric) to meet the needs of the eventual cloud consumers/departments.
Also, the individual IT departments within each agency were essentially cut out of the new cloud-based operations and, therefore, were reluctant to use the new cloud where they had no control of, no visibility into, and no influence on current/future requirements. The bottom line result was a brand-new community cloud service that none of the sub-agencies wanted to use.
The centralized IT department’s further attempts to use a “stick” rather than a “carrot” to force adoption of their new cloud only made the sub-agencies dig their heels in further. This resulted in some departments/sub-agencies deploying their own internal or public cloud services instead.
There are three main lessons to be learned here:
- Include your cloud consumers (i.e. sub-agencies in this case) in the requirements and governance planning
- Don’t oversize the initial cloud environment with only the hope of filling up the available capacity. Instead, build a smaller cloud with maximum elasticity/flexible capacity to quickly grow
- Never underestimate the ability of politics and fiefdoms to interfere with cloud migration forecasts/plans.
Matheiu Pierret Cloud Enablement Leader at Cloudreach
My best migration story is the high velocity migration we did with Delaware North in 2015. Delaware North is a global leader in hospitality, food, and retail services based in Buffalo, New York. They needed a detailed migration strategy to minimize disruption to company operations, and worked closely with Cloudreach on the project execution.
The most dramatic physical change was the elimination of 205 servers; everything running on that hardware was migrated to AWS. Six months into the cloud migration, benefits included: cost-effective security compliance, enhanced disaster recovery, and faster deployment times for new services.
Tom Ray Head of Cloudreach, USA at Cloudreach
The worst migration projects are those that don’t have C-Level support, the projects never end well. A move to the cloud is a transformation for your business, not “just an IT” project. To be super successful you need the help of many teams across the organization.
Ofer Gadish CEO at CloudEndure
How about the worst migration story that turned into the best migration story? This was the case of a large, well-respected, global systems integrator (GSI) that was working on migrating over 700 servers for a major client. After using three different migration tools that had either failed to work altogether or were not up to the customer’s strict cutover window requirements, the GSI was way behind schedule, which in this case manifested in penalties for missed deadlines.
About two months before the final deadline, the GSI approached us for help. Within eight weeks, using our automated live migration tool, they were able to migrate more than 700 servers that were spread across two data centers on different continents.
For CIOs and CEOs who are skeptical about migration, this is a great example of the importance of choosing a migration tool that actually works.
Looking for more technical information about different cloud migration methods? Check out this eBook on 5 Approaches to Cloud Migration.