Top risks of cloud migration: 5 reasons migrations fail
Functionality, scalability, cost-effectiveness: the cloud promises a lot of great things.
But taking advantage of everything the cloud offers isn’t as easy as flipping a switch. Sure, in the long-run there’s less to manage since all of the important stuff sits at the vendor’s end, but cloud services still need to be implemented, and existing infrastructure and data migrated.
The fact is, cloud migrations can go awry just like any other. Unfortunately, no one can see into the future—unless you happen to have Doctor Strange on your cloud implementation team—so some migration hiccups are simply unavoidable.
That said, with enough planning you should be able to put your business in a good position to deal with any potential setbacks on your migration journey.
It also helps to learn from the mistakes of others, so you can make sure you’re evading the same pitfalls. Let’s take a look at some of the most common reasons that cloud migrations fail, and find out how you can avoid them.
Lack of planning
Abraham Lincoln once said: “Give me six hours to chop down a tree and I will spend the first four sharpening the axe.”
During a project as huge as cloud migration, there’s a fair chance you’ll have to amend or revamp some of your implementation plan at some point, but that’s a lot easier to do if you already have one.
When you’re trying to get from A to B, things usually go a lot smoother if you lay down the tracks first. Try to execute a cloud migration without an exhaustive plan of action and you’ll end up flying by the seat of your pants, and making things up as you go along is not conducive to executing a successful tech project.
One of the most common causes behind cloud migration failure is lack of planning. Migrations that are started without a clearly defined, well-researched, and coherent strategy are doomed to fail, so take a leaf out of Honest Abe’s book.
The first step in creating a robust and functional plan for your cloud migration is to examine your current infrastructure.
Look at how you work now, and think about what parts of your infrastructure you’ll take to the cloud. Be thorough—missing dependencies at this stage can cause havoc during migration. Think about whether any parts of your infrastructure will need to be integrated with other services.
Make a note of your current KPIs—page load time, CPU usage, memory used percentage, for example—and plot targets for improvement post-migration.
Create a reasonable timeline for migration to take place, then add in significant “buffer” time to account for any deviations or roadblocks. Consider how apps will be migrated and whether they’ll need to be rearchitected.
Looking for top AWS talent? We make it easy.
Tell us what you’re looking for and we’ll put together a job spec that’ll attract professionals with the skills and experience you need.
Too many budding cloud users go into a migration believing it’s as simple as dragging an app from their in-house servers and “dropping” it into the cloud. Elemi Atigolo, Founder and Director at Buildly, advises a thorough evaluation on an app-by-app basis to avoid over-subscribing to your new cloud philosophy.
“Some existing applications may need to be rebuilt in order to take advantage of cloud features,” says Atigolo, “however rearchitecting isn’t always necessary, or even advisable, to gain those advantages.
“Critically evaluating the options for the whole business, to ensure you identify which applications will require adapting or rebuilding, makes sense.”
And when you make these assessments is just as important as how meticulously according to Atigolo, who adds: “The planning and strategy stage is where this decision should take place and not during implementation.”
Selecting the wrong migration approach
Another common migration mishap comes when businesses select the wrong approach.
Migration is actually something of an umbrella term; there’s more than one path to the same result. But often, businesses don’t “shop around” enough to make sure they find a method that fits the bill.
The lift and shift approach, app modernization and refactoring, and re-platforming are all popular methods of shifting your processes to the cloud, and each has its place in migration strategy.
Many businesses opt for the lift and shift approach, since it tends to be the fastest and least disruptive model (at least in theory). Involving porting an application or operation over from one environment to another without redesigning or restructuring, it tends to be a fairly cheap option for migration, but isn’t without its drawbacks.
Since you’re moving an app to its new cloud-based home “as is”, any preexisting issues or quirks will come with it. That means shifting any bugs you had on-premise to your new environment, where they could play havoc with your implementation—especially as cloud maintenance is a little more detached than traditional on-premise upkeep, and involves more shared responsibilities between your business and your cloud vendor.
Make sure you explore all of your options, and work out which one works best for your particular apps, timescale, and long-term needs before you launch into your project.
Going too big, too soon
Cloud migrations can go awry not only because of how you decide to make the move, but what you choose to shift to the cloud.
Though vendors have worked hard to make the switch to cloud computing as seamless as possible, migration is still a huge undertaking, requiring a lot of time, effort, and reeducating of staff at every level. With that in mind, it’s not always the best option to go from zero to cloud in one fell swoop.
Often, businesses can get swept up by the transformative promise of the cloud, and take an across-the-board approach to migration. The reality is, though, that not everything has to be moved at once, or even at all. Not every app or process or pillar of infrastructure is a candidate for the cloud.
Some workloads just aren’t a good fit, or are incredibly tricky to migrate.
According to Elemi Atigolo, it’s important to keep in mind that not every app, and not every part of your infrastructure, is necessarily a candidate for migration: “Migration solutions can be high risk,” he says, “and can take years to complete depending on the size and complexity of the architecture.
“Rearchitecting of apps and programs opens an organization up to the risk of failure if one of the lines of code is written incorrectly.
“The first question that needs to be asked is whether your organization has a sound business use case for cloud migration. Cloud migration should only be considered where clear tangible benefits can be identified for your business.”
In other words, kick off your migration planning by analyzing your current usage and determining which applications are worth reallocating and which function best on-premise. It’s just as crucial to decide what you’re not going to do as what you are.
This giddy, impulsive rush to the cloud is something that Lior Cohen, Senior Director of Product and Solutions for Cloud Security at Fortinet, has seen businesses fall foul of again and again.
“Typically, cloud migrations fail as customers rush into moving multiple applications into the cloud without addressing the key differences between the existing infrastructure and the cloud,” says Cohen.
Cohen outlines these key differences as:
- The control businesses have over the underlying infrastructure in a private data center does not exist in the cloud
- The performance characteristics of multi-service-based applications need to be engineered in the cloud
- The availability of an application needs to be designed specifically to leverage multiple-cloud components
- The security policies on-premise are different from those in the cloud, as objects are much more static
“These differences are fundamental and often times when customers do not address them in the migration phase,” Cohen continues. “They end up paying an arm and a leg as they replicate their overprovisioning strategies to the cloud, as well as managing unnecessary cloud services.
“It’s important to take a gradual approach,” agrees Atigolo. “An organization would benefit from having end-to-end planning, as trying to migrate everything all at the same time risks creating additional issues, and more implementation expense and delays.”
Once you’ve selected the parts that are most likely to thrive in a cloud environment, you need to prioritize your migration plan. Obviously the parts of your infrastructure that are stable, modern, and working efficiently won’t be top of your list; unless that is, they’re proving costly to run and you’re looking to switch up deployment to make them more economical.
It’s okay to start small and build up your cloud portfolio over time. Beginning with non-business-critical apps and migrating progressively will make it much easier to deal with and, in future, off-set any issues that arise without grinding your operations to a halt.
Not testing thoroughly
Testing is obviously an extremely vital step toward ducking a cloud migration disaster – and that doesn’t just mean testing once your migration is almost complete and your apps and infrastructure have landed in their new home.
Testing should be baked in at every stage of your migration plan, allowing you to spot potential issues at the earliest possible stage. The more you test and weed out problems early on, the smoother your migration will go, so get your ducks in a row before marching them across the street.
“Many organizations fail to extensively or adequately test before migrating their entire infrastructure to the cloud,” says Atigolo.
“You should see migration as a quick win, but a planned strategy to add tangible benefits to your organization. The same level of planning, attention, due diligence, and testing is required for migration as it would be if you were building a new architecture or center for your data.”
Overlooking the human element
Cloud migration is a transformative project. It can totally revolutionize the way a business creates products, delivers its services, or connects with its customers. But all this cloud magic doesn’t happen independently —people, as well as processes, need to change.
Users need to get to grips with radically updated software, operational shifts, and new processes when it comes to seeking technical support. Education, training, and change management are just as important when it comes to IT staff too.
As you move away from legacy IT models and responsibility for your operations becomes decentralized, roles will change. Your IT teams will need to adapt to a new way of doing things, and find innovative ways to support users and add value to the business.
With lack of user adoption a major threat to any implementation, training, and governance need to be a key focus to ensure that when your cloud environment goes live, your staff are actually using it.
Involve people early on, sell the benefits of the migration and explain if and how their day-to-day lives will change. The longer people have to warm to the migration, the more prepared they’ll be to take advantage of it when it’s complete.
Put open-door feedback channels in place so you can address user concerns and queries in real-time and avoid issues stacking up, and faith in the migration souring.
Want the latest insights into the AWS market?
The Jefferson Frank Salary Survey provides a unique insight into the Amazon Web Services community. Complete the form below and receive your PDF report in seconds.