Migrate to Google Cloud: Get started

Last reviewed 2024-11-20 UTC

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:

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, 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 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. 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 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.

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.

There are four phases of your migration:

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. Google Cloud provides documentation for each of its products and services, as well as for APIs.
  • Architecture Center documentation. The migration section of the Architecture Center covers many migration scenarios. For example, Migration resources 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 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 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 lets you bring data to Cloud Storage from other cloud providers, 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 Cloud without disrupting business operations.
    • BigQuery Migration Service is a comprehensive solution for migrating your data warehouse to BigQuery.
  • Whitepapers. These papers include reference architectures, case studies, best practices, and advanced tutorials.
  • Media content. You can listen to the Google Cloud podcast or watch any of the videos on the Google Cloud YouTube channel. These resources discuss a wide range of topics from product explanations to development strategies.
  • Online courses and labs. Google Cloud has several courses on Coursera that include video content, reading materials, and labs. You can also take labs using Google Cloud Skills Boost or participate in live online classes.

Technology partners

Google Cloud has partnered with multiple companies 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.

Google Cloud Professional Services

Our Professional 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 workloads in production with our Cloud Plan and Foundations 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 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 based on your team's needs.

What's next

Contributors

Author: Marco Ferrari | Cloud Solutions Architect