Why Cloud Migration Project tend to time delays?

In the context of modernization, organizations are on cloud migration path since last few years. Cloud Migration is a project where organization want to move away from traditional on premise systems to cloud service providers such as Amazon, Azure, Google cloud etc. I have personally worked on two such big ticket projects. One use case was for Big Data on premise application and another one was of Teradata to cloud migration. Cloud migration projects are relatively strategic and complex projects. They tend to time delays, cost overruns and most of the time not meeting the business needs.

We generally apply traditional project management approach in Cloud Migration projects. Traditional project management approach focus on time and budget of the project. Cloud migration being strategic project calls for a different type of management. Such project must be tracked based on outcome not on output.

I have put a diamond cross model to study the project management style of migration projects. Lets me quickly try to explain this. Diamond cross model works based on Novelty, Complexity, Technology and Pace. Novelty represent how new is the product to market. Technology represent extent of new technology used. Complexity represent the level of system innovation. Pace represent commitment to finish project in stipulated time.

From users perspective, migration projects are "platform". Platform means a new generation of existing product line. Technology wise "medium tech" - some new technology used. Complexity wise "system" - collection of sub systems. Pace wise "Time Critical". As most of the project are constrained by time and budgets. If we represent this on axis it forms diamond. The inner diamond represent the perception. In reality the truth on ground is different.

The outer dotted and green line represent the required parameters for a cloud migration project. Let me explain you in brief. Novelty - thought perceived as platform the migration projects are always new to market. As there is no hand book to migration, reimagining the system on cloud would require pilot testing and iterative model modification until final version is established. Technology wise even though the perception is medium tech but there are many services from cloud which are new in stack. The innovation is relatively quick on cloud service providers. The cloud services tend to change their implementation in relatively less time. There is also chance the service used might no longer exist. One such example is we started cloud migration and completed in Databricks cloud and later found that relatively untested but less cost service of Amazon was available.

Complexity even though perceived as combination of subsystem the final architecture of cloud system is a array means a widely spread collection of systems with common mission. Just to give example we might end up using AWS for most of services but use an on premise airflow for orchestration or Databricks for big data processing. The the final system is spread across multiple systems with common goal.

To begin with, the perception itself goes wrong on the project. It tends to have a domino effect on the project lifecycle. Some of our learning is correction of perception to begin with. The cloud migration are not just any other project they are strategic projects. When we start designing we must define a high level design for all the project components. Separate out the key subsystems with risk and design the pilot implementation and testing cycles for them. Once the project is started define the critical paths and focus on them to ensure their completion. There is huge scope of innovation but we also have to limit ourselves as per the timelines. It is important to note what not to do.

Teams involved must be highly motivated and be on mission mode. Quality of each of the delivery is critical and must be micromanaged. Instead of having just a final integration test we must have additional smaller sub system integrations done after each interval. This helps us validate issues at the early phase of project. We must always remember we have to build a better system so all the boundaries must be crossed and no stone left unturned for quality delivery.

Keep the stake holder involved and time frame should not be a problem. Above are some of my two cents for any one attempting strategic cloud migration projects in their organizations. If we could keep in mind some of the learning we we will have a final laugh.

Happy learning and Sharing!!