Four Facets of Cloud Migration

Demystifying the haziness around migration to cloud and associated complexity by elucidating elementary questions.

Elementary Questions: Four Facets of Cloud Migration Roadmap

Why Cloud?

As any strategic move begins with “Purpose”, same is true with your cloud journey as well.

The most fundamental element would be to know objective behind moving to cloud. This could be a business driven transformation wherein the company wants to move towards new business model e.g. to offer subscription based model, extending the geography reach or to bring agility and faster time to market or technology driven e.g where organization decides to move out of a datacenter or retire End of Life /End of Support infrastructure, OS, application or databases.

As we understand the motive for moving to cloud and constraints if any, you could structure the priorities and define a decision tree. As an example, when you see priority for your organization is to exit out of datacenter, you would choose lift n shift migration approach against modernization or native build.

A decision tree driven by the purpose helps to define qualifying criteria and define migration paths looking at multiple business, technology and economic factors.

What is there to move to cloud?

It is fundamental to understand what is there in my IT landscape as Infrastructure and applications which you want to move to cloud. Understanding CMDB and application portfolio along with its relationship forms the foundation for cloud roadmap. You can formally call them as Infrastructure Discovery and Application Portfolio Assessment respectively.

Infrastructure Discovery about knowing quantitative aspects like Server inventory, IP address, Hostname, OS, CPU, RAM, storage, IOPS, performance utilization in terms of average, max, utilization and last but not the least knowing Inter dependencies with other servers and applications along with port, protocol . There are multiple discovery tools which could provide this data.

Application assessment is bit fuzzier as it is about knowing qualitative aspects like usage, security requirement, performance, criticality and many more. The usual approach to gather this information is via workshop or questionnaire. It is critical to optimize the questionnaire and have the right set of questions which can lead to our goal with minimum effort.

Understanding Infrastructure and application estate and existing landscape is the answer to “What do we have”

How should it be migrated?

As we understand purpose of migration (Why) and available landscape (What), next focus is to look at more details and individual application to evaluate the best way to migrate each application. In Cloud terminology, it is termed as R path, as such if we merge R definitions across organizations, there are numerous variations of R path, however to stay neutral, we would stick to Gartner R path definitions.

Rehost – Lift n Shift – which is modeled on Infrastructure as a Service

Refactor – Minimal changes to adopt to cloud platform- Modeled on Platform as a Service

Revise – Major changes to application code and configuration to make it cloud ready

Rebuild – Build the application from scratch usually using cloud native way using microservices, containerization or server less architecture

Replace – Replace the application by software delivered as a Service

As we move from top to bottom, cloud benefit increases and at the same time migration effort also. Hence it is important to identify the optimal migration R path for each application based on business, technical and economic parameters.

When to move to cloud?

By now we understand the purpose(why), landscape(what), and migration path (How) to move to cloud. The next and final step would be to visualize the roadmap.

To build roadmap, there are three critical components which we must know.

1. What is the effort expected for each application: Based on the migration path (rehost/Refactor..) and complexity, we can derive migration effort. Now you may ask how would we know Complexity? Well, complexity parameters would vary depending on Rpath. To give an example, if we are migrating the application as ‘Rehost’ , number of servers, interdependencies, OS are some of the critical parameters. If we migrate as an application as ‘Refactor’, application functionality and code complexity of more importance to derive migration complexity. Migration Complexity identification could be another topic in itself and I plan to cover in the next blog.
2. What would the time required to migrate the application: Now it may sound like time is directly proportional to effort and no brainer. Well, Yes and no. While effort is one of the key factors to drive timeline, there are many other parameters which would influence the timeline in real world. Those could be Organization Processes to go through change control board, various quality gates, various function and non-functional as well as security test requirement and business availability for acceptance test and finally all stakeholder alignment for go live!
3. What should be the sequence of migration: After having effort and timeline for individual application, next question to address would be which applications need to go first and which ones to take next and so on. While migration roadmap is derived based on multiple factors, like, business priority, complexity, stakeholder’s availability and many more, most important one of to know Interdependencies among applications. We typically try n balance these multiple factors to optimize the risk- benefit ratio while grouping and sequencing the application in so called- Migration Wave Plan.

While I will soon be back with more detailed approach for each of these elementary questions in the next series of articles, I would like to leave you with the idea that Cloud migration roadmap could be crafted by addressing the most elementary questions around why-What-When-How.