[Video](https://www.youtube.com/watch?v=6BSjMpO4rGU)

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

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

- Migrate to Google Cloud: Get started (this document)
- [Migrate to Google Cloud: Assess and discover your workloads](https://docs.cloud.google.com/architecture/migration-to-gcp-assessing-and-discovering-your-workloads)
- [Migrate to Google Cloud: Plan and build your foundation](https://docs.cloud.google.com/architecture/migration-to-google-cloud-building-your-foundation)
- [Migrate to Google Cloud: Transfer your large datasets](https://docs.cloud.google.com/architecture/migration-to-google-cloud-transferring-your-large-datasets)
- [Migrate to Google Cloud: Deploy your workloads](https://docs.cloud.google.com/architecture/migration-to-gcp-deploying-your-workloads)
- [Migrate to Google Cloud: Migrate from manual deployments to automated, containerized deployments](https://docs.cloud.google.com/architecture/migration-to-google-cloud-automated-containerized-deployments)
- [Migrate to Google Cloud: Optimize your environment](https://docs.cloud.google.com/architecture/migration-to-google-cloud-optimizing-your-environment)
- [Migrate to Google Cloud: Best practices for validating a migration plan](https://docs.cloud.google.com/architecture/migration-to-google-cloud-best-practices)
- [Migrate to Google Cloud: Minimize costs](https://docs.cloud.google.com/architecture/migration-to-google-cloud-minimize-costs)

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

## Beginning the journey

When planning your migration to Google Cloud, you start by defining the
environments that are involved in the migration. Your starting point can be
an on-premises environment, a private hosting environment, or another
public cloud environment.

An on-premises environment is an environment where you have full ownership and
responsibility. 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 a
[colocation facility](https://en.wikipedia.org/wiki/Colocation_centre),
you outsource part of the physical infrastructure and its management to an
external party. This infrastructure is typically shared between customers. In a
private hosting environment, you don't have to manage the physical security and
safety services. Some hosting environments let you manage part of the physical
hardware, such as servers, racks, and network devices, while others
manage that hardware for you. Typically, power and network cabling are
provided as a service so you don't have to manage them. You maintain full
control over hypervisors that virtualize physical resources, the virtualized
infrastructure that you provision, and workloads that you run on that
infrastructure.

A
[public cloud environment](https://en.wikipedia.org/wiki/Cloud_computing#Public_cloud)
has the advantage that you don't have to manage the whole resource stack by
yourself. 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 underlying
physical infrastructure. Additionally, you don't have to manage the resource
virtualization hypervisor. You can build a virtualized infrastructure and can
deploy your workloads in this new infrastructure. You can also buy fully managed
services, where you care only about your workloads, handing off the
operational burden of managing runtime environments.

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

| Resources | On-premises environment | Private hosting environment | Public cloud environment |
| Physical security and safety | You | Service provider | Service provider |
| Power and network cabling | You | Service provider | Service provider |
| Hardware (incl. maintenance) | You | Depends on service provider | Service provider |
| Virtualization platform | You | You | Service provider |
| App resources | You | You | You (eventually leveraging fully managed services) |
|---|---|---|---|

In this document, the target environment is
Google Cloud.

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

Legacy workloads and operations are developed without any
consideration for cloud environments. These workloads and operations can be
difficult to modify and expensive to run and maintain because they usually don't
support any type of scalability.

Cloud-optimized workloads and operations are
natively scalable, portable, available, and secure. The workloads and operations
can help increase developer productivity and agility, because developers can
focus on the actual workloads, rather than spending effort to manage development
and runtime environments, or dealing with manual and cumbersome deployment
processes. Google Cloud also has a
[shared responsibility model for security](https://cloud.google.com/security/overview/). Google Cloud is
responsible for the physical security and the security
of the infrastructure, while you're responsible for the security of the
workloads you deploy to the infrastructure.

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

- On-premises or private hosting environment with legacy workloads and operations.
- On-premises or private hosting environment with cloud-optimized workloads and operations.
- Public cloud or private hosting environment with legacy workloads and operations.
- Public cloud or private hosting environment with cloud-optimized workloads and operations.

The migration process depends on your starting point.

Migrating a workload from a legacy on-premises environment or private hosting
environment to a cloud-optimized 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.

## 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 called *rip and replace*
- Repurchase

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

### Rehost: lift and shift

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

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

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

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

However, after a rehost migration, the workloads that are running in the target
environment aren't optimized for the cloud. These workloads don't
take 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 optimize
them for the new cloud environment.

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

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

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

### Refactor: move and improve

In a refactor migration, you modify the workloads to take advantage of
cloud capabilities, and not just modify the workloads to make them work in the new
environment. You can improve each workload for performance, features, cost, and
user experience.

You can modify the workloads while you're migrating them to the cloud, or even
before migrating them. For example, if you don't have substantial experience with
cloud migrations, you might prefer to modify the workloads while you're
migrating. However, if you have cloud migration experience, you may
already have an idea of the modifications that the workloads need to take
full advantage of cloud capabilities.

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

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

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

However, refactor migrations take longer than rehost
migrations because the workloads must be refactored in order for the app to
migrate.

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 of
restructuring how the workload code works, re-architect migrations change
how that code functions. Those code changes optimize the workload and take
advantage 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 you
deploy on Google Cloud.

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

### Rebuild: remove and replace

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

If the current app isn't meeting your goals---for example, you don't want
to maintain it, it's too costly to migrate using one of the previously mentioned
approaches, or it's not supported on Google Cloud---you can do a
rebuild migration.

Rebuild migrations let your app take full advantage of
Google Cloud features, such as horizontal scalability, highly managed
services, 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 or
refactor migrations. Moreover, this type of migration isn't suitable for
ready-made apps because it requires rewriting the app. You need to evaluate
the extra time and effort to redesign and rewrite the app as part of its
lifecycle.

A rebuild migration also requires new skills. You need to use new
toolchains to provision and configure the new environment and to deploy the app
in that environment.

### Repurchase

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

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

## Google Cloud Adoption Framework

Before starting your migration, you should evaluate the maturity of your
organization in adopting cloud technologies. The
[Google Cloud Adoption Framework](https://cloud.google.com/adoption-framework)
serves both as a map for determining where your business information technology
capabilities are now, and as a guide to where you want to be.

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

![Architecture of Google Cloud Adoption Framework with four themes and three phases.](https://docs.cloud.google.com/static/architecture/images/migration-to-gcp-getting-started-1-gcp-adoption-framework.svg)

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 a mandate from leadership to migrate to Google Cloud.
- **Scale.** The extent to which you use cloud-optimized services, and how much operational automation you have in place.
- **Secure.** The capability to protect your current environment from unauthorized and inappropriate access.

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

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

When you evaluate the four topics in terms of the three phases, you get the
Cloud Maturity Scale. In each theme, you can see what happens when you move from
adopting new technologies when needed, to working with them more strategically
across the organization---which naturally means deeper, more comprehensive, and
more consistent training for your teams.

## The migration path

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

The following diagram illustrates the path of this journey.

![Migration path with four phases.](https://docs.cloud.google.com/static/architecture/images/migration-to-gcp-getting-started-migration-path.svg)

There are four phases of your migration:

- **Assess.** In this phase, you 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. For more information about the assess phase, see [Migrate to Google Cloud: Assess and discover your workloads](https://docs.cloud.google.com/architecture/migration-to-gcp-assessing-and-discovering-your-workloads), [Migrate to Google Cloud: Best practices](https://docs.cloud.google.com/architecture/migration-to-google-cloud-best-practices), and [Migration Center: Start an asset discovery](https://docs.cloud.google.com/migration-center/docs/start-asset-discovery).
- **Plan.** In this phase, you 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. For more information about planning and building your foundation, see [Migrate to Google Cloud: Plan and build your foundation](https://docs.cloud.google.com/architecture/migration-to-google-cloud-building-your-foundation).
- **Deploy.** In this phase, you 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. For more information about how to deploy your workloads to Google Cloud and how to migrate data to Google Cloud, see [Migrate to Google Cloud: Deploy your workloads](https://docs.cloud.google.com/architecture/migration-to-gcp-deploying-your-workloads), [Migrate to Google Cloud: Migrate from manual deployments to automated, containerized deployments](https://docs.cloud.google.com/architecture/migration-to-google-cloud-automated-containerized-deployments), and [Migrate to Google Cloud: Transfer your large datasets](https://docs.cloud.google.com/architecture/migration-to-google-cloud-transferring-your-large-datasets).
- **Optimize.** In this phase, you begin to take full advantage of cloud-optimized 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. For more information about how to optimize your environment, see [Migrate to Google Cloud: Optimize your environment](https://docs.cloud.google.com/architecture/migration-to-google-cloud-optimizing-your-environment). For more information about costs, see [Migrate to Google Cloud: Minimize costs](https://docs.cloud.google.com/architecture/migration-to-google-cloud-minimize-costs).

## Finding help

Google Cloud offers various options and resources for you to find the
necessary 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-service
resources:

- [Product documentation](https://docs.cloud.google.com/docs). Google Cloud provides documentation for each of its products and services, as well as for [APIs](https://docs.cloud.google.com/apis).
- [Architecture Center documentation](https://docs.cloud.google.com/architecture/migrations). The migration section of the Architecture Center covers many migration scenarios. For example, [Migration resources](https://docs.cloud.google.com/architecture/migrations) provides guidance about your migration journey to Google Cloud.
- Tools. Google Cloud provides several products and services to help you migrate. For example:
  - [Google Cloud Migration Center](https://docs.cloud.google.com/migration-center) is a unified platform that helps you accelerate your end-to-end cloud journey from your current on-premises or cloud environments to Google Cloud.
  - [Migrate to Virtual Machines](https://docs.cloud.google.com/migrate/virtual-machines/docs/5.0) is a product for migrating physical servers and virtual machines from on-premises and cloud environments to Google Cloud. Migrate to VMs lets you migrate a virtual machine to Google Cloud in a few minutes, where the data is copied in the background but the virtual machines are completely operational.
  - [Storage Transfer Service](https://docs.cloud.google.com/storage-transfer) lets you bring data to Cloud Storage from other cloud providers, online resources, or local data.
  - [Database Migration Service](https://docs.cloud.google.com/database-migration) is a product that helps you migrate your databases to Google Cloud.
  - [Transfer Appliance](https://docs.cloud.google.com/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 Cloud without disrupting business operations.
  - [BigQuery Migration Service](https://docs.cloud.google.com/bigquery/docs/migration-intro) is a comprehensive solution for migrating your data warehouse to BigQuery.
- [Whitepapers](https://cloud.google.com/whitepapers). These papers include reference architectures, case studies, best practices, and advanced tutorials.
- Media content. You can watch any of the videos on the [Google Cloud YouTube channel](https://www.youtube.com/googlecloudplatform). These resources discuss a wide range of topics from product explanations to development strategies.
- [Online courses and labs](https://cloud.google.com/training/). Google Cloud has several courses on [Coursera](https://www.coursera.org/) that include video content, reading materials, and labs. You can also take labs using [Google Cloud Skills Boost](https://www.cloudskillsboost.google/) or [participate in live online classes](https://cloud.google.com/training/courses).

### Technology partners

Google Cloud has
[partnered with multiple companies](https://cloud.google.com/find-a-partner)
to enable you to use their products. Some of the offerings might be free to use
so ask the company and your Google Cloud account manager.

### System integrators

Google Cloud partners not just with product and technology companies, but
with system integrators that can provide hands-on-keyboard assistance. In
the partners list, you can find a
[list of system integrators that specialize in cloud migrations](https://cloud.google.com/find-a-partner/).

### Google Cloud Professional Services

Our
[Professional Services team](https://cloud.google.com/consulting)
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 workloads
in production with our
[Cloud Plan and Foundations](https://services.google.com/fh/files/misc/cloud_plan_infrastructure.pdf)
offering. These experts provide your team with guidance through each phase of
migrating your workload into production, from setting up Google Cloud
foundations to optimize the platform for your unique workload needs and
deploying 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 and
deliverables:

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](https://services.google.com/fh/files/misc/cloud_sprint.pdf)
is an intensive workshop that accelerates your app migration to
Google Cloud. In this workshop, Google Cloud Professional Services
leads one of your teams through interactive discussions, whiteboarding sessions,
and reviewing target apps to migrate to Google Cloud. During the Cloud
Sprint, Professional Services works alongside your team members to help you gain
first-hand experience with cloud solutions with required deployment activities
to help you understand your next steps for future Google Cloud
migrations.

#### Training: Develop your team's skills

Google Cloud Professional Services can provide
[training in fields](https://cloud.google.com/training/)
based on your team's needs.

## What's next

- Learn where to [find help for your migrations](https://docs.cloud.google.com/architecture/migration-to-gcp-getting-started#finding_help).
- Take the [Google Skills training course on migrating to Google Cloud](https://www.skills.google/course_templates/1561).
- For more reference architectures, diagrams, and best practices, explore the [Cloud Architecture Center](https://docs.cloud.google.com/architecture).

## Contributors

Author: [Marco Ferrari](https://www.linkedin.com/in/ferrarimark) \| Cloud Solutions Architect