Cloud Migration Strategy & Tips

There has been a strategic shift in the IT landscape from ‘build to consume’ and enterprises are taking huge strides in migrating a large number of their traditional and virtualized on-premises workloads onto a cloud computing infrastructure.

The benefits of migrating to a cloud infrastructure are fairly obvious and compelling — lower CapEx, OpEx and maintenance costs, unlimited scalability on demand, redundancy, 24*7 availability, best-in-class enterprise security, monitoring and compliance. However the business and technical risks associated with undertaking such migrations are manifold and often less well understood.

i’ll briefly describe some commonly adopted strategies for migrating your application workloads on to any cloud infrastructure. Additionally, I’ll provide a checklist to analyze your application workloads for their suitability for migration and lay down some steps to follow for on-boarding applications successfully on to a cloud environment.

Define Cloud Migration Strategy

One of the key challenges for cloud migration is to determine the path by which each application workload can potentially be transitioned on to the cloud. There are several paths to consider — although categorization provided by Gartner is one of the most widely accepted. The categories for cloud migration are described below -

Lift and Shift

This is the simplest migration strategy that involves moving the underlying infrastructure to run on virtual servers in the cloud and then porting the legacy applications to the new environment “as-is” without performing any refactoring.

This low-barrier-to-entry approach can provide quick gains for enterprises who incur significant operational expenditure to run workloads in their current on-premise data centers. It causes minimal disruption to the applications that are being migrated. The transition process itself is significantly faster and much less costly requiring less resources.

However, this strategy has several limitations. Firstly, not all applications are suitable for lift and shift style migration especially if they are resource intensive or have any dependencies on any third party services that may need licenses to run in the cloud. Secondly, it comes up short in realizing the optimal and tangible benefits of a modern cloud platform in terms of enhanced scalability, availability, performance, security etc. In fact, it may be more expensive to run certain workloads in the cloud without making any refactoring whatsoever.

A lift and shift migration process typically entails the following steps as illustrated in the diagram below:

Most cloud platform providers provide some tools to automate lift and shift tasks. Amazon AWS provides tools, most notably Snowball and VM Import/Export to migrate petabyte-scale data and virtual machines in and out of the public cloud.

Refactoring

This entails making major changes to your application code and/or configuration in order to migrate them over to the cloud. This typically follows a determination that your application, in its current state, is not suitable to be run on the cloud. In most cases your architectural design choices seems to pose severe limitations on your ability to scale out the application, recover gracefully from hardware failures, improve performance and build new features. Once refactoring is completed, applications should be able to run natively on a PaaS rather than having to be installed within custom VMs running on the cloud. This leads to a better level of integration between the applications inside the PaaS. It allows the customer to focus on applications rather than the platform. However, the migration effort is much more costlier, riskier and time consuming.

Re-Platforming

This migration strategy is ideal for customers who want to modernize their applications by extending them to the cloud and make them operate as part a larger distributed system. This involves taking advantage of horizontally scalable cloud services delivered by PaaS vendors like swapping your local RDBMS databases with datastore-as-service offering like RDS or switching your messaging systems with SNS service from AWS.

Re-platformed apps benefits from dynamic allocation and reallocation of resources, autoscaling, availability and improved security. Additionally, it disrupts the traditional software licensing model and replace it with utility and subscription based pricing model that cloud vendors offer, resulting in lower overall costs of operation.

However, the cost of re-platforming apps is significant higher since it inevitably requires code changes to perform more natively on a cloud platform. Furthermore, it need building up sufficient technical expertise among your IT staff on various cloud platforms services.

Analyzing Workloads for Migration

A key decision that needs to be made along with determining your overarching cloud migration strategy is to analyze and select workloads that are suitable for migration. Most organizations have a heterogeneous mix of new, legacy and third-party applications. Accordingly, each of these applications needs to evaluated and categorized in terms of their migration complexity, costs and risks. Each of them need to assigned a appropriate migration method that minimizes all of the above.

There are typically two broad considerations to make when deciding the cloud deployment model and hosting options -

It is a complex process to navigate your application landscape and analyze the workloads that provides the best tradeoff between the ease of migration and potential cost benefits that accrue from the cloud. Asking the following questions could be the first step towards rationalizing your application portfolio and determining their business criticality.

As cloud platforms have matured over the years, there is a growing trend within organizations to architect and/or refactor applications to take full advantage of the platform. Greenfield applications provides an excellent opportunity to start building on a cloud platform using cloud-first principles from day one. However, legacy migration demands a more incremental approach where you can start transitioning business logic to the cloud by creating cloud-native microservices that will strangle legacy components, one at a time. To ensure a seamless integration between the new cloud workloads and services that are not migrated, it may be necessary to build a hybrid cloud infrastructure comprising of your on-premise data center and the public/private cloud.

There are some basic software architecture principles that are absolutely critical to ensure your application works well on any cloud provider platform and realizes all the benefits of performance, scalability and availability. Most of these principles derive from the fact that any cloud computing infrastructure is ephemeral, highly distributed and prone to intermittent failures. Most applications need some degree of refactoring to adhere to those principles and qualify as cloud ready. A quick look at these technical guidelines will help you determine which application workloads can be migrated with least amount of refactoring.

Cloud On-Boarding Steps

Once the application workloads have been identified for migration, they must be prepared for on-boarding on to the cloud environment. Successful application on-boarding is all about careful planning and preparation.

Preparing the application for migration involves implementing all the refactoring /re-platforming changes identified for it to work well in the cloud. Also, it usually involves containerization or virtualization of the workload, if not already done so.

Once the application is ready, the next step is to provision the resources on the cloud environment based on the number or type of virtual machines required for the migration. Any additional storage, database, network, compute instances need to be provisioned.

This is typically followed by the actual transfer of the application and any associated databases and services which are being migrated along with the application. It also requires setting up environment metadata which is often very provider-specific. Account structures, users, permissions, policies, load balancers, and the like vary from cloud to cloud. Ensure data security controls are not compromised at any stage during the migration process.

For a smooth, seamless integration it is necessary to establish a 2-way network connectivity between your existing on-premise network and the target cloud environment. This helps in the migration process itself and allows for any integration or aggregation of capabilities across the network between your on-premise data center and the cloud.

The final steps are to test and validate the application deployment in the cloud and ensure all the technical testing (functional, integration, performance, security), user acceptance are passing without any failures. Special attention needs to be given to check data consistencies especially after the databases are replicated and synchronized onto the cloud.

Once the cloud deployed application is qualified, it is time to cutover and retire the old application instances.

After the migration is accomplished successfully, it is necessary to monitor the application and its usage patterns while it is operating in the cloud. There are a variety of tools available that can help in providing application-level insights and monitoring.

Conclusion

Migrating to a cloud is a complex undertaking. It requires a comprehensive plan and a considerable level of organizational readiness to push through the cultural, technical and process changes needed to implement a cloud-first strategy. A cohesive and consistent approach is needed to evaluate various service providers, cloud services, deployment models, data security requirements etc. The ultimate objective is to strike a balance between operational risks and expected benefits.