Migrating a workload from your legacy on-premises environment to a cloud-native environment, such as a public cloud, can be challenging and risky. Successful migrations change the workload to migrate as little as possible during the migration operations. Moving legacy on-premises apps to the cloud often requires multiple migration steps

There are three major types of migrations that you can consider:

• Lift and Shift
• Improve and Move
• Rip and Replace

Lift and Shift (Rehost)

Known as “Moving out of a data center”, the easiest of all workload migrations, lift and shift is the movement of your workload from your on-prem environment to the cloud with little to no modifications or refactoring. The only modifications that are necessary are those just required to get your applications working in the cloud environment.

Lift and shift migrations are best when the workload can still operate as-is in the cloud environment or where you have no business need for the change or where technical constraints won’t allow it any other way. This could be due to complicated source code that would be difficult to refactor.

On the down side, lift and shift migrations are considered non-cloud-native workloads that happen to be running in the cloud. These workloads don’t take full advantage of cloud platform features, such as horizontal scalability, more controlled pricing, and having highly managed services.

Improve and move (Replatform)

Known as “Application Modernization”, in an improve and move migration, you modernize much of your workload while migrating it. The idea is to modify the workloads to take advantage of cloud-native capabilities, as opposed to simply just trying to make them work in the cloud environment like we did with Lift and Shift. You can improve each workload for performance, features, cost, or user experience.

Improve and move migrations let your applications use features of a cloud platform, such as scalability and high availability. You can also architect the improvement to increase the portability of the application.

The downside here is that improve and move migrations take longer than lift and shift migrations, because they must be refactored in order for the applications to migrate.

Rip and Replace (Refactor)

Known as “Building in and for the cloud”, with rip and replace migration, you are not migrating your applications, but completely decommissioning them and rebuilding and rewriting them as a cloud-native app.

If your current applications are not meeting your goals, for example, you are sick of maintaining it or it would be too costly to migrate, or perhaps its not even supported on Google Cloud, you can do a rip and replace.

This migration allows your application to take full advantage of Google Cloud features, such as horizontal scalability, highly managed services and high availability.

However, rip and replace migrations can take longer than lift and shift or improve and move migrations. Further, this type of migration isn’t suitable for off-the-shelf applications because it requires rewriting the apps. You need to think about the extra time and effort to redesign and rewrite the apps as part of its lifecycle.

Migration Path

The goal with a cloud migration is to get from point A (where you are now on-prem) to point B (in the cloud). To get from A to B you can use any of the methods we just discussed.

The journey from A to B can be summarized as:

Assess

Perform a thorough assessment and discovery of your existing environment in order to understand your app and environment inventory, identify app dependencies and requirements, perform total cost of ownership calculations, and establish app performance benchmarks.

• Take Inventory: databases, message brokers, data warehouses, network appliances and dependencies. Machines + OS + specs
• Catalog Apps: Mission critical, non-mission critical
• Educate: Train and certify engineers on Google Cloud – frameworks, APIs, libraries
• Experiment / POC: Run a bunch of POCs such as firewall rules, performance on Cloud SQL, play with Cloud Build, play with GKE Clusters
• Calculate total cost of ownership: Google Cloud vs On-Prem. Which is cheaper? Use the Google Cloud price calculator
• Choose what workloads to first migrate: Non business critical, dependency-light workload, requires minimal refactoring

Plan

Create the basic cloud infrastructure for your workloads to live in and plan how you will move apps. This planning includes identity management, organization and project structure, networking, sorting your apps, and developing a prioritized migration strategy.

• Establish Identities: Google Accounts, Service Accounts, Google Groups, Google Workspace Domains, Cloud Identity Domains
• Design Resource Organization: Organizations, Folders and Projects
• Define hierarchy: Environment-oriented, function oriented or granular access-oriented
• Define groups and roles for resource access:
  • Org Admin: IAM policies
  • Network Admin: networks, subnetworks, Cloud Router, Cloud VPN, Cloud Load Balancing
  • Security Admin: IAM roles for projects, logs and resource visibility
  • Billing Admin: billing accounts, monitor resource usage
• Design Network Topology / Establish Connectivity: Create VPC(s), cloud interconnect/peering/cloud VPN/Public internert

Deploy

Design, implement and execute a deployment process to move workloads to Google Cloud. You might also have to refine your cloud infrastructure to deal with new needs.

• Fully manual deployment: do everything from provision, configuration and deployments manually
• Configuration Management (CM) Tools: Deploy in automated, repeatable way. Is a bit complicated.
• Container Orchestration: GKE to orchestrate workloads
• Deployment Automation: CI/CD Pipeline to automate creation and deployment of artifacts
• Infrastructure as Code (IaC): Terraform or Deployment manager

Optimize

Begin to take full advantage of cloud-native technologies and capabilities to expand your business’s potential to things such as performance, scalability, disaster recovery, costs, training, as well as opening the doors to machine learning and artificial intelligence integrations for your app.

• Build and train your team: Train deployment and operation teams to know new cloud environment.
• Monitor everything: Cloud Logging and Cloud Functions, Prometheus, Cloud Monitoring alerting
• Automate everything: Automate critical activities such as deployments, secrets exchanges, and configuration updates. Automating infrastructure with Cloud Composer and Automating Canary Analysis on Google Kubernetes Engine with Spinnaker are examples of automation on Google Cloud.
• Codify everything: Infrastructure as Code and Policy as Code, you can make your environment fully auditable and repeatable
• Use managed services instead of self-managed ones: Cloud SQL for MySQL instead of managing your own MySQL cluster, for example.
• Optimize for performance and scalability: Compute Engine autoscaling groups, GKE cluster autoscaler, etc.
• Reduce costs: analyze your billing reports to study your spending trends, etc.

More information can be found here: https://cloud.google.com/architecture/migration-to-gcp-getting-started