Cloud migration failures and how to prevent them
The use of cloud computing for enterprise apps continues to grow, with organizations putting more of their workloads in public clouds and pursuing multi-cloud strategies to generate lower costs, increased agility and greater flexibility.
However, not all cloud deployments deliver those benefits — or any benefits at all. Many IT leaders face cloud migration failures, because they move apps into the cloud only to find they don’t work as well there as they did on premises, forcing a reverse migration.
A recent study from security provider Fortinet, conducted “When companies repatriate workloads, it’s often an indication that something has gone wrong,” said Yugal Joshi, vice president of information technology services at Everest Group, a management consulting company based in Dallas.
That’s far from ideal. Moving workloads is costly and often disruptive, according to experts. There could be performance issues, additional security exposure and work interruptions, as well as a drain on IT and business resources.
“Changing the location of a workload isn’t easy, and there is a lot of risk in moving workloads around,” Joshi said.
Cloud migration faces challenges
That level of failed cloud migrations doesn’t surprise Asif Malik, senior vice president and CIO of SilkRoad Technology, based in Chicago. He said he has been in that situation in the past at a prior company.
Malik detailed one particular case to illustrate the problems he faced with a move to the cloud. He and his team moved a data analytics application from the company’s data center to a public cloud offering, opting to have the application hosted “We thought it was Capex versus Opex. We thought we could save a lot of money and get rid of managing infrastructure,” Malik explained. “But we were wrong.”
There were problems from the start. His IT workers noticed latency issues right away, and they identified limitations within their networking equipment that further hindered the app’s performance.
“We kept throwing compute resources and storage resources at it,” Malik said, and that drove up costs.
Given such problems and no financial benefits, Malik opted to move the app out of the cloud and back on premises. This process presented its own challenges and took about eight months of his team’s time to complete.
Why migrations fail
Joshi said companies moving apps out of the cloud typically do so after finding they’re experiencing latency issues or increased security and compliance challenges.
Those observations track with the results of the Fortinet survey. According to the report, 52% of those who moved workloads from the cloud back on premises said either performance or security issues were the primary reasons for their decision. An additional 21% cited regulatory issues as the driving factor.
“If I think about the times that I’ve seen people move to the cloud and then move backward, it’s been a combination of things,” said Scott Buchholz, a managing director at Deloitte Consulting LLP who serves as the government and public services chief technology officer and the national emerging technologies research director.
Some companies see higher costs than they expected. Some find they’re not getting the uptime they expected from the cloud vendor. Still others hit complexities that slow down their systems.
“There are some very high-volume systems that have particular technical requirements that don’t work well in the cloud. High-volume transactional databases, for example, don’t work well in the cloud. And there are some apps that we don’t think are really connected to other things, and they have more connectivity and talk to more things than was realized. So, Malik said his cloud migration misstep gave him deeper insights into migration best practices. It drove home one point in particular, he said: “Not every application belongs in the cloud.”
That, indeed, was what he determined was the main cause of failure with the data analytics app he moved to the cloud — it wasn’t ready to make the move.
According to Malik, the problem started with the decision to simply move the app as it was to the cloud — a straight lift-and-shift project.
“The application wasn’t a multi-tenant application, it wasn’t an elastic application, and it did not use a virtualized environment very well,” he said, adding that the app relied on data that resided within the data center — a factor that contributed to the app’s poor performance in the cloud.
Experts said that’s a typical scenario for IT departments.
“They treat the cloud like a virtual data center, and they don’t change their operations or procedures when they move to the cloud,” Buchholz added.
That is changing, though, as more organizations gain experience with cloud migration projects. IT advisers and researchers said they’re seeing more CIOs doing a better job evaluating their on-premises applications to determine which can move into the cloud as they are and run successfully, which ones should be modernized and moved to the cloud, and which ones should stay put.
Application evaluation is crucial
James Fairweather, chief innovation officer at Pitney Bowes, a global technology company in Stamford, Conn., offering customer information management, location intelligence, customer engagement, shipping and mailing, and global e-commerce products, said the company embarked on a transformation initiative about five years ago. Part of that involved moving workloads and individual capabilities and services into the cloud.
To help smooth those moves to the cloud, Fairweather said the company rigorously evaluated applications to determine which could be shifted as is to the cloud and which needed to be optimized for the cloud in order to deliver returns.
“In all these workload migrations, we’ve been very planful (sic) about them,” he said, explaining that staff conducts security reviews, code testing and other analyses on applications before mapping out the best path forward.
The company also invested in new technologies, such as automation tools and API management from Apigee, to ensure successful cloud migrations.