Migrating Workloads to GCP : Part I : Planning Migrations
Migrations are always challenging. I have worked on various migrations — Legacy to Legacy, Legacy to Bigdata and now from past few years, working on migrations to Cloud platform. Based on my past experiences, I am coming up with series of blogs on Migrations. Hope this blog series will help to plan, design, and implement the processes to migrate your applications/workloads to Google cloud.
Let’s get started with first blog in the series and learn more on “Planning migrations” to Google Cloud.
Migrating workloads to GCP can include any of this scenario –
1. On-Premises to GCP
2. Another Cloud to GCP
3. Private Cloud/hosting to GCP
Now, to get started with planning — understand the steps/phases of planning and capture required details/inputs necessary for Migration.
a. Define Environments — Start and End State of Environment
a. In this case, target/end state will be GCP environment.
b. To define, start state — consider evaluating existing application setup, infrastructure, security , Networking , Virtualization of platform if any , any additional resources supporting applications/servers etc.
b. Define Type of Applications/Workloads or Processes –
a. What are the different types of applications run on above infra/env?
b. How many loads run in concurrent?
c. What are the interdependency of these applications amongst each other ?
d. What are the open sources used for application?
e. What is state of applications run on it ? Business critical? Supporting ? in development ?
c. Define Goal –
a. Identify applications to be migrated to Target env i.e. GCP
b. Identify application phases depending on interdependencies between applications
c. Identify Processes , Data Volume, Users, Operations to be migrated to GCP
d. Define business goal and inline with application goals
Once, Start details are gathered and end/target state is defined this helps to define the migration approach and type of migration.
Let’s see what the different types of migrations are –
1. Lift and Shift
2. Improve and Move
3. Remove and Replace
Each of this migration type is defined with a use case as below –
1. Lift and Shift
Move workloads from a source environment to a target environment with minor or no modifications or refactoring. The modifications applied to the workloads to migrate are only the minimum changes that need to be made for the workloads to operate in the target environment. These are 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.
Lift and Shift migration is also chosen in case of technical challenges. 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 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 migrating existing workloads with minimal refactoring, lift and shift migrations tend to be the quickest, compared to improve and move or remove and replace migrations.
Only cons of lift and shift is : Post migration non-cloud-native workloads running in the target environment. These workloads don’t take full advantage of cloud platform features, such as scalability, Pricing, and managed services.
1. Improve and Move
In an improve and move migration, modernize the workload while migrating it. In this type of migration, modified workloads to take advantage of cloud-native capabilities, and not just to make them work in the new environment but also 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 that need to make to migrate.
Improve and move migrations allows applications leverage features of a cloud platform, such as scalability and high availability. These can also be architected considering the improvement to increase the portability of the app.
Cons of improve and move migrations: These migrations take longer than lift and shift migrations, because they must be refactored in order for the app to migrate. These need to be evaluated causing the extra time and effort as part of the life cycle of the app. Also , requires that you learn new skills.
2. Remove and replace
In a remove and replace migration, we decommission an existing app and completely redesign and rewrite it as a cloud-native app. If the current app isn’t meeting goals — for example, we 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 — we can do a remove and replace migration.
Remove and replace migrations let app take full advantage of Google Cloud features, such as horizontal scalability, highly managed services, and high availability. Because of rewriting the app from scratch, it also remove the technical debt of the existing, legacy version.
Cons of remove and replace migrations : They 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. This need to evaluate the extra time and effort to redesign and rewrite the app as part of its lifecycle.
Now, we know the 3 types of migrations. Based on the start state and end state captured in planning phase we can estimate the probable path and time of migration considering the business goal of migration.
Google provides its adoption framework which can help to assess readiness for Google cloud and what is required to fill in the gaps to develop new competencies.
The framework assesses four themes:
Learn. The quality and scale of our learning programs.
Lead. The extent to which our IT departments are supported by a mandate from leadership to migrate to Google Cloud.
Scale. The extent to which we use cloud-native services, and how much operational automation we currently have in place.
Secure. The capability to protect our current environment from unauthorized and inappropriate access.
For each theme, there is one of the following three phases, according to the framework:
Tactical. There are no coherent plans covering all the individual workloads that have in place. We are mostly interested in a quick return on investments and little disruption to IT organization.
Strategic. There is a plan in place to develop individual workloads with an eye to future scaling needs. We are interested in the mid-term goal to streamline operations to be more efficient than they are today.
Transformational. Cloud operations work smoothly, and we use data that we gather from those operations to improve our IT business. We are interested in the long-term goal of making the IT department one of the engines of innovation in our organization.
When we evaluate the four topics in terms of the three phases, we get the Cloud Maturity Scale. In each theme, we can see what happens when we 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 teams.
By now, we have captured enough pointers to list down which will help us in migration journey. This isn’t is the only required path/part of migration journey. This is just beginning! Once we capture initial state, target state, type of migration, probable estimate aligned with business goals, evaluate against the maturity scale the next step is to get started with migration journey.
Let’s look at the migration path and phases of migration in next blog.
About Me :
I am DWBI and Cloud Architect! I have been working with various Legacy data warehouses, Bigdata Implementations, Cloud platforms/Migrations. I am Google Certified Professional Cloud Architect .You can reach out to me @ LinkedIn if you need any further help on certification, GCP Implementations!