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 ,you outsource part of the physical infrastructure and its management to an external party.
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.
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. We consider 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.
Types of migrations
There are three major types of migrations:
- Lift and shift
- Improve and move
- Rip and replace
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.
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.
Rip and replace
In a rip and replace migration, you decommission an existing app and completely redesign and rewrite it as a cloud-native app.
Rip and replace migrations let your app take full advantage of Google Cloud features, such as horizontal scalability, highly managed services, and high availability.
However, rip 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.
The migration path
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.
- 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.
- 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.
- 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.
Migration phase 1: assess
In the assessment phase, you gather information about the workloads you want to migrate and their current runtime environment.
- Take inventory
- Catalog apps
- Educate your organization about Google Cloud
- Experiment and design proofs of concept
- Calculate total cost of ownership
- Choose which workloads to migrate first
Migration phase 2: plan
In this phase, you provision and configure the cloud infrastructure and services that will support your workloads on Google Cloud. Building a foundation of critical configurations and services is an evolving process. When you establish your rules, governance, and settings, make sure you allow room for changes later.
To plan for your migration, you need to do the following:
- Establish user and service identities.
- Design your resource organization.
- Define groups and roles for resource access.
- Design your network topology and establish connectivity.
Migration phase 3: deploy
After building a foundation for your Google Cloud environment, you can begin to deploy your workloads. You can implement a deployment process and refine it during the migration. You might need to revisit the foundation of your environment as you progress with the migration.
When designing the deployment process for your workloads, you should take into account how much automation and flexibility you need. There are multiple deployment process types for you to choose, ranging from a fully manual process to a streamlined, fully automated one.
Migration phase 4: Optimize
In the optimization phase, you refine your environment to make it more efficient than your initial deployment.
Optimization is an ongoing and continuous task. You constantly optimize your environment as it evolves. To avoid uncontrolled and duplicative efforts, you can set measurable optimization goals and stop when you meet these goals. After that, you can always set new and more ambitious goals, but consider that optimization has a cost, in terms of resources, time, effort, and skills.
The following diagram shows the optimization loop.