Migrating workloads to the cloud can be tricky. In fact, a study Virtana conducted earlier this year found that 72% of respondents had to move applications back on-premises after migrating them to the public cloud because they ran into a variety of problems. Clearly, organizations need to address these showstoppers. There are, however, a host of other challenges you could run into that, while they may not necessitate the drastic step of repatriation, could create problems, delays, extra costs, and other headaches during and after the migration process. Here are eight common problems that can hamper the efficiency and ultimate success of your cloud migration, along with guidance to help you mitigate those risks.
Risk #1: Selecting the wrong migration strategy
There is more than one way to get your workloads from the data center to the public cloud (you can read about those options here). The “right” strategy for you will depend on a variety of factors. For example, “lift and shift” is attractive because the migration process itself can be faster and easier than the other approaches, but with this option you may not be able to take advantage of a range of cloud-native benefits, and you could potentially run into latency issues and/or higher-than-expected cloud costs. Taking the time to understand the different cloud migration strategies and evaluating them for your organization’s specific workload characteristics, business requirements, and risk tolerances will help you make the right strategy decision from the start.
Risk #2: Migrating workloads that are ill-suited to the cloud
It is a rare organization that can operate 100% of its workloads in the public cloud. In some sectors, such as financial services, enterprises keep applications on premises due to concerns—and sometimes regulations—related to security and privacy. This is only one of the considerations you need to factor into the decision of which workloads to migrate to the public cloud. Others include back-end architecture, data, and transaction speed requirements. In fact, of the 72% of companies who reported having to repatriate applications after migrating them to cloud, 41% said it was because those applications should have stayed on premises to begin with. To avoid this problem, you need to discover, assess, and map your on-premises environments and then understand how they will behave in the target public cloud environment.
Risk #3: Selecting the wrong cloud service provider (CSP)
Different CSPs offer different strengths, and the best one for your organization will depend on the characteristics of your applications and your requirements. For example, AWS is a good all-around option, but if you need strong corporate authentication integration, Azure—which leverages Microsoft’s LDAP and Active Directory legacy—might be a better choice. Oracle Cloud is a good option if you already use their database technologies or are looking for robust big data management solutions, while GCP is becoming the cloud of choice for data analytics and machine learning. In fact, 21% of the respondents in the survey who had to repatriate workloads said it was because they used the wrong CSP. There may be many more organizations who, instead of hitting the “undo” button, continue to run their workloads in a less-than-ideal cloud environment for their specific needs. You do not, of course, have to pick just one CSP. Most companies are opting for a multi-cloud strategy, using multiple CSPs. In this case, you will want to consider how you will monitor and manage your workloads across multiple public clouds. In addition to understanding the relative strengths and weaknesses of your CSP options, you also want to be able to see how your specific workloads will operate within that particular cloud environment.
Risk #4: Missing key dependencies in the migration process
The modern IT environment is a complex ecosystem with many components and services being shared by different applications. If you miss a dependency in your migration plan, you could end up breaking something in the process. If the culprit is not obvious, and it often is not, then you could lose a lot of valuable time tracking it down. Therefore, when planning a migration, you need to understand not just what you have but also how it all interrelates. You can then use this information to build and prioritize “move groups,” or groups of workloads that should be migrated together.
Risk #5: Overcommitting on reservations
If you agree to a specific capacity and resource allocation to be used over a certain time frame, you can get a reduced rate. This is sometimes called a reserved instance, but that term is a little confusing as it is not really an instance but a commitment. The savings can seem appealing, but if you end up paying for capacity you do not need, you have not actually captured that value for your business. You need to understand your utilization requirements beyond simple min/max values or averages. For example, let’s say that you have two workloads with similar min/max ranges or average values. One workload runs in the 80-90% utilization range most of the time. The other one usually operates at around 30%, peaking at 100% for only brief but predictable periods. You can start to see how the workloads may or may not “fill” a reservation you are considering. To avoid overcommitment of programmatic discounts, you need to accurately account for peak and non-peak usage and then find the ideal resource settings before making a purchase. Additionally, you want to be able to track the amortized value of your programmatic discount usage at the instance level.
Risk #6: Underestimating performance impacts
The public cloud is fundamentally different than the on-premises environment. While a slight increase in latency is to be expected and may be acceptable depending on the application, you want to avoid problems that prevent you from meeting your SLAs. Of the organizations who had to bring migrated workloads back on premises, 29% said it was because of application performance degradation. To avoid this problem, you need to find the right configuration to support your performance requirements. Too often, however, organizations focus primarily on CPU utilization which, while important, is not the only factor. You need to be able to evaluate how your workloads will perform based on their characteristics—all of them—as well as your specific budget requirements and risk tolerances.
Risk #7: Incurring unexpected costs
One of the benefits of the cloud that has been touted since the very beginning is lower costs. And yet, organizations are constantly being hit with higher-than-expected cloud bills. There are numerous reasons this happens, but solving it can prove to be a challenge. One-fifth of the survey respondents who brought migrated applications back on premises said they did so as a result of unexpected costs. Not only that, but there is a tremendous amount of cloud waste, which means that companies are spending more than they need to, and they do not even know it. To keep your cloud costs in check—and ensure you are only paying for value you are getting in return—you need to understand the details of those costs, identify unused compute instances and storage blocks, and keep your instances rightsized on an ongoing basis.
Risk #8: Being unable to analyze and report on metrics that are meaningful to the business
While digital transformation is enabled by technology—particularly cloud computing—it is fundamentally a business initiative. Because these platforms, and the tools used to manage them, are built and primarily used by technical people, they often do not make it easy to measure and report on the metrics that matter to c-suite executives or line-of-business leaders. For example, if your enterprise uses IT chargebacks or showbacks, you need to ensure that you will be able to report on cloud usage by individual cost center, which will likely require setting up cost allocation tags in your cloud instance. Another example is the EC2 Other cost bucket in AWS, which contains multiple service-related usage types such as Amazon EBS volumes and Snapshots, Elastic IP addresses, NAT gateways, data transfer, and more. EC2 Other can end up being one of the biggest spend items on your cloud bill, so it is likely to catch the attention of your finance team. An “I don’t know” answer in response to “what is this big charge?” does not bode well for your credibility, and AWS native tools do not make it easy to figure it out. Finally, you need to analyze your costs in a way that is meaningful for your business—filtering, grouping, and stacking by your cost-allocation tags and further breaking it down in additional dimensions. You need to understand the analysis and reporting capabilities and limitations of your existing tools to deliver the insights you need from both technical and business perspectives, and have a plan to fill any gaps so you are tracking what matters right from the start.
Know Before You Go With Virtana, You Cloud Migration Partner
Migrating your workloads to the cloud can be risky, but it does not have to be. With Virtana Workload Placement, you can plan smarter to accelerate and de-risk cloud migration. Virtana Workload Placement provides you with full visibility into existing on-premises workloads and the tools to make the best decisions about application priorities, grouping, and deployments so you can plan smarter and get cloud migrations right the first time, every time. Once your workloads have been migrated, you can use Virtana Cloud Cost Management to achieve smarter cloud scaling by optimizing your capacity and cost in real time on an ongoing basis. Our precision observability provides full visibility into all your cloud costs and identifies unused resources that can be eliminated. Try Virtana for free
Additional Cloud Migration Resources
- E-book: Cloud Migration for Dummies
- E-book: The Complete Cloud Migration Planner
- Blog post: The 7 Steps to Creating and Refining a Cloud Migration Strategy
- Blog post: Cloud Migration—the 8 Part Guide to Successfully Migrating Workloads
- Solution brief: Virtana Migrate
Randy Randhawa
