Before we start, let’s take a moment to briefly touch on what cloud migration even is and why a company might want to use it.
What is cloud migration?
According to Google, “A cloud migration is when a company moves some or all of its data center capabilities into the cloud, usually to run on the cloud-based infrastructure provided by a cloud service provider.”
Why have cloud migration?
According to Google, the main reason businesses use cloud migration is “A cloud migration allows your business to expand and grow painlessly while working within the existing infrastructure. This means applications and data can grow without impacting your business performance or customer experience”.
Cloud migration can be extremely useful for a company that wishes to grow and use the services that the cloud can provide. One large issue with this, however, is the migration itself. Many companies have issues migrating their infrastructure over to the cloud.
I’m writing this blog to help with that. I’m going to list out steps that a company can take before migrating in order to make the migration as easy and effective as possible.
For transparency, I found a really good blog on this subject on the website newrelic. I will be using this as my source for this blog. If you wish to just use that blog you can use this link:
I will be more or less summarizing what is stated in this blog.
The first step is to task someone to be in charge of the migration. Someone who is at the top of all that goes on when it comes to migrating is necessary to make it work.
The second step is to decide whether you want a shallow cloud integration or a deep cloud integration.
Shallow cloud integration is when you make as few changes as possible to get your applications to run on the cloud servers. Deep cloud integration is when you modify your applications so that they are able to take advantage of the cloud’s services. This depends on each business and how they can most effectively use the cloud.
The third step is deciding whether you want to put your applications using a single cloud provider or use multiple cloud providers. And if you use multiple cloud providers, in what way will you use them? Will you have one full application in one cloud and another application in another? Will you have one application split between two clouds? Or will you have your applications coded in such a way that they’ll work on any cloud server? The advantages for leaning toward fewer cloud services is that you can take more advantage of what they can offer, but the advantage for leaning towards many cloud services is that you have better negotiating power.
The fourth step is to create cloud KPI’s. A KPI is a key performance indicator, basically a set of metrics you set to see if your application is meeting your expectations as you migrate. This can be anything, such as user experience, application performance, etc. These metrics are there to help you see if you’re falling behind in any areas.
The fifth step is to create performance baselines. This is just finding a way to measure your pre-migration productivity against your post-migration productivity. You should set a baseline for each KPI you created in the last step.
The sixth step is to prioritize migration components. Once you start migrating, you’ll have to decide in what order you’ll migrate the different applications. To do that, you’ll need to go through each of the applications and determine an order that is most efficient. As it may be the case that some applications rely on others.
The seventh step is to refactor your applications. This is just changing up your applications so that you can work on them as efficiently as possible on the new cloud servers. This will probably be a more involved step if you’ve chosen a deep cloud integration in step 2.
The eight step is to create a data-migration plan. This is an extremely tricky and involved step since the location of data can hamper performance if done carelessly. Be sure your data is as accessible as possible whilst it’s being migrated.
The ninth step is to switch over the company’s production system over to the cloud server. You can try to do this all at once or a little bit at a time.
The tenth and final step is after you’ve finished migrating, review your resource distribution. Since you’re now on a different system, you may not be distributing your resources to your applications in an optimal way anymore.
And that’s it. If this has interested you, but you wish for more detail for these steps, here’s the link again to the blog I’ve used as a source for this:
This has been Warren Ball, intern at iSmile Technologies. Thanks for reading. I hope this helps.