This document helps you plan, design, and implement the process of migratingyour workloads to Google Cloud. Moving apps from one environmentto another is a challenging task, even for experienced teams, so you need toplan and execute your migration carefully.

This document is part of the following multi-part series about migrating toGoogle Cloud:

• Migrate to Google Cloud: Get started (this document)
• Migrate to Google Cloud: Assess and discover your workloads
• Migrate to Google Cloud: Plan and build your foundation
• Migrate to Google Cloud: Transfer your large datasets
• Migrate to Google Cloud: Deploy your workloads
• Migrate to Google Cloud: Migrate from manual deployments to automated, containerized deployments
• Migrate to Google Cloud: Optimize your environment
• Migrate to Google Cloud: Best practices for validating a migration plan
• Migrate to Google Cloud: Minimize costs

This document is useful if you're planning a migration from an on-premisesenvironment, from a private hosting environment, from another cloud provider toGoogle Cloud, or if you're evaluating the opportunity to migrate andwant to explore what it might look like.

Beginning the journey

When planning your migration to Google Cloud, you start by defining theenvironments that are involved in the migration. Your starting point can bean on-premises environment, a private hosting environment, or anotherpublic cloud environment.

An on-premises environment is an environment where you have full ownership andresponsibility. You retain full control over every aspect of the environment,such as cooling, physical security, and hardware maintenance.

In a private hosting environment such as acolocation facility,you outsource part of the physical infrastructure and its management to anexternal party. This infrastructure is typically shared between customers. In aprivate hosting environment, you don't have to manage the physical security andsafety services. Some hosting environments let you manage part of the physicalhardware, such as servers, racks, and network devices, while othersmanage that hardware for you. Typically, power and network cabling areprovided as a service so you don't have to manage them. You maintain fullcontrol over hypervisors that virtualize physical resources, the virtualizedinfrastructure that you provision, and workloads that you run on thatinfrastructure.

Apublic cloud environment has the advantage that you don't have to manage the whole resource stack byyourself. You can focus on the aspect of the stack that is most valuable to you.Like in a private hosting environment, you don't have to manage the underlyingphysical infrastructure. Additionally, you don't have to manage the resourcevirtualization hypervisor. You can build a virtualized infrastructure and candeploy your workloads in this new infrastructure. You can also buy fully managedservices, where you care only about your workloads, handing off theoperational burden of managing runtime environments.

For each environment, this document evaluates the following aspects as well aswho should provide and manage the relevant services:

In this document, the target environment isGoogle Cloud.

After you define your starting and target environments, you define the workloadtypes and the related operational processes that are in scope for the migration.This document considers two types of workloads and operations: legacy andcloud-optimized.

Legacy workloads and operations are developed without anyconsideration for cloud environments. These workloads and operations can bedifficult to modify and expensive to run and maintain because they usually don'tsupport any type of scalability.

Cloud-optimized workloads and operations arenatively scalable, portable, available, and secure. The workloads and operationscan help increase developer productivity and agility, because developers canfocus on the actual workloads, rather than spending effort to manage developmentand runtime environments, or dealing with manual and cumbersome deploymentprocesses. Google Cloud also has ashared responsibility model for security. Google Cloud isresponsible for the physical security and the securityof the infrastructure, while you're responsible for the security of theworkloads you deploy to the infrastructure.

Considering these environment and workload types, yourstarting situation is one of the following:

• On-premises or private hosting environment with legacy workloads andoperations.
• On-premises or private hosting environment with cloud-optimized workloadsand operations.
• Public cloud or private hosting environment with legacy workloads andoperations.
• Public cloud or private hosting environment with cloud-optimized workloadsand operations.

The migration process depends on your starting point.

Migrating a workload from a legacy on-premises environment or private hostingenvironment to a cloud-optimized environment, such as a public cloud, can bechallenging and risky. Successful migrations change the workload to migrate aslittle as possible during the migration operations. Moving legacy on-premisesapps to the cloud often requires multiple migration steps.

Types of migrations

This document defines the following major types of migrations:

• Rehost: lift and shift
• Replatform: lift and optimize
• Refactor: move and improve
• Re-architect: continue to modernize
• Rebuild: remove and replace, sometimes calledrip and replace
• Repurchase

In the following sections, each type of migration is defined with examples ofwhen to use each type.

Rehost: lift and shift

In a rehost migration, you move workloads from a source environment toa target environment with minor or no modifications or refactoring. Themodifications you apply to the workloads to migrate are only the minimum changesyou need to make in order for the workloads to operate in the targetenvironment.

A rehost migration is ideal when a workload can operate as-is in thetarget environment, or when there is little or no business need for change. Thismigration is the type that requires the least amount of time because the amountof refactoring is kept to a minimum.

There might be technical issues that force a rehost migration. If youcannot refactor a workload to migrate and cannot decommission the workload, youmust use a rehost migration. For example, it can be difficult orimpossible to modify the source code of the workload, or the build process isn'tstraightforward so producing new artifacts after refactoring the source codemight not be possible.

Rehost migrations are the easiest to perform because your team cancontinue to use the same set of tools and skills that they were using before.These migrations also support ready-made software. Because you migrateexisting workloads with minimal refactoring, rehost migrations tend tobe the quickest, compared to refactor or rebuild migrations.

However, after a rehost migration, the workloads that are running in the targetenvironment aren't optimized for the cloud. These workloads don'ttake full advantage of cloud platform features, such as horizontal scalability,fine-grained pricing, and highly managed services.

Replatform: lift and optimize

In a replatform migration, you lift the existing workloads and then optimizethem for the new cloud environment.

A replatform migration is best for organizations that want to take advantage ofall the core competencies of the cloud. These competencies include elasticcomputing, redundancy, improved performance, and security.

For example, you might replatform a workload to the cloud in order to takeadvantage of a cloud-based microservice architecture or containers inGoogle Kubernetes Engine. These workloads will then have higher performance and moreefficiency running in the cloud.

However, replatform migrations take more work to accomplish than rehostmigrations. The new cloud platform will have a different underlying codebase,which requires several rounds of testing to make sure that everything isrunning at its optimal level.

Refactor: move and improve

In a refactor migration, you modify the workloads to take advantage ofcloud capabilities, and not just modify the workloads to make them work in the newenvironment. You can improve each workload for performance, features, cost, anduser experience.

You can modify the workloads while you're migrating them to the cloud, or evenbefore migrating them. For example, if you don't have substantial experience withcloud migrations, you might prefer to modify the workloads while you'remigrating. However, if you have cloud migration experience, you mayalready have an idea of the modifications that the workloads need to takefull advantage of cloud capabilities.

If the current architecture or infrastructure of an app isn't supported in thetarget environment as it is, a certain amount of refactoring is necessary toovercome these limits.

Another reason to choose the refactor approach is when a major updateto the workload is necessary in addition to the updates you need to make tomigrate.

Refactor migrations let your app take advantage of features of a cloud platform,such as scalability and high availability. You can also architect theimprovement to increase the portability of the app.

However, refactor migrations take longer than rehostmigrations because the workloads must be refactored in order for the app tomigrate.

A refactor migration also requires that you learn new skills.

Re-architect: continue to modernize

Re-architect migrations are similar to refactor migrations. However, instead ofrestructuring how the workload code works, re-architect migrations changehow that code functions. Those code changes optimize the workload and takeadvantage of cloud-optimized properties such as scalability, security,and agility. For example, a re-architect migration can take one large,monolithic workload and turn it into several independent microservices that youdeploy on Google Cloud.

A re-architect migration is more complex than a refactor migration, so ittakes more time and effort. A re-architect migration can also potentiallyintroduce bugs or security issues into the new workloads. Thus, a re-architectmigration requires several rounds of testing to make sure that everything isrunning at its optimal level.

Rebuild: remove and replace

In a rebuild migration, you decommission an existing app and completelyredesign and rewrite it as a fully cloud-optimized app.

If the current app isn't meeting your goals—for example, you don't wantto maintain it, it's too costly to migrate using one of the previously mentionedapproaches, or it's not supported on Google Cloud—you can do arebuild migration.

Rebuild migrations let your app take full advantage ofGoogle Cloud features, such as horizontal scalability, highly managedservices, and high availability. Because you're rewriting the app from scratch,you also remove the technical debt of the existing, legacy version.

However, rebuild migrations can take longer than rehost orrefactor migrations. Moreover, this type of migration isn't suitable forready-made apps because it requires rewriting the app. You need to evaluatethe extra time and effort to redesign and rewrite the app as part of itslifecycle.

A rebuild migration also requires new skills. You need to use newtoolchains to provision and configure the new environment and to deploy the appin that environment.

Repurchase

A repurchase migration is when you move from a purchasedon-premises workload to a cloud-hosted software-as-a-service (SaaS) equivalent.For example, you can move from on-premises collaboration software and localstorage to Google Workspace.

From a resources perspective, a repurchase migration might be a lot easier thanrefactoring, rebuilding, or re-architecting. However, a repurchase migrationmight be a lot more expensive and you might not get the granular features ofcontrolling your own cloud environments.

Google Cloud Adoption Framework

Before starting your migration, you should evaluate the maturity of yourorganization in adopting cloud technologies. TheGoogle Cloud Adoption Framework serves both as a map for determining where your business information technologycapabilities are now, and as a guide to where you want to be.

You can use this framework to assess your organization's readiness forGoogle Cloud and what you need to do to fill in the gaps and develop newcompetencies, as illustrated in the following diagram.

The framework assesses four themes:

• Learn. The quality and scale of your learning programs.
• Lead. The extent to which your IT departments are supported by amandate from leadership to migrate to Google Cloud.
• Scale. The extent to which you use cloud-optimized services, and howmuch operational automation you have in place.
• Secure. The capability to protect your current environment fromunauthorized and inappropriate access.

For each theme, you should be in one of the following three phases, accordingto the framework:

• Tactical. There are no coherent plans covering all the individualworkloads you have in place. You're mostly interested in a quick return oninvestments and little disruption to your IT organization.
• Strategic. There is a plan in place to develop individual workloadswith an eye to future scaling needs. You're interested in the mid-term goalto streamline operations to be more efficient than they are today.
• Transformational. Cloud operations work smoothly, and you use datathat you gather from those operations to improve your IT business. You'reinterested in the long-term goal of making the IT department one of theengines of innovation in your organization.

When you evaluate the four topics in terms of the three phases, you get theCloud Maturity Scale. In each theme, you can see what happens when you move fromadopting new technologies when needed, to working with them more strategicallyacross the organization—which naturally means deeper, more comprehensive, andmore consistent training for your teams.

The migration path

It's important to remember that a migration is a journey. You are at point Awith your existing infrastructure and environments, and you want to reach pointB. To get from A to B, you can choose any of the options previously described.

The following diagram illustrates the path of this journey.

There are four phases of your migration:

• Assess. In this phase, you perform a thorough assessment anddiscovery of your existing environment in order to understand your app andenvironment inventory, identify app dependencies and requirements, performtotal cost of ownership calculations, and establish app performance benchmarks.For more information about the assess phase, seeMigrate to Google Cloud: Assess and discover your workloads,Migrate to Google Cloud: Best practices,andMigration Center: Start an asset discovery.
• Plan. In this phase, you create the basic cloud infrastructure foryour workloads to live in and plan how you will move apps. This planningincludes identity management, organization and project structure,networking, sorting your apps, and developing a prioritized migration strategy.For more information about planning and building your foundation, seeMigrate to Google Cloud: Plan and build your foundation.
• Deploy. In this phase, you design, implement and execute adeployment process to move workloads to Google Cloud. You might alsohave to refine your cloud infrastructure to deal with new needs. For more informationabout how to deploy your workloads to Google Cloud and how to migrate data to Google Cloud, seeMigrate to Google Cloud: Deploy your workloads,Migrate to Google Cloud: Migrate from manual deployments to automated, containerized deployments,andMigrate to Google Cloud: Transfer your large datasets.
• Optimize. In this phase, you begin to take full advantage ofcloud-optimized technologies and capabilities to expand your business'spotential to things such as performance, scalability, disaster recovery,costs, training, as well as opening the doors to machine learning andartificial intelligence integrations for your app. For more information abouthow to optimize your environment, seeMigrate to Google Cloud: Optimize your environment. For more information about costs, seeMigrate to Google Cloud: Minimize costs.

Finding help

Google Cloud offers various options and resources for you to find thenecessary help and support to best take advantage of Google Cloud services.

Self-service resources

If you don't need dedicated support, you can use these self-serviceresources:

• Product documentation.Google Cloud provides documentation for each of its products andservices, as well as forAPIs.
• Architecture Center documentation.The migration section of the Architecture Center covers many migrationscenarios. For example,Migration resources provides guidance about your migration journey to Google Cloud.
• Tools. Google Cloud provides several products and services to helpyou migrate. For example:
  • Google Cloud Migration Center is a unified platform that helps you accelerate your end-to-end cloudjourney from your current on-premises or cloud environments toGoogle Cloud.
  • Migrate to Virtual Machines is a product for migrating physical servers and virtual machines fromon-premises and cloud environments to Google Cloud.Migrate to VMs lets you migrate a virtual machine toGoogle Cloud in a few minutes, where the data is copied in thebackground but the virtual machines are completely operational.
  • Storage Transfer Service lets you bring data to Cloud Storage from other cloudproviders, online resources, or local data.
  • Database Migration Service is a product that helps you migrate your databases to Google Cloud.
  • Transfer Appliance is a hardware appliance you can use to migrate large volumes of data(from hundreds of terabytes up to 1 petabyte) to Google Cloudwithout disrupting business operations.
  • BigQuery Migration Service is a comprehensive solution for migrating your data warehouse toBigQuery.
• Whitepapers.These papers include reference architectures, case studies, best practices,and advanced tutorials.
• Media content. You can listen to theGoogle Cloud podcast or watch any of the videos on theGoogle Cloud YouTube channel.These resources discuss a wide range of topics from product explanations todevelopment strategies.
• Online courses and labs.Google Cloud has several courses onCoursera that include video content, reading materials, and labs. Youcan also take labs usingGoogle Cloud Skills Boost orparticipate in live online classes.

Technology partners

Google Cloud haspartnered with multiple companies to enable you to use their products. Some of the offerings might be free to useso ask the company and your Google Cloud account manager.

System integrators

Google Cloud partners not just with product and technology companies, butwith system integrators that can provide hands-on-keyboard assistance. Inthe partners list, you can find alist of system integrators that specialize in cloud migrations.

Google Cloud Professional Services

OurProfessional Services team is here to help you get the most out of your investment in Google Cloud.

Cloud Plan and Foundations: get help with your migration

Professional Services can help you plan your migration and deploy your workloadsin production with ourCloud Plan and Foundations offering. These experts provide your team with guidance through each phase ofmigrating your workload into production, from setting up Google Cloudfoundations to optimize the platform for your unique workload needs anddeploying the workload.

The objectives of Cloud Plan and Foundations are:

• Set up the Google Cloud foundation.
• Create design documentation.
• Plan deployment and migration activities.
• Deploy workloads into production.
• Track issues and risks.

Professional Services guides your team through the following activities anddeliverables:

1. Conducting technical kickoff workshops.
2. Building a technical design document.
3. Creating a migration plan.
4. Creating a program charter.
5. Providing project management.
6. Providing technical expertise.

Cloud Sprint: accelerate your migration to Google Cloud

Cloud Sprint is an intensive workshop that accelerates your app migration toGoogle Cloud. In this workshop, Google Cloud Professional Servicesleads one of your teams through interactive discussions, whiteboarding sessions,and reviewing target apps to migrate to Google Cloud. During the CloudSprint, Professional Services works alongside your team members to help you gainfirst-hand experience with cloud solutions with required deployment activitiesto help you understand your next steps for future Google Cloudmigrations.

Training: Develop your team's skills

Google Cloud Professional Services can providetraining in fields based on your team's needs.

What's next

• Learn when tofind help for your migrations.
• For more reference architectures, diagrams, and best practices, explore theCloud Architecture Center.

Contributors

Author:Marco Ferrari | Cloud Solutions Architect