A Comprehensive Cloud Migration Checklist
A Comprehensive Cloud Migration Checklist
More and more cloud providers are emerging and spreading their business across different regions in the current times. As a result, customers want to reduce their IT workload and migrate their product or application to a cloud-based environment. The primary reason behind this is that the cloud heavily reduces the overheads of investing in IT infrastructure, hardware upgrades, maintenance, etc.
Instead of focusing on the overheads, companies can focus on their business enhancement. Thus, the companies can now spend more time developing their business rather than their infrastructure. The migration process from on-premise to cloud infrastructure is a humongous task, and customers usually require a checklist to achieve it. Here is our list for helping your on-premises infrastructure take off to the cloud:
- Phase 1: Analyze Your System
- Phase 2: Define a Cloud Transformation Roadmap
- Phase 3: Conduct a POC and Gain Confidence
- Phase 4: Phase In the Migration
- Phase 5: Post Migration Optimization
- Migrate with Confidence
Phase 1: Analyze Your System
Before beginning with the migration process, you must have an in-depth analysis of the complete system. This analysis will help you understand the total number of applications that will be affected by the migration. Additionally, you will also figure out which applications would require refactoring or re-assessment in general. Since the underlying infrastructure is about to be changed, the new environment needs to be checked for any legal complications that it might create for the system.
Understand the System’s Complexity
It is vital to gather as much information as possible to aid in other decisions as well. Once you have the data, the next move is to analyze the systems’ complexity towards the process.
Identifying the business criticality of the application is an important step. Assuming that an application is critical for a business, it will be wise to migrate it to the cloud later because the process itself may affect its usability. A down application directly links to business losses. On the flip side, you can choose to migrate a low-priority application earlier, giving you insights into overall migration success.
Another critical factor to consider is the application dependencies. If an application has a high number of dependencies, it is advisable to migrate it in the later phases of the process. However, migrating such an application even towards the end of the process can still get tricky and slow the entire process down.
Evaluate the System’s Migration-Readiness
A company’s traditional IT infrastructure has a variety of workloads from various vendors with various timelines. There might be legacy systems running for decades on your data centers. You might not be willing to upset it until compulsorily needed.
Therefore, it is crucial to assess and analyze the criticality, feasibility, and possibility of a system’s probable migration to the cloud. A few critical questions to ask while doing these assessments are:
- Will the current projects run on cloud infrastructure, or are there any restrictions to run on a local environment only?
- Will the cloud provider support the original ecosystem of applications?
- Will the workload be supported by the product vendor for migration and post-migration in the new cloud environment?
A good practice is to consider first migrating those applications that simply need re-hosting or use minimal resources like low storage, computations, etc. Once you understand the current and expected system on the cloud, the next step—defining a migration roadmap—becomes more effortless
Phase 2: Define a Cloud Transformation Roadmap
Adopting cloud for a new workload is reasonably straightforward but migrating an existing one can be a massive venture and might require a definitive roadmap to follow. Defining a cloud transformation roadmap ensures that the process aligns well with the organization’s vision. Here are some of the steps you need to follow to define a clear cloud migration roadmap for your system.
Analyze Probable Cloud Provider/s and Service Provider/s
The first step in the process is to decide on the cloud and service provider(s) to migrate. Choosing a cloud provider will be based on several factors, such as:
- Availability in various regions
- Robustness against failures
- Compliance with all industry norms such as security standards, data protection norms, etc.
- Support experience post-migration
- Variety and innovation in services
- Cost-effectiveness
Based on the above-said factors, businesses can choose cloud hosting models, such as
- Single Cloud
- Multi-Cloud
- Private Cloud
- Hybrid Cloud
For organizations that do not specialize in cloud operations, it is not easy to migrate all by themselves. Fortunately, there are cloud migration service providers that work with these companies to drive the cloud migration program smoothly. For example, system integrator organizations such as CSC, Cognizant, Deloitte, etc., usually have cloud migration and support partnerships with cloud providers like AWS, Azure, GCP, etc. In addition, cloud providers themselves sometimes recommend some of their best-valued partners to the businesses.
Choose the Migration Strategy Based on 6 R’s
There are different types of migration strategies with which companies can choose to migrate their diverse workloads. These are often called the Six R’s. Identifying the correct migration strategy is vital to categorize and plan the workloads efficiently.
- Rehost: When migrating the workload to the cloud without any changes, companies can opt for this option. This type of migration can utilize the native tools provided by cloud providers. This method can also work across varied cloud platforms by using other migration tools available in the market.
- Replatform: This approach involves migrating the application without any significant architectural changes. For example, migrating the database from a PaaS service to IaaS. Another example would be choosing cloud-native web services over having a web server on IaaS.
- Repurchase: This approach proposes adding a few components to the existing application and provisioning them on the cloud, resulting in some architecture changes. However, it is wise to improve the application performance or expand your application while migrating it to the cloud.
- Refactor: This migration approach is suited for applications that need to be revamped and migrated to the cloud. Sometimes, migrating legacy applications is not possible due to unsupported platforms and technology. This approach is suitable for those applications. For example, you can refactor legacy applications running with older versions of .NET or Java to use the latest versions or re-architecture to function as microservices.
- Retire: It is a process of analyzing and identifying obsolete assets and services. There is no point in migrating redundant applications to the cloud. Instead, migration should focus on the services that will provide immediate business value. Therefore this approach prioritizes clearing out the obsolete services before migrating the application.
- Retain: Companies can choose applications or particular components to retain on-premise due to compliance, audit purpose, local infrastructure assets, etc. For example, they might need to keep certain assets like local AD/DNS servers for business purposes. So it is crucial to identify and assess these.
Prioritize Components
It is crucial to prioritize the applications to migrate. Large organizations have thousands of servers and applications, but it is impossible to start migrating all of them at once. Therefore, prioritizing becomes crucial.
To identify and prioritize the migrations process, you must consider these factors at the minimum:
- Prioritize applications that you can move with the least amount of risk to your business.
- The next tier phase should have apps that hold high value to your business but present a relatively low risk during migration.
- Put the mission-critical workloads to be migrated towards the end of the entire process.
Decide On the Standards, Processes, and Tools
Once you identify the hosting solution, cloud provider(s), and strategies, building architectural standards and analyzing migration processes is essential. Below are some points to keep in mind while doing so:
- Define the network topology for the cloud. Analyze the segregation process for the production and non-production networks.
- Establish a connection between on-premise and cloud. Identify the best-suited way of contact based on the business requirement and criticality.
- Adopt security tools to secure the cloud network and applications.
- Analyze integration of existing users and access policy with the cloud resources.
Every organization is most likely familiar with all types of tools and solutions like monitoring, network security, application security, backup, and storage for their on-premise infrastructure. So the usual question that they face while migrating is, “Should we use the existing tools in the cloud or switch to cloud-native tools?”. Companies can find the answer to this after analyzing the current situation based on factors such as:
- Will the on-premise solution work and suit the cloud?
- What will be the license implication in extending the existing solution?
- Are there any better and cheaper cloud-native solutions available?
Once an organization establishes these factors, they will serve as the layout for their application migration process.
Phase 3: Conduct a POC and Gain Confidence
Conducting a Proof of Concept (POC) is a critical factor in building confidence in the migration strategy and its workloads. So, it is essential to identify application designs and begin working on the POC.
Before starting with a POC, you need to take care of a few other things—performance benchmarks, dependency migration, and data migration plans. Let’s take a look at these first.
Identify Performance Benchmarks
One of the critical factors for successful cloud migration is the application’s performance in the cloud and the user experience. So it is vital to capture the performance benchmarks for all the applications on-premise. Some of the critical metrics for benchmarking are:
- CPU usage percentage
- Memory usage percentage
- Page loading time
- Key operations time
- User traffic
For example, if a database query function takes more time to load the results than the on-premise benchmarks, you can optimize it by following these steps:
- Increasing the connection count,
- Adjusting the time wait interval and operating system level by changing the paging value.
Identify Dependencies
An application usually depends on other components such as database, LDAP, network devices such as load balancer, traffic manager, messaging services, caching services, or other applications. Therefore it is crucial to identify the dependencies of individual applications and map them. Also, it is essential to have a plan for dependent components before beginning with the migration. Consider the following factors for dependency planning:
- Determine if you can migrate all components together or if they need to be migrated individually in different phases.
- Identify the impacts to the application if the components are separated, such as performance impact, cost implication, etc.
Create a Data Migration Plan
Migrating the existing data to the cloud is a very critical step. You need to plan and take extra caution here. There are different types of data, such as database records, files, media, etc. The migration team needs to plan the migration, keeping in mind the following factors:
- Importance: The criticality of the data determines the encryption method to be used. The encryption method affects the entire data transmission process.
- Size: The length of the data determines the cloud transformation method to be used.
- Temperature - The frequency of access to the data determines if it is easier to transfer. “Cold” data (accessed rarely) is generally trickier to migrate compared to “hot” data (accessed frequently).
All cloud providers offer native methods and tools which facilitate customers to transfer their data. If the data volume is enormous, you can use physical devices provided by the cloud providers to transfer the data securely to the cloud data centers. For example, AWS offers the following methods to transfer offline data:
- AWS Snowball - Enables transferring petabytes of data using a secured appliance.
- AWS Snowball Edge - Enables transferring petabytes of data using a device with onboard storage and compute capabilities.
- AWS Snowmobile - Enables transferring exabytes of data using a secured 40-feet shipping container
Here are some online data transfer methods offered by AWS:
- VPN - Establishes a secure connection between the datacenter and AWS over the existing MPLS.
- Direct Connect - Establishes a dedicated physical connection between the data center and AWS.
- AWS S3 Transfer Acceleration - Uses the public internet for secure data transfer to S3 storage buckets.
- AWS Data sync - These are tools used to automate the data transfer between datacenter and AWS
Apart from cloud providers’ native tools, some other tools offer advanced features and security measures to transfer data, such as Carbonite Migrate, Corent, etc.
Once done with the benchmarks, you need to carry out a POC by migrating a few low-complexity workloads to your new environment. Comparing their on-premise performance metrics with the latest cloud performance metrics will give you insight into how successful your migration and cloud adoption has been for you.
Phase 4: Phase In the Migration
This phase is where the primary step of the process begins. This phase is highly crucial to the entire process, and it is vital that you properly follow the plan you have built by now.
Migrate Your Workload
The migration begins by setting up the applications on the cloud based on the plans formulated above. After that, it is crucial to configure the network, security, storage, and other base architecture-level setups.
Once the basic architecture-level setup is complete, the next step is to move the resources based on the identified priority and plans. The POC from the last step serves as an excellent pilot for migrating the rest of the workload.
Test Your New Environment Well
Once you have migrated your workloads to the new environment, it is essential to test the new deployment thoroughly. The tests should cover various dimensions of the system, such as functional, performance, security, integration, and disaster recovery.
- Performance Testing: The migration process should not affect the application performance. So, you need to test your workloads with performance analysis in mind. Performance bottlenecks, if any, should then be optimized based on the test coverage results.
- Security Testing: Security testing covers authentication mechanisms in the application and data security. This testing involves ensuring the customer’s private data is not accessible from the outside and the system data is encrypted.
- Functional Testing: Functional testing involves testing applications with valid inputs and proper error messages on invalid information. In addition, it needs to test third-party integration with the application.
- Disaster Recovery: You need to monitor the uptime of the application to recover it quickly from disasters. It is critical to test these conditions after the migration process to ensure consistent uptimes.
It’s of utmost importance to address the challenges and test the applications during the migration process. Without testing the functionality and performance of the application in the cloud environment, it can cause issues like server crashes, database errors, and poor application performance. Consequently, it can affect the company’s business.
Switch Your Traffic
Once you are satisfied with all the test results and consistent availability is achieved from the new cloud deployments, it is time to switch your production traffic to the new systems. This step marks the induction of the cloud into your systems and workloads.
This step usually involves making changes in your DNS and other network routing systems to point the user traffic to the new system. You do not need to worry about any significant or sensitive changes here. If you face a surge in issues after switching, you can always switch back to the old system to buy yourself some time to fix the problems.
Phase 5: Post Migration Optimization
Phasing in the migration seems to have completed the process, but a few steps are still left to complete. These mainly include cleaning up on the old setup to cut down on costs and optimize the new environment to get the best out of the cloud.
Decommission On-premises Workload
Once you have migrated your systems to the cloud, you might want to close down the on-premise workloads running for the same purpose. Alternatively, you might want to retain these workloads in case of a breaking issue in the new environment. But if you are looking to make the best out of the cloud ecosystem, you need to optimize your new workloads and decommission old workloads.
Assess and Optimize Resources
Optimization is an ongoing process. It is essential to monitor and optimize the resources and assets in the cloud after the migration. The new workload might over-utilize some of the resources since most cloud services charge on an hourly basis. Therefore, it is crucial to monitor and perform optimization to reduce unnecessary expenses.
Most cloud providers offer recommendation systems for this purpose. For example, the Microsoft Azure Advisor service monitors the metrics of the services and provides recommendations based on the utilization. Say a virtual machine is being underutilized continuously for a certain period. The Advisor will recommend to scale-down the VM size to an optimal SKU.
Advisors also provide recommendations such as reserving the VMs, storage, etc., based on the usage. This practice is crucial to maintain sanity at the infrastructure level and keep the right resources cost-effective.
Migrate with Confidence
Cloud migration is all about adopting the latest tools and technology by moving business applications to the cloud. However, simply moving legacy workloads to the cloud can be a stop-gap approach and not a permanent solution. It merely means that the applications are not utilizing the cloud to their fullest extent. Therefore it is essential to drill deep into migrating a typical application to a cloud-first architecture before rehosting it on the cloud.
The more you move towards containers and microservices, the more you will save on the cost and resources. You can then shift your focus towards giving your users the best possible experience. The cloud transformation roadmap discussed before does not end once you migrate the application to the cloud. Instead, it should extend towards modernizing the application using the powers of the cloud.