I once heard someone say, "What the cloud migration strategies lack at the moment is a methodology to Lift-and-Shift connections to the cloud." Let's digest that.

In today's landscape, maintaining a competitive edge and delivering a high-quality customer experience is becoming synonymous with migrating to the cloud. As of 2022, [57% of organizations](https://info.flexera.com/CM-REPORT-State-of-the-Cloud)57% of organizations are migrating more workloads to the cloud.

A typical decision in the cloud migration strategy is to containerize existing workloads when possible and adopt Kubernetes as the platform of choice. However, to fully reap the benefits of the cloud requires more than just lifting-and-shifting monolithic workloads to Kubernetes. It requires a migration and modernization strategy that can work at scale by simultaneously supporting legacy workloads, modernization efforts to re-architect to microservices, and greenfield development.

The unintended consequence of many cloud migrations is the overhead of managing the connectivity of application states that become distributed across on-prem and the cloud (i.e., the hybrid cloud paradigm).

Here we want to introduce the Crawl/Walk/Run Cloud Migration Strategy, which uses Kong Konnect and Kong Mesh as the underlying technologies. It will support any cloud migration transformation strategy to Kubernetes or ECS at scale.

## Who is the Crawl-Walk-Run Strategy for?

The purpose is to offer a powerful networking solution that is both sustainable and flexible.

The migration strategy provides a solid platform to support any tech decision related to modernization and move-to-cloud strategy — Kubernetes, ECS, and EC2.

It prescribes how to build a network foundation layer that can support any cloud migration strategy (lift-and-shift, green development, re-architect to microservices), even simultaneously if needed.

This is an approach that allows businesses and the engineering teams to work cohesively to reach the cloud.

• - **From the business perspective, **this solution derisks the application modernization and migration efforts.
• - **From the technical perspective, **this solution derisks cloud migrations because it delivers a robust and flexible network foundation that reduces network complexity thus allowing more energy to focus on business initiatives.

So who is this strategy for? It's for product leaders and for engineering leaders that want to reach the cloud.

## Kong Konnect and Kong Mesh joint solution

From a technical perspective, the objective is to create a cross-platform logical network topology that allows VM-based applications and cloud-based applications to easily communicate.

### Build the network foundation

**Kong Mesh** natively supports creating a distributed mesh network that spans on-prem monolith services and microservices in Kubernetes.

**Kong Konnect **natively supports multi-platform deployments and Kong Mesh to offer north-south security from anywhere including being a part of the mesh network.

An example of the joint solution of Kong Mesh and Kong Konnect is represented with the diagram below:

**Kong Mesh **

• - **Multi-Platform Deployment Strategy** – Kong Mesh supports Kubernetes, VMs, and bare metal deployments.
• - **Multi-Zones –** Mesh deployments are not mutually exclusive of each other. With the concept of zones, VM-based zones and cloud-based zones can interact.
• - **Distributed-Mesh** – Mesh networks can be layered across the zones to allow for applications hosted within those zones to communicate.
• - **Delegated Gateways** – Easily onboard a Gateway for north-south security.

**Kong Konnect **

• - **Multi-Platform Deployment Strategy – **Provides the flexibility to deploy a Gateway on-prem or in the cloud.
• - **Kong Mesh Support** – Kong Mesh is natively supported.

### Cross-platform traffic management

Once the networking foundation is in place, the same traffic management features offered by all service mesh technologies still apply to the mesh network being managed by Kong Mesh.

As a result, the same L4 and L7 traffic routing capabilities can now be used to retire monolithic APIs one at a time and redirect traffic to new microservices.

But, it's important to note, the routing decision is not made by the gateway; it's made by Kong Mesh. In other words, the migration process is abstracted, from the gateway perspective, by the mesh. Gateway is responsible for enforcing mesh-wide north/south security-related policies.

## Crawl/Walk/Run three-phase migration approach

Introducing technologies into an organization is extremely daunting. We often bite off more than we can chew. So we developed a three-phased approach that allows organizations to incrementally build out the network foundation.

• - **Crawl: **Create a Baseline
  
  • - Deploy a Kong Konnect runtime-instance on-prem and onboard the monolith.

The objective of the *Crawl *phase is to control the exposure of the entire application regardless of where the application will be deployed. There should be no major changes to the monolith or to the functionality that an API consumer experiences.

Check out [*A Crawl/Walk/Run Strategy – Part 1: Crawl*](https://www.youtube.com/watch?v=fKgO6I9H27k)*A Crawl/Walk/Run Strategy – Part 1: Crawl* on YouTube for more details.

• - **Walk:** Extend the Foundation
  
  • - Deploy the cloud infrastructure.
  • - Deploy the distributed mesh on-prem and in Kubernetes.
  • - Onboard the Kong Konnect runtime-instance and the monolith to the mesh.

In the *Walk* phase, it's all about setting up the mesh network foundations, teams building out new microservices in the cloud, and preparing for the cutover. These activities (building the mesh and building out microservices) can happen in parallel. At the end of the day, the expectation for an API consumer is that there will be no major changes to the monolithic application's functionality.

Check out [*A Crawl/Walk/Run Strategy – Part 2: Walk*](https://www.youtube.com/watch?v=GLuBYeqBcHQ)*A Crawl/Walk/Run Strategy – Part 2: Walk* on YouTube for more details.

• - **Run:** Leverage the Foundation to Cutover
  
  • - With mesh traffic policies, redirect traffic and deprecate the old for the new.

In the final phase, with the network foundation in place, consisting of both Gateway and Mesh, it’s time to migrate components of the monolith. Using the new platform, expose the new microservice by defining routing policies and pair down the behavior of the monolith. If the rollout is unsuccessful and these changes need to be rolled back, rollback strategies are much easier to handle because the traffic management is centralized to the mesh.

Check out [*A Crawl/Walk/Run Strategy – Part 3: Run*](https://www.youtube.com/watch?v=69hUIW7H)*A Crawl/Walk/Run Strategy – Part 3: Run* on YouTube for more details.

### Conclusion

Check out Marco Palladino, CTO, and Andrew Huffman, Director of Partner Engineering, stepping through the Cloud/Walk/Run strategy live at [AWS re:invent 2022.](https://www.youtube.com/watch?v=tbtV8UQKm_s)AWS re:invent 2022.

We've open sourced the tutorial: go ahead and download the [GitHub Repository](https://github.com/Kong/cloud-migration-journey)GitHub Repository to run through the self-paced tutorial on your own.

Or, check out our three-part video series made to accompany the tutorial [on YouTube](https://www.youtube.com/watch?v=fKgO6I9H27k)on YouTube.