Newer / Older

Avoiding the 4 Most Common Pitfalls of a Cloud Migration

By Lee Atchison | August 22, 2022 | Cloud Adoption & Migration | Cloud Migration

 

When starting a cloud migration, organizations often come in with lofty expectations: “Moving my applications to the cloud will modernize my business and solve all my problems!”

But sometimes the cloud doesn’t meet all your expectations. Things you’ve been promised about migrating to the cloud may end up not being true. And you may find that some promises you’ve made to your stakeholder are impossible to keep. As it turns out, migrating to the cloud isn’t as easy as you thought it would be after all.

You should know that you’re not alone. Many companies going through a cloud migration struggle with these kinds of cloud migration problems, and some companies struggle more than others. The best way to ensure your migration goes smoothly is to keep your eye open for these four common pitfalls that sink many a cloud migration—and follow my advice on how to overcome them.

#1: Failing to identify KPIs at the beginning

Migrating an existing application to the cloud can create problems when the migrated application begins to work differently than the original application. This happens for just about every application being moved. The changes may be slight and manageable, but they’re always there. And for some applications, those changes can be dramatic and unacceptable.

To mitigate this problem, before the migration begins you must identify the most important key performance indicators (KPIs) to track. These metrics will allow you to determine how the application is performing and how your customers are perceiving the application.

Cloud migration KPIs fall into three main categories:

  • Infrastructure: How are the servers your application uses behaving? How is your CPU and memory usage changing? Are you having issues with load balancing? Is network latency acceptable?
  • Application: How responsive is your application to user requests? How many requests succeed and how many fail? Is the rate of requests changing in unanticipated ways as you migrate? Are the applications timing out when accessing data or other key resources? Are user sessions getting longer or shorter?
  • Business: Are customers browsing more instead of going through the checkout process? Is the checkout process taking longer? Are users abandoning their carts more often? Are newsletter subscription rates up or down?

Some of these metrics are likely to change drastically when you move to the cloud. Others may change but will have little impact on how your application performs. Some will have a significant impact. Some will impact your bottom line, others will not.

Understanding which metrics are the most important for monitoring the health of your application before you migrate, and tracking these metrics throughout the migration, is critical to making sure your migration is successful.

#2: Failing to establish—and measure—SLAs

In addition to establishing and tracking KPIs before your migration begins, you also need to establish acceptable service-level agreements (SLAs) for your KPIs.

Checking your metrics against your SLAs will give you an objective measure of how well the migration is going. When the migration is complete, you can easily tell if it was successful, and if not, you can get specific quantifiable data telling you what you need to work on to achieve success.

The KPIs tell you how your migration is moving forward, while the SLAs tell you whether the KPIs you’re measuring have acceptable values. Essentially, your migration is not successfully complete until it meets your SLAs.

Critically, by setting SLAs in advance, you remove the “heat of the battle” temptation to compromise on quality during your cloud migration. That’s important because compromises made during the migration can create problems both immediately as well as down the road. The need to resolve those problems can unacceptably increase your post-migration technical debt.

#3: Starting the migration without a fully developed plan in place

A common reason why organizations migrate their applications to the cloud is because they believe the cloud will save them money. After all, vendors promote the affordability of their services, and professionally run infrastructure should be able to leverage economies of scale to cut infrastructure costs, right?

Many of these organizations are surprised when they complete their cloud migration and do not immediately see the cost savings they were expecting. Sometimes, in fact, infrastructure costs can actually appear to have increased after a cloud migration.

Why is this so? In most cases, it’s due to improper or incomplete planning before and during the cloud migration.

Many of the cloud’s cost benefits come from its ability to dynamically allocate and consume resources on demand, then free up those same resources when they are no longer needed. This powerful capability lets the cloud handle the scaling needs of your applications without requiring it to keep a significant quantity of “dark resources” in reserve, just in case.

However, using dynamic resources typically requires making changes to your application architecture. Sometimes those changes are simple, and sometimes they are complex. But either way, if you migrate your application to the cloud without implementing these architectural changes—the basic “lift and shift” approach to cloud migration—you will end up using the cloud with the exact same static processes used by your on-premises applications. This robs you of one of the cloud’s biggest cost advantages, and you’re often stuck with a higher-than-expected bill.

Another cloud-migration-cost issue is not technical at all, it’s financial. It’s often said that a successful cloud migration requires cultural changes in your organization. It turns out that these changes must include not just your development and operational teams, but also your finance department! Your CFO must implement cultural changes in order to effectively utilize the cloud.

Why is this so? In many modern corporations, the cost of owned infrastructure is capitalized and amortized over a significant portion of the life of the infrastructure components. However, when companies move their infrastructure from on-premises to the cloud, they also move most of their infrastructure costs from capital expenditures to “pay-per-use” operating expenses. Even though the move may end up saving the company money over time, it’s likely to significantly change how the company reports expenses and profit/loss.

This cultural shift in how money is spent should be planned and accounted for just as carefully as the technical migration.

#4: The absence of one key technical role

Even when migrating largely cloud-ready applications to the cloud, significant technical planning is required. You still have to deal with migrating data, downtime management, and inter-service latency during the migration. These issues require advanced planning and consideration.

This is why I recommend that every organization contemplating a cloud migration create a Migration Architect role within the company. The person in this role should be the single point of decision-making for all technical aspects of the migration and all the planning and rearchitecting needed to make the migration successful. For large migrations, this individual may lead a team of architects, but a clear point of responsibility for all technical decision-making is critical.

Less headache, more reward

Moving to the cloud isn’t always painless, but it doesn’t have to be painful. Paying careful attention to the four common cloud migration problems discussed here can go a long way toward making sure your migration is as smooth as possible, and delivers on the high expectations that convinced you to make the move in the first place.

More articles from Lee Atchison:

 

Image by Merio from Pixabay.