Cloud migration is here to stay. It’s no longer a matter of “if” you do it, but when and how you’re going to make the move. So you’ve done your homework, and prepared the cloud migration checklist.
First, you’ll carefully select the optimal application to move to the cloud. Next, you’ll devote some time to check the applications readiness, and estimate the time and effort required to perform the migration. Then you’ll scrutinize every single detail of the application and its components to analyze how they are related and how they communicate with one another. Finally, you’ll know it’s the right time… Decisions will have been made, the budget will be approved, and you’ll be ready to embark on your first cloud adventure!
Hold your horses… Haven’t you missed anything? How will you know if your migration has been successful? How can you establish if your goals have been reached, and everything works as expected? Do you know your goals and expectations?
Have you set any specific migration goals (apart from moving your application and resources to the cloud)? Have you prioritized them?
If you have, you’re on the right track! You could probably stop reading this post now (just kidding; who wouldn’t like some instant tips on defining success criteria for cloud migration?). If you haven’t, that’s obligatory reading. Take a few minutes to find out how to identify and measure a successful cloud migration.
Define your cloud migration goals
Migration to the cloud can be challenging, not only from a technical standpoint. Very often cloud is an innovation driver in a company, so failure is out of the question. Success is the only option. But how to define it?
Every interest group within an organization understands success differently: end-users, system administrators, and business department. Each of these groups will have their own success criteria and different expectations as to the outcome of the migration.
To evaluate if a cloud migration was successful, you need to consider user expectations, costs and tolerance for application performance after the migration is complete.
Some of the success criteria may look like this:
- Application deployment time reduced by XX% comparing to the pre-migration levels
- Time to prepare the entire development environment reduced by XX% percent comparing to the pre-migration time
- Steady-state server utilization reduced to XX% of the pre-migration levels
- Application response time within XX% of the pre-migration levels
- Infrastructure costs in the steady-state reduced by at least XX% percent of the pre-migration costs
- Error rates lower than or equal to the pre-migration rates
- No deterioration in the application availability and performance
Different applications will assume different success criteria and migration goals. The more critical application, the more specific the goals.
Regardless of the case, you always need to define what you’re hoping to achieve through migration. As a next step, decide how to measure these goals. Specify and quantify the expected improvements, identify critical metrics to improve or maintain at the same level, and clearly state that error rates and types may not change. This will help you make sure that you didn’t allow any new errors during the migration.
Establish your baseline
Once your goals and success criteria are well-defined, you need to establish a baseline for you end-user experience and application performance. It’s a critical step, as after the migration you must develop some benchmarks. If your goal is to reduce server utilization to the pre-migration level, you first must know what that pre-migration utilization level was. You will not be able to precisely gauge the success of your migration without points of reference.
Another benefit of benchmarking is that it allows you to identify problems and report issues during migration when you observe any deviations. You can fix or mitigate errors before the migration is complete.
But what to assume as a baseline? Again, this depends on your goals and needs.
What makes a valuable baseline?
In general, whatever you want to measure as success criteria after migration, should be measured as a baseline. It can be response time, error rates, type of errors, latency, CPU, memory and network utilization during several different scenarios with different traffic load, typical task duration, current infrastructure costs, etc. Here are some handy tips to remember when determining your baselines:
- The most important aspect of migration is user experience. Migration must not affect it negatively. Although it may be difficult to be measured, with measuring of the above metrics you may identify potential issues with UX. If you have any application performance monitoring tool, you may benefit from it here.
- To be sure you didn’t miss anything, establish multiple baselines based on the application’s usage patterns. The application may behave differently during usage peaks so you may want to compare that behavior after the migration. You don’t want to end up in a situation when your application works like a charm in the cloud under the typical load and becomes unusable when it increases.
- Changing performance of any given service can impact the application performance under different conditions. A small change in one place may have a significant impact somewhere else. So establishing reliable baselines, measured under various conditions is mandatory to allow you correctly evaluate a migration success with full confidence.
Evaluate your cloud migration
When you move all desired services to the cloud, it’s time to measure your success. How do you do it? Well, with your pre-migration baselines prepared, it’s simple!
Examine your application using the same usage patterns as you did before the migration and compare the new baselines to the ones before the migration. Validate if the metric changes meet your expectations. If some of them don’t, there is no need to panic or undo the entire process. Act sensibly.
First, examine deviations to determine the causes. It’s possible that you’re already aware of them and know how to fix them. If you don’t, check if a given deviation is acceptable. It may turn out to be a small glitch in the overall context, without any impact on the infrastructure. Rolling back the migration to get rid of it would be more detrimental in that case.
Once all planned performance improvements are validated, all negative performance deviations fall within the scheduled acceptable levels or have been explained and deemed acceptable, and no unexpected errors are identified, you can congratulate yourself on pulling off a successful cloud migration!
What if something goes wrong?
Sometimes performance after the migration becomes unacceptable, metrics are much worse than before, and you have no idea how to quickly fix them. Something went wrong.
Don’t set off the panic mode yet. If that happens to you, don’t be afraid to roll back the migration or some part of it and reevaluate what has to be changed before going further. Adjust your metrics and goals if needed. Find out what went wrong and how to fix it before you re-attempt the migration. Maybe you will need to slightly change your approach or even start from scratch? Anyway, treat it as lessons learned to avoid such situation the next time and don’t get discouraged.
Choosing the relevant success criteria when migrating to the cloud is vital for an appropriate process assessment. If you don’t define them well, you will not be able to determine whether the migration succeeded or not.
Success criteria depend on the goals you would like to achieve. You may be looking to reduce the infrastructure cost, decrease latencies or server loads, or improve user experience. Whatever your goals are, the critical part is to define a proper baseline for benchmarking. Only then will you be able to determine if your measured metrics improved or got worse.
Well-defined baselines and clear-cut goals are essential to create and validate cloud migration criteria of success.