In several articles, we’ve been talking about the advantages of the cloud and the reasons why we should move our infrastructure to it or migrate from one service to another in the cloud. Today we’ll focus primarily on how to take that first step, so as to have a better idea of how to plan a migration. Generally, migration projects are lengthy and complex, and many things can go wrong. Expectations are high and there’s pressure from different areas to have a good result.
The Moment of Transitioning
Before we start, we should say that the most common goal for any migration project is to reduce application costs. In an ideal world, we’d have two infrastructures coexisting for some time, a short time. But, generally, this is not the case, since we have to make sure some services are working until we can safely say we don’t need the “old” infrastructure anymore. Many times, when we plan how much we’ll reduce costs, we take the current cost and make a projection, but we don’t take into account the period of time in which several services will be working at the same time or will be idly. This is important, since people could get nervous when the figures on the invoices start going up. In order to cover this expense, we should always be transparent and think about the long-term benefits.
Time to Plan
There are two possible starting points when we decide to migrate our apps:
- We have experience and vast knowledge of the matter.
- We have enough knowledge, but we also have serious doubts.
Knowing where we stand allows us understand our challenges in more detail. And this is all very important when we have to start planning.
With our experience and technical knowledge, we need to detect which services we need to migrate. A common practice is to divide each service or app in different stages, starting with the less risky ones or the ones that will have a lower impact on the structure of the company. This methodology allows us to understand possible complications or deviations, so much so that we can refine the process for those services which present higher complexity and risk. It also allows us to show stakeholders why the project is important, since it offers us quick visibility and the possibility to be confident that our goals will be achieved in the near future.
So, when the time comes to create a migration plan, a calendar and a risk mitigation plan, we feel as if we were creating something nice, like the famous sourdough in times of lockdown. But, what’s next?
Classifying the Migration Project
Defining what type of migration we’re going to carry out goes hand in hand with the objectives and goals to be attained. When we know what type of migration we’ll do, we understand the risks and advantages we’ll encounter during the process. When we start our migration project, we can either classify it as:
- Lift and shift
In this case, we move our apps from the starting point to the final destination without modifying anything, just making the necessary adjustments so that they work properly. There is lower risk compared with the other categories, but it doesn’t enhance our apps with cloud characteristics. It generally doesn’t have an impact on costs, since we mainly focus on equivalences between the new and the old infrastructures (hence, it simplifies cost calculations). However, we do need to know about the equivalent services, although we don’t need to be experts on the cloud.
- Improve and move
This category focuses on two main goals: knowing the product and understanding how the cloud can improve it natively. In this case, we need to know how to manage cloud services better. The architecture team and cloud specialists need to work hand in hand to leverage the opportunities. These projects take more time and costs are higher, but in the long run, performance results and savings are much more meaningful than in the case of “lift and shift”.
- Extract and replace
Unlike the other two categories in which we move our apps to the cloud, this type of migration requires the development and infrastructure teams to create the solution again, but natively. This type of project allows us to update the infrastructure, but also the technologies our apps are using. Because the product is typed again, its schedule is longer and more complex. If the app is complex as well, the process is particularly complicated. The projects that focus on extracting and replacing have considerable long-term benefits, since we can innovate and rethink the processes. They offer us many possibilities for the future.
All Set to Plan
Planning, i.e. arranging a schedule, deciding on the type of migration and detecting risks, allows us to manage our time better. The key to a successful migration is to understand its complexity, but also to embrace its benefits. At intive, we help our clients transform their business through design and the development of people-centered digital products.
What do you think? What could we improve in terms of planning? Is there any other principle you believe is important?