Cloud Essentials+ Journey – Cloud Migration Phases

Writing from experience, without knowing much about it, “moving to the cloud” can be a nebulous concept. It seems easy to just think that, “hey, we have applications hosted in our data center today, then tomorrow they will be in the cloud.” However, a cloud migration is much more than that. A fair amount of work needs to go into the strategy and planning of a cloud migration, and not all of that is technical. The goals and desires of the business need to be taken into account early to make sure that moving to the cloud is the right business choice. A cloud migration should have multiple phases, with the early phases focusing much on discovery and analysis with a goal of determining whether or not certain applications and services should be migrated into the cloud and if a cloud migration aligns with business goals and requirements. A cloud assessment addresses these early phases. At a high level, these cloud migration phases can include the following.

• Resource Discovery
  • Before applications and services can be moved to the cloud, we need to know what we are running and supporting currently. I think of this as the inventory phase. This is where we do a lot of information gathering to see what we have today.
• Applicability of Existing Resources in the Cloud
  • Once we have our application and service inventory, we can begin the analysis to see which applications, if any, make sense to be cloud deployed. Not all applications make sense to be cloud delivered. As a recommendation, it may be good to avoid migrating the following types of applications to the cloud. The reason being is that these types of applications may not fit cloud structures well.
    • Legacy/”old” applications.
    • Applications that have been heavily modified/changed/customized.
    • In-house developed (“home-grown”) applications.
• Aligning Existing Services to Available Cloud Solutions
  • When applications and services are deemed suitable to be cloud deployed, we now need to see what cloud options are available that well fit our existing needs. Some applications may just be a lift and shift migration from on-premises into the cloud, while in other cases, a rip and replace or repurchase migration might make more sense. For instance, an on-prem application might satisfy a business need today, but it may make more sense to purchase a new cloud solution to meet the need instead of trying to migrate the existing application to the cloud.
• Application/Service Migration to the Cloud
  • This can be thought of as the actual deployment phase. There are seven main types of cloud migrations that I will plan to dig into in another post in this series:
    • Rehost (lift and shift)
    • Replatform (lift, tinker, and shift)
    • Refactor (rip and replace)
    • Repurchase (drop and shop)
    • Retire
    • Retain
    • Hybrid
• Ongoing Support and Day-to-Day Operations
  • In my opinion, day-to-day operations really should be seen as a migration phase for the main reason of remembering that it exists. Once an application has been migrated to the cloud, that does not mean the work is done. Just like on-premises applications, there is still maintenance and support in one form or another that exists in the cloud.

As you can see from the list above there is a fair amount of time and effort that goes into a cloud migration, a lot of which that happens well before the actual migration. Another important thing to remember when thinking through a potential cloud migration is the objectives of the business. Something that should be done early on is a feasibility study that not only looks at the technical side with checking the feasibility of applications to be cloud-delivered, but also the business side. For example, does is make sense for the organization to shift from primarily capital expenditures to primarily operating expenditures? As eluded to in the beginning, there is much more to a cloud migration than just flipping a switch.