Most organizations have already made the shift to the cloud, meaning cloud migrations have taken on a new meaning. Today it’s mostly not about a lift-and-shift from in-house infrastructure, it’s about cloud acceleration—improving the performance of the applications and services already running in the cloud. That could be migrating applications to a new cloud provider, or to a different tier or geography with your current cloud provider.
To do that, you must accurately measure your current performance. Only when you fully understand your existing cloud performance can you hope to make the necessary improvements—and maybe even save money in the process. Here, we’re going to explore the steps you need to take before and after a migration to maximize your chances of success.
Pre-migration Measurements
First, it’s critical to understand your current usage patterns. What are your workloads actually doing? How are they connected? And what performance are you getting from them?
Migrations often start from a cost-saving perspective. You might be paying a certain amount to run in four geographically diverse availability zones and you’re thinking about reducing that number to one or two. What’s the impact of that going to be? Well, first you have to quantify your current performance.
It may be that reducing that number of availability zones is going to increase latency for users in a particular location by a couple of milliseconds. That might not appear to be a big deal in theory, but if you’ve got a “chatty” application that’s constantly making calls back and forth, that two milliseconds of extra latency could degrade performance to unacceptable levels. So, before you make any changes, it’s imperative you know where you’re starting from—accurately measuring current performance so you can monitor the impact of change.
The next step is to run small-scale tests of how those workloads are likely to perform in a new environment. Major cloud providers often offer free tiers where you can run synthetic tests to understand what the performance would look like in a particular environment. You want to measure the impact of factors such as database location changes, connectivity between different cloud providers, and potential latency issues.
The goal is to gather quantifiable data about potential migration impacts before actually moving workloads, helping to minimize risks and unexpected performance issues. This isn’t something you want to gamble on. Take the example of the Australian company that shifted its HR application from on-premise to cloud infrastructure, with the goal of being able to execute a workload within five seconds from wherever staff may happen to be in the world. The company didn’t do the necessary testing pre-migration and only realized afterwards that some of the functions were hosted in Munich. If staff were working in South America, they couldn’t execute workloads any faster than 15 seconds, because of the sheer distance the data needed to travel.
Post-migration Management
Having done the groundwork with your pre-migration measurements and testing, the post-migration job is about making sure your performance expectations have been met, or even improved upon.
The small-scale synthetic tests you conducted pre-migration should have given you a baseline against which actual post-migration performance can be assessed. So now it’s crucial to measure end-to-end service performance across all components, comparing actual performance against those pre-migration expectations.
Sometimes, cloud migrations have unexpected impacts. Even benefits of moving applications to a cloud infrastructure, such as improved resilience, can have unintended side effects. Resiliency comes from pushing data down multiple paths, but it’s important to continually test all these different routes for unexpected consequences. For example, when an organization is resolving to one DNS provider instead of another, they may discover that they're incurring additional seconds of delay. Only if you’re accurately monitoring every hop of that journey will you be able to detect where such bottlenecks occur, especially when you’re switching to new, unfamiliar environments.
The connectivity between different cloud providers and latency between regions can also have unintended consequences for performance. Despite all of your testing, you may find that performance is worse post-migration. And sometimes the solution might be to do something completely counterintuitive, and bring some workloads back on site.
The decision to move to the cloud is normally taken because the business demands extra compute resources, the ability to scale up and down quickly, or even access to AI models. But there might be a business case for bringing certain workloads back closer to users, with a data center at the edge. This is precisely what this high level of visibility allows you to do, to really drive into a hybrid environment, where specific workloads are managed locally, while still enjoying all the other benefits that a cloud computing environment offers.
If moving workloads back to a local data center isn’t an option, there are other ways you can smooth performance post-migration. You can look to redistribute workloads, maybe bringing them closer or even into the same location as where your major SaaS applications are hosted, to minimize the distance data has to travel.
You might also be able to work with your SaaS providers to iron out performance issues. In the case of the HR application we mentioned earlier, this problem was eventually resolved by increasing the size of the cache used by the SaaS application so that it didn’t need to refresh as frequently, minimizing the impact of the extra latency that it incurred during the shift to the cloud. Again, you’d only be able to identify such a solution if you had full visibility of the entire service delivery chain in the first place.