Migrate to Google Cloud: Get started

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 a multi-part series about migrating to Google Cloud. If you're interested in an overview of the series, see Migrate to Google Cloud: Choosing your migration path.

This article is part of a series:

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

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-native 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-native workloads and operations.
  • Public cloud or private hosting environment with legacy workloads and operations.
  • Public cloud or private hosting environment with cloud-native 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-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.

Types of migrations

There are three major types of migrations:

  • Lift and shift
  • Improve and move
  • Remove and replace (sometimes called rip and replace)

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

Lift and shift

In a lift and shift 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 lift and shift 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 lift and shift migration. If you cannot refactor a workload to migrate and cannot decommission the workload, you must use a lift and shift 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.

Lift and shift 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 off-the-shelf software. Because you migrate existing workloads with minimal refactoring, lift and shift migrations tend to be the quickest, compared to improve and move or remove and replace migrations.

On the other hand, the results of a lift and shift migration are non-cloud-native workloads running in the target environment. These workloads don't take full advantage of cloud platform features, such as horizontal scalability, fine-grained pricing, and highly managed services.

Improve and move

In an improve and move migration, you modernize the workload while migrating it. In this type of migration, you modify the workloads to take advantage of cloud-native capabilities, and not just to make them work in the new environment. You can improve each workload for performance, features, cost, or user experience.

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 improve and move approach is when a major update to the workload is necessary in addition to the updates you need to make to migrate.

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

On the other hand, improve and move migrations take longer than lift and shift migrations, because they must be refactored in order for the app to migrate. You need to evaluate the extra time and effort as part of the life cycle of the app.

An improve and move migration also requires that you learn new skills.

Remove and replace

In a remove and replace migration, you decommission an existing app and completely redesign and rewrite it as a cloud-native 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 remove and replace migration.

Remove and replace 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, remove and replace migrations can take longer than lift and shift or improve and move migrations. Moreover, this type of migration isn't suitable for off-the-shelf 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 remove and replace 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.

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-native services, and how much operational automation you currently 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 leverage Google Cloud services.

Self-service resources

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

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.

These products include the following:

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 hands-on 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