Cloud Migration Checklist: what to do and why to do it

Written by FedakV | Published 2018/11/05
Tech Story Tags: devops | cloud | cloud-computing | kubernetes | cloud-migration

TLDRvia the TL;DR App

Every company has to perform a cloud migration at some point of their scaling up. We provide a cloud migration checklist to help you make the right choices and avoid mistakes.

We have already covered the most common mistakes made during cloud transition and mentioned the right approaches to dealing with the challenges that arise. Today we describe the best-case scenario of cloud migration and explore the steps needed to make everything work fine:

  1. IT infrastructure audit
  2. Identifying the existing issues and designing the solutions for them
  3. Designing a migration plan
  4. Designing the optimal cloud infrastructure
  5. Completing a pilot project in parallel with the legacy processes to test the system
  6. Improving the infrastructure based on the pilot project feedback and outcomes
  7. Moving the system components to the cloud (product code, databases, media content and scripts, etc.)
  8. Configuring the CI/CD pipelines, cloud monitoring, logging and alerting solutions

Below we describe each of these steps in more details.

IT infrastructure audit

As the business grows, their IT infrastructure grows with them. In the perfect world, the growth goes along the planned lines and the infrastructure is built according to a long-term strategy to support that growth. In real life, however, the IT infrastructure is usually expanded in a somewhat chaotic way.

Thus said, the first step to the cloud transition is performing a thorough audit of existing IT infrastructure, workflows, tools and processes in place. This audit can be performed internally, by your IT department, or by hiring a dedicated DevOps team to assess the situation. The audit involves interviewing the stakeholders and gathering all the data and documentation available to form a holistic picture of the processes and tasks your IT infrastructure must support.

There can be two outcomes of such an audit. The infrastructure can be either lifted-and-shifted to the cloud or rebuilt from scratch using the cloud-native components when the databases are synchronized with their cloud analogs and the rest is replaced with new modules. The latter approach is longer, costs more but provides the best results long-term. However, most of the customers prefer to choose the former variant and try to lift-and-shift their systems to the cloud. Omitting the IT infrastructure audit can be the doom of the whole project, and is highly inadvisable for any business. The only exclusion might be moving the really small systems with a clear structure, but these are usually created in the cloud from the start nowadays.

Identifying the existing issues and designing the solutions for them

Once the audit is complete, certain bottlenecks and weak spots become visible. Taking them with you to the cloud is wasteful, so the solutions for these issues must be designed. Most of these problems are usually solved by the cloud structure itself, like providing the horizontal scalability and high-availability, but some flaws usually need correction before passing on. These improvements become the parts of the global cloud migration plan.

Otherwise, cloud migration will not provide any tangible benefits, as all the old discrepancies and inefficiency will remain in the cloud processes and will hamper your further growth.

Designing a migration plan

A migration plan is a holistic roadmap of the goals the business wants to achieve through the cloud migration, the means to reach these goals and the milestones for measuring the progress of the project. The better the preceding audit, the more detailed Key Performance Indicators can be selected, and the more visible the project status will be.

Moving on without a plan can be devastating for the project, as it is quite clear that the totally incorrect sequence of actions will lead to a disaster.

Designing the optimal cloud infrastructure

There are multiple cloud service providers (CSPs) like AWS or Azure, GCP or DigitalOcean. Depending on the needs of your business, some offers might be better suited for your systems than others. In addition, modern DevOps tools allow building cloud-agnostic infrastructures, when the data is stored with GCP, but processed by AWS and the scripts are executed using Azure Functions. Usually, however, such complex structures are not needed, and selecting the optimal cloud destination helps satisfy all the needs of the project.

However, opting blindly for provider-specific features and products (like AWS RDS, Google Bigquery, AWS Fargate or AWS Aurora) can lead to overpaying for the services you do not actually need. Thus said, an in-depth knowledge of the cloud products and offers from various CSPs helps to understand the optimal selection of modules for your case.

Completing a pilot project in parallel with the legacy processes to test the system

Once the new cloud infrastructure for your business is completed, it should be tested by moving some of the lesser systems there as a pilot project. This will allow determining if your assumptions of the workloads were correct, if the system is scalable to your needs, if the transition handling is adequate, etc.

Going full-on with migrating all the systems at once can result in major system breakdown and prolonged service downtime, which is unacceptable in the nowadays business.

Improving the infrastructure based on the pilot project feedback and outcomes

Once the pilot is completed and the feedback is gathered, the cloud systems can be tuned based on the results of the project. For example, sometimes it becomes obvious that Auto-Scaling groups should be used instead of configured instance clusters, that a bastion host should be used to provide secure admin access to the system, or that an automated database backup should be configured using Terraform, instead of the platform-specific tools.

Moving the system components to the cloud

Once everything is ready, the actual cloud migration can begin. The product code can remain in GitHub, but the rest of the resources (databases, website media content, scripts, etc.) must be moved to the cloud. The most important part of this transition is moving the domain name to the cloud service provider beforehand, to avoid post-migration downtime. This is due to the fact, that CSPs allow setting the TTL for nameserver records as little as 3 seconds, so the migration will be seamless.

The legacy databases must be synced with the cloud databases. Be aware, that MySQL can be 100% synced with MySQL only, so swapping the database (to Redis or Cassandra) during the cloud migration requires writing lots of custom code and is generally inadvisable. The cloud replica of your DB must run in parallel with the legacy one to synchronize, then the legacy DB is shut down and your database operates from the cloud from now on. Moving the media content and scripts is usually simpler, as they are not updated as intensely as the DB records.

Configuring the CI/CD pipelines, cloud monitoring, logging and alerting solutions

Once your products or services arrive at the cloud, you gain access to DevOps best practices like Continuous Integration / Continuous Deployment (CI/CD) and managing the Infrastructure as Code (IaC). This means that instead of provisioning and configuring each separate server, cloud-based businesses manage their resources with the help of configuration scripts, like Kubernetes and Terraform manifests, which can be stored at GitHub, versioned and adjusted as any other code. This helps in decreasing the environment setup time significantly.

In addition, most of the mundane daily IT tasks can be automated using Jenkins, Ansible and other CI/CD tools, so that your IT team will be able to concentrate on moving your business forward, instead of doing the repetitive configuration and maintenance jobs. One of the most popular CI/CD pipelines involves the automated process of provisioning the testing and staging servers for the new batch of code and pushing the new product release into production automatically, should the code pass the automated unit tests. This way, every developer can deliver new code without waiting for Ops to provide the server resources, dramatically decreasing the time to market for new product features.

Similar CI/CD pipelines can be created for monitoring, logging and alerting systems. This enables the AIOps approach to infrastructure monitoring, where most of the repetitive incidents are solved before they even occur, removing much of the mundane workloads of the IT team. This can be done using the tools like Zabbix, Prometheus+Grafana and other components of the DevOps monitoring toolkit.

Conclusions on the cloud migration checklist

As you can see, cloud migration is quite a doable endeavor, if it is executed according to a straightforward checklist. However, there are multiple underwater reefs that pose a grave danger for the project, should it be performed by a team without previous experience of such kind.

Thus said, cloud migration is one of the most popular services provided by reliable Managed Services Providers worldwide. These companies have ample experience designing and implementing the cloud migration plans, allowing their customers reach the business goals set, optimize their product or services performance and deliver more value to their customers while spending less on their IT infrastructure maintenance.

Are you planning a cloud migration now? IT Svit stands ready to help!

Originally published at itsvit.com on October 30, 2018.


Published by HackerNoon on 2018/11/05