Co-authored by Marcel de Vries and Martijn van der Sijde

It is no longer a question of whether or not your organization will move its applications to the cloud; it’s a matter of when and how. This article discusses the various cloud-migration strategies you should consider and explains how to determine the right one for your company.

Do you have a business case for migrating to the cloud?

When we talk to organizations about cloud transitions, we hear about many different approaches. But which one they choose and the steps they take depends primarily on who leads the migration. Your development team will offer different solutions from your operations team.

For example, from a developer’s perspective, a great migration plan involves changing the application’s architecture to microservices and using the latest .NET Core framework, since it’s been optimized for cloud workloads. This approach requires a very high investment before a move can begin because the fundamental differences in the architecture require rewriting the application.

The IT operations department’s perspective might involve provisioning infrastructure in a new way, and then to set up a service catalog to allow customers to request new virtual machines (that are now) provisioned in the cloud. Since this approach involves implementing the current systems using cloud infrastructure, it will also create extensive network architectures and a lot of complexity.

These are two examples of many other perspectives. Are they wrong? No, but we think they are suboptimal because they'll incur a high cost/low return on investment.

Instead, for a balanced and correct perspective, ask which migration strategy will contribute most to your organization’s overall business and IT goals. What is the business case for migrating an application to the cloud? Determine this before you decide how to make the transition so that you can predict costs and benefits.

From CAPEX to OPEX

The cloud is a real game changer, from both a technical and economic perspective. In the past, organizations invested significant sums to start a competing online service. But with the cloud, capital expenses (CAPEX) are almost a thing of the past, as costs shift to operational expenses (OPEX).

CAPEX = Capital Expenditures, investment costs for developing a system

OPEX = Operational Expenditures, the returning costs when using a system

It's because of the on-demand, “pay-as-you-go” nature of the cloud. You don’t have to invest in hardware; instead, you pay the cloud provider for the resources you use.

From this shift, our customers to change the way software is delivered. The first force concerns independent software vendors (ISVs) that are now asked to provide their software as a service (SaaS) because their customers want the same model for the software they buy as they now do with hardware in the cloud.

The second force concerns enterprises that are driven to reduce their operational costs. One way to make this happen is by adopting the cloud. You see many enterprises state in their plans to move completely to the cloud and get rid of their datacenters. It sounds very lucrative at first, but sometimes one tends to forget that just moving your existing machines to machines in the cloud is not at all economically beneficial. Your overall costs will probably become much higher.

How do you move to the cloud the “right” way?

The first thing to understand is that moving to the cloud is not a “one size fits all” business venture.

For example, if you’re the ISV mentioned above, you need to look at your current software and determine the cost of hosting it yourself first- a cloud transition confronts you with a cost your customers previously incurred.

You should replicate these costs for every customer you have. What is the state of the software and what’s its lifecycle stage? Was it recently built, or has it been out there for awhile and now needs a significant rework? Is it a product that is at the end of its lifecycle and you need a way to provide SaaS, but you don’t want to invest?

Once you know your application’s lifecycle stage, you can project it onto a cloud migration strategy model, such as the Gartner 5-R model (Rehost, Refactor, Revise, Rebuild, Replace), the Azure 5-R model, or AWS 6-R model.

The table below combines the strategies of these three different R models and explains their pros and cons. Pick one of these strategies based on your company’s cloud migration goals and the requirements and constraints of the particular application.

The strategies from the various “R” models are combined and explained in the following table.

Table 1: Cloud migration strategies

After you select one of the strategies, you need to look at two factors, the capital expense, and the operational expense.

First, what is the capital expense if you choose to rehost, refactor, rebuild or replace? All of these “R” strategies require investment in your solution before you are running in the cloud.

Next, you need to look at the operational expense of running this application in the cloud over the next five years. A graph can show you the total amount you will spend in over five years in any selected strategy.

For example, the graph below depicts the capital and operational expenses plotted over five years for a product we moved to the cloud.

The problem statement (or question, in this case) was: How can we move our product to the cloud, as quickly as possible, with a capital expense as low as possible, and still have a cost-effective operational expense for running the product for our customers in the long term?

We estimated the number of product users each year and the number of required changes to the product for each strategy.

The graph shows that a rehost strategy for this product will have a small upfront investment (CAPEX) cost but operational expenses will make the total cost increase linearly, because of the required use of virtual machines each year.

The refactor strategy focuses on changing the product to make it multi-tenant, which is more resource-effective than a rehost strategy because the product will no longer require dedicated resources for each customer.

The rebuild strategy has the best operational cost model. After the initial investment, the cost line hardly increases compared to the other cost lines. Eventually, it will be the cheapest, but the return on investment will take a couple of years because of the high initial costs. Another drawback is that time-to-market of the product will be longer compared to strategies requiring less significant changes. If you only do the lift-and-shift, you will see that within one year it will be more expensive than refactoring the application to support multi-tenancy. The latter scenario is cheaper because one instance of the application will provide service to multiple customers, whereas a dedicated application provides service to a single customer.

The replace strategy substitutes the product for a software-as-a-service (SaaS) solution. This is an interesting scenario from a cost perspective because the product subscription will be paid each period. The important question to ask here is if the product is a strategic differentiator. In other words, does the product contribute to innovation and differentiation of the product compared to the competition?

Based on this graph you could deduce a strategy of starting with a lift-and-shift, then start the investment first for multi-tenancy (Refactor) and then Rebuild it to cloud-native. Since it probably won’t make a lot of sense to refactor and rebuild at the same time, you may want to choose a scenario where you look for options to gradually refactor towards a full cloud-native product.

The main benefit of this example is that this way of assessing applications will yield a set of possible scenarios and it will give you insight into a hard business case to make the investment and determine the best strategy.

An Enterprise perspective

When you are in an enterprise organization, you can also make this same kind of assessment, but the difference will be that you need to deal with a portfolio of applications. In this case, first, divide the applications roughly into three categories.

 • Custom-built
 • Custom-built by a partner
 • Off-the-shelf and hosted on-premise

The category custom-built involves software that is built to make a difference for the company. Gartner calls these systems “systems of innovation”. These systems can be assessed in exactly the way we described for the ISV, and from that, you can pick the best scenarios.

The category custom-built by a partner includes the systems of differentiation, where you often buy a partial off-the-shelf solution, but fully tailor this to the needs of the organization. These systems can also be moved to the cloud. In this case, you often ask the partner that built the product to take care of this.

The category off-the-shelf usually means “systems of record”. These are the systems you need, but everyone has the same, and it is just there to ensure that you can run your business. There is no way you can gain an advantage by doing this differently from your competitor. For this category, you can often move to the vendor’s SaaS solution.

Assessing applications for cloud migration

Applications that are going to move to the cloud need to be assessed on multiple levels. It’s important to determine the current phase in the application’s lifecycle. After that, you should ask, “Where do we want to go with this product?” It may have been a “system of innovation” at one time, but by now each competitor also has it. This is the moment you choose to replace it with a SaaS solution. If the system will still be differentiating or innovating, it makes sense to look at the scenarios rehost, refactor, and rebuild. Practically, this means that the initiative for cloud transformation allows you to revisit the strategic importance of applications in the portfolio, and gradually migrate towards the cloud. The following figure shows the flow of assessment.

 Figure 1: Decision tree for application portfolio assessment

Cloud Transitions Done Right

There is no single cloud-migration strategy appropriate for all applications in the portfolio of an ISV or enterprise. A mix of different approaches is required, based on the value an application delivers versus the costs (investment and operational) of any selected strategy.

Now you know how to create a business case for moving your applications to the cloud. If you ask your development team, you will get a different solution from what your operations team tells you. From an economic perspective, you gain a more balanced view. Weigh the cost against the benefit of any cloud-migration approach.

There is no one-size-fits-all solution.

This article is part of the Urgent Future report Cloud - It's a Golden Age.