There can be many reasons for migration from one cloud to another, for example: provider failures, lack of necessary functions, changes in legislation, more favorable conditions elsewhere.
We will tell you how to migrate your applications and data from one cloud to another without loss, unnecessary settings and with minimal downtime.
First inventory, then migration
Algorithms for migration from AWS, Azure, Yandex.Cloud, IBM Cloud, Alibaba Cloud, Google Cloud Platform, Oracle Cloud and any other cloud are similar, only technical details differ.
The move begins with a complete inventory of your infrastructure. You need to make a complete list of all infrastructure facilities, for example:
- services;
- servers;
- disks;
- storage facilities;
- balancers;
- databases;
- domains and HTTPS certificates to them;
- subnets and networks.
It is also necessary to collect data on which projects / departments of the enterprise are using which specific capacities.
Be sure to note the amount of different resources required for each piece of infrastructure. For some services, it is useful to mark the software versions you are using so that during the move it does not turn out that you, for example, are trying to migrate data from PostgreSQL 12 to PostgreSQL 10.
Migrating similar infrastructure components from cloud to cloud
Most of the components can be migrated without any problems – virtual servers and disks to them look about the same for most cloud providers. Even the sets of operating systems provided and their versions may be the same. If there are too many images (hundreds or thousands), it is worth considering using server management automation tools: Chef, Ansible, Terraform. These tools can be used as an addition or alternative to images.
There are also ready-made mechanisms in the clouds to help avoid unnecessary manual labor. For example, on the MCS cloud platform, you can use an automated platform to migrate servers, data and applications. This does not override the use of configuration managers like Ansible or the approach of managing infrastructure as code.
Sometimes the services you need are named differently by different providers, so it’s worth taking a little time to explore the range of what the new cloud provider has to offer.
You need to migrate data by directly copying information from the infrastructure of the old provider to the new one. Plan these processes ahead of time and estimate how long they can take: for example, a hundred terabytes just cannot be migrated. Copying data is a simple process, but it requires attention to detail and a lot of time.
Networks and subnets are a thing that you can migrate without problems. Of course, there may be exceptions, for example if you need a particularly complex configuration. However, almost always you can easily combine servers in the network as you see fit, including using the provider’s capabilities to customize the channel data migrate protocol.
Cloud-to-cloud migration is a good time to upgrade your infrastructure. Use it to upgrade to newer OS and software versions. Somewhere you will want to reduce the power of virtual servers, and somewhere, on the contrary, increase.
Make a detailed plan of how you want to migrate subnets and virtual machines, with notes about updating the configuration files of server capacities and software versions.
Many people say that moving is like a fire, in fact – cloud-to-cloud migration will help bring more order to your infrastructure if you pay attention to planning.
Migrating what not all providers have
Almost all popular cloud platforms offer services that only they have. For example, these can be internal server monitoring systems, special load balancers, operating system distributions and proprietary programs.
The good news is that in the open-source world, for almost all of these things, there are acceptable solutions that can be implemented in the infrastructure after the move. Make a detailed plan of how you will replace the boxed solutions of your old provider with alternative software.
Proprietary solutions can almost always be replaced with alternative free software. There might be a cost to fix the code, but that doesn’t make the transition impossible.
Also evaluate what the new provider is offering for alternative uses. Perhaps, among its services there are indirect analogs of the usual functionality.
To avoid the need to move to another platform in the future, make sure that the chosen provider provides the cloud services that you may need in the future.
