All successful cloud migration projects start with up-to-date knowledge of a company’s current infrastructure and application landscape. While it may seem obvious, many organisations don’t have a clear picture of what’s running in their environments. This picture helps the migration effort both before and after the migration. I’ll mention
how in a bit, but first, what should we look for?
Audit
One obvious category is information about the workloads themselves. Almost all platforms come with reporting tools that tell you about the workloads running on them. That information, extracted from all platforms and kept in an easily manipulated format, such as a spreadsheet, forms the initial scope for migration.
Networking design will undoubtedly change beyond recognition as part of cloud migration, but it’s crucial to have an in-depth understanding of the existing topology, the rationale behind that design, type, and quantity of traffic that goes over the various links.
Knowing the complete breakdown of the costs of running the existing service is a must. Hardware and software costs for the platform and data center costs are obvious ones, but the headcount required for operations is often forgotten. Make sure that they’re also considered.
What about who owns which service and who is the technical authority for it? These are often different people with different priorities. It’s not enough to just put any names there. It’s very important that the named individuals know about and agree to hold those roles for that service.
Pain points are excellent indicators of what are important issues to resolve. For example:
- How long does it take for operations to deploy a machine?
- Does the application scale under load? If so, what are the response times?
- How long do the developers have to wait before they get their test platforms?
- Are current processes automated or do they require manual intervention?
These measurements define your KPIs (key performance indicators) and will be used later to measure success. Those indicators must be well-defined, and their values should prove categorically if the state has improved or deteriorated. Once defined, values of those indicators should be carefully documented for the pre-migration state, with careful consideration that no correction is carried out before the measurements are taken.
Benefits Before Migration
Once the audit is done, the picture starts to become clearer. Let’s take the infrastructure spreadsheet for starters. Initially, it will be a crude list of workloads, but with a bit of thinking, the team can determine how many of them should be in-scope to move. They could be all production and development machines, but what about test machines?
It could also be that the hosting platform is creaking under the workload, increasing the urgency to migrate, to avoid capital investment into more hardware. This audit may identify workloads that are forgotten but can be removed to reclaim precious resources, thereby creating breathing space and buying more time to migrate.
Before the design phase, having all networking information in-hand is extremely important, as networking costs are calculated very differently in the public cloud. Not only are they highly-dependent on the design, but they can influence the final design.
It’s also a good opportunity to look at workloads to see if there are any unusual machines in terms of resource allocation or licenses that may not fit nicely when moved to a public cloud platform. Some rationalization in that area can help reduce pain when going ahead with the design.
If not already done, this exercise also gives a good estimation of potential infrastructure costs on the various cloud platforms and can also feed into business case conversations.
Benefits After Migration
Going through the audit process makes it easier to carry the habit through into the new platform, especially if it proved to be useful. Data gathered can also be extended to contain additional data points that might have been useful to have initially but were only discovered as part of the migration.
In the short term, after-migration costs are seen to increase. That is because in the initial stages of migration, both source and destination environments are running in parallel. In such situations, having the audit done with exact cost breakdown helps to explain that behavior.
A key milestone in the migration project is to show the business that you as a team have achieved the
goals that were set out in the cloud migration business case. That’s where the effort spent in defining those KPIs and documenting the values comes in handy. New data returned into those KPIs post-migration becomes the determining factor for project success or failure.
Conclusion
Having the current, complete, and accurate data in-hand is the first practical step in starting the migration journey. That should contain data from all the sources that will be affected by the migration. Most importantly, it should contain the KPIs that will determine success or failure and their measurements before and after migration.
It’s important because while one can announce a migration to be a success, as W. Edwards Deming said:
“Without data, you’re just another person with an opinion.”
