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:
- Migrate to Google Cloud: Getting started (this document)
- Migrate to Google Cloud: Assess and discover your workloads
- Migrate to Google Cloud: Choose an assessment tool
- Migrate to Google Cloud: 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
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.
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.
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, Migrate to Google Cloud: Choose an assessment tool, and Migrate to Google Cloud: Best practices for validating a migration plan.
- 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: Build 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, Migrate to Google Cloud: Migrate from manual deployments to automated, containerized deployments, and Migrate to Google Cloud: Transfer your large datasets.
- Optimize. In this phase, you 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. For more information about how to optimize your environment, see Migrate to Google Cloud: Optimize your environment.
Google Cloud offers various options and resources for you to find the necessary help and support to best leverage Google Cloud services.
If you don't need dedicated support, you can use these self-service resources:
- Documentation. Google Cloud provides documentation for each of its products and services, as well as for APIs. For more information about migrations, check out the Google Cloud migration center.
- Tools. Google Cloud provides several products and services to help
you migrate. For example:
- 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.
- Online transfer to Cloud Storage by using the gsutil command-line tool, Cloud Storage JSON API or the Google Cloud console.
- Storage Transfer Service lets you bring data to Cloud Storage from other cloud providers, online resources, or local data.
- 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 hands-on labs. Google Cloud has several courses on Coursera that include video content, reading materials, and hands-on labs. You can also take hands-on labs using Google Cloud Skills Boost or participate in live online classes.
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:
- Assessment and discovery phase: StratoZone, CloudPhysics, Risc Networks, and Cloudamize
- Provisioning and configuration phases: Terraform, Chef, Ansible, SaltStack, and Puppet
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:
- Conducting technical kickoff workshops.
- Building a technical design document.
- Creating a migration plan.
- Creating a program charter.
- Providing project management.
- 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.
- Start your migration to Google Cloud by assessing and discovering your environment.
- Explore reference architectures, diagrams, and best practices about Google Cloud. Take a look at our Cloud Architecture Center.