How to quantify—and qualify—cloud migration benefits
It’s a foregone conclusion that the future of enterprise business rests in the cloud. This is especially true when considering what a huge role cloud migration has played within the enterprise space over just the past few years:
Spending on cloud computing has grown at 4.5 times the rate of IT spending since 2009, and is expected to grow at more than 6 times that rate through 2020.
This is supported by the latest data from Oracle, whose number two prediction for 2019 was that 80 percent of all enterprise workloads--including those deemed “mission critical”--will move to the cloud over the next 12 months.
Despite the near ubiquity of cloud across the enterprise (and growing familiarity with cloud technologies for IT experts and laypeople alike) moving workflows into the cloud is no easy feat. This is especially true when it comes to managing expectations, and actually delivering improvements--whether those are related to cost or performance--when migration is complete.
To make sure teams aren’t making promises they can’t keep, they need visibility at every stage of their cloud migration. After all, “you can’t manage what you can’t measure,” the old mantra goes, and so IT teams must have visibility at every stage of the migration in order to set accurate expectations and stay ahead of issues before they derail the whole venture.
Defining acceptable performance goals
For starters, teams need to fully understand what applications, network infrastructure, or processes break down most often. IT will likely need to interview cross-functionally to get information and buy-in across the organization.
Making the case for cloud migration may be easy when IT is thinking in terms of generalities. Sure, offloading the maintenance of network hardware will look attractive to budget-conscious decision makers, but how much upfront investment is needed before the business can reap those savings?
Cost alone might not be enough to entice all decision makers, either. If cloud migration improves the performance of several apps that are deemed business critical, will it come at the cost of tools used elsewhere? Will app performance be impacted throughout the migration, and for how long? Is there new training required for users?
Teams need to have a grasp of all of these questions before they bring their migration proposals to the executive team. This will require IT to do some serious reflection on the current state of the network to create a baseline of existing performance. This way, teams can confirm or inform decision-makers’ opinions on where improvement is needed most and put the solution in the context of the cloud.
Baselining performance before migration
End-user experience is where this baselining all begins. After all, IT will not be successful if the end-user experience of employees isn’t improved -- or is actually noticeably worse -- after cloud migration. Even decision makers who are focused solely on the bottom line will agree since poor user experience can have a domino effect on the performance of the larger business. IT, therefore, needs to zero in on the “current state” of the network (along with user satisfaction) before any architectures are uprooted.
For applications, this requires synthetic web testing that gives IT local perspective into what users are actually experiencing in the locations they work, along with clear visibility across the entire delivery path. With this information handy, IT can establish “acceptance criteria” that they need to meet during and after cloud migration to ensure that users remain satisfied. Some sample criteria might look like:
- Response time should be within 5 percent of levels before migration
- Service error rates should be equal to, or lower than, levels before migration
- Application availability should be equal to, or lower than, levels before migration
- Infrastructure costs should be reduced by at least X percent over course of migration
Teams, therefore, need to get a pulse check on how fast apps are currently being delivered to users, latency between servers (both internal and external, DNS, etc.), error rates, types of errors and browser-specific performance issues. Only with all of this data can IT wrap their heads around the state of the network pre-migration.
Continue monitoring throughout migration
Once teams have put baselines in place, it’s important that they continue monitoring their acceptance criteria throughout the migration process. Teams should be able to create dashboards and alerts that can flag when the network isn’t meeting criteria, ideally using the same metrics, if not monitoring solution, that they referenced to baseline performance.
- Uptime - For cloud applications, IT should expect downtime to be limited to minutes during any given week. Most public apps strive for 99.9% or better (~7 minutes in any business week).
- DNS - For apps that are now in the cloud IT will likely have a local DNS server or public DNS service supplying the IP address. This is something that should be actively monitored as it will prevent connections for all users at a given location.
- Latency, RTT - Now that services are outside the data center or outside of the office there could be a meaningful difference in the time the traffic takes to travel from client to server. Spikes here could be related to LAN, ISP or app issues.
- Capacity - Paying for bandwidth from an ISP is one thing, but the end-to-end capacity of a network between user location and app server will likely have a different bottleneck. This measurement allows IT to identify when congestion impacts connection speeds.
Spikes and jumps are useful indicators of migration-related bugs that need to be tackled immediately -- even before new business requests -- to stop issues before they proliferate. By resolving issues IT’s eyes are directly on the problem, teams are more likely to implement the most appropriate solution.
Leverage monitoring to qualify success
The baselining that teams conducted before migration needs to be redone for comparison once the new network architecture is in place. The key here is to use the same processes (usage, patterns, time, etc.) that was tested over the old network.
With all cloud migrations, there is some level of control that is lost. Whether that is at the bare metal, OS, or access levels, it’s also important that teams are using modern monitoring solutions that can deliver the same level of visibility into the new cloud-supported network. If the infrastructure is no longer owned by IT then the level of visibility with old monitoring tools will be impaired. This is crucial, as many monitoring solutions can’t deliver visibility into cloud environments or even outside of IT firewalls.
Without insights beyond the firewall, it’s difficult for IT to identify issues that stem from ISP or 3rd party infrastructure and resolve them quickly. This can both delay migration while it’s in progress and make users outside of IT nostalgic for the pre-cloud days if performance is continually hindered.