In this blog I will roughly explain what cloud rationalization is, why it is an important part of digital transformations or cloud adoption, and I will help you get started with cloud rationalization.

What is cloud rationalization

Digital transformation is at the top of the agenda for many organizations, and cloud adoption is inextricably linked to this transformation. This has an impact on people, processes and technology. It’s all the more strange that many IT organizations are mainly focused on technology, without considering the intended business outcomes and motives for cloud adoption in the migration and modernization strategies. While cloud rationalization should of course take into account the capabilities and impossibilities of target platforms and compatibility, it is primarily a strategic consideration.

Cloud rationalization is an integral part of any digital transformation program and cloud adoption plan. Cloud adoption plans convert the aspirational goals of a cloud adoption strategy into an actionable plan. It is common that a cloud adoption strategy arises from a business case, consisting of financial and technical considerations, motives and expected outcomes against which justification of the projects is measured. Cloud rationalization is the process of evaluating assets to determine the best way to migrate or modernize each asset in the cloud, closely aligned with the cloud adoption strategy.

The Rs of rationalization

There are several definitions of rationalization options circulating on the internet. The five R’s of rationalization listed here describe the most common rationalization options and the options described by Microsoft:

The five Rs The five Rs of rationalization by Rolf Schutten on Schutten.Cloud

The other definitions that are used refer in most cases to the options mentioned above. Below is an overview of some rationalization options that basically mean the same thing, but use a different name:

  • Replatform: Replatform is in most cases the same as Rebuild.
  • Repurchase: Repurchase is in most cases the same as Replace.
  • Retain: Retain is the option where no migration of the application will be executed at this point. Reasons can be the lack of important information, being hindered by other factors, or the application fitting the current requirements.
  • Retire: Retire is the option where an application is explicitly phased out.
  • Reimagine: Reimagine is in most cases the same as Rearchitect.

The pitfalls of cloud rationalization

It is impossible to make rationalization decisions before analyzing workloads and associated assets, and gaining deeper knowledge of the current digital estate. A rationalization decision is closely intertwined with the objectives and intended results. For example, the motivations for a data center exit and reduction in capital investment may fit well with a “Rehost” approach, but that approach in itself will not (directly) result in a reduction in vendor or technical complexity, cost savings, or increased business agility. More will be needed to achieve these goals. “Replace”, “Refactor” or “Rebuild” approaches may be more appropriate for some workloads.

The stages of your migration and modernization journey The stages of your migration and modernization journey by Microsoft on How to Migrate and Modernize with the Cloud | Microsoft Azure.

Another pitfall in cloud rationalization is the assumption that rationalization decisions must be made for the entire landscape before the migration or modernization can begin. Microsoft has as a rule of thumb that it generally takes 40-80 FTE hours per application to perform an analysis. This would mean that an application landscape of 50 applications results in 2000-4000 FTE hours, before the migration or modernization can take place. For example, I remember the “Attack Program Information Facilities” of the Dutch National Police. At the start of that program (in 2010), the landscape consisted of approximately 1200 applications. That would result in a workload of 48,000 to 96,000 working hours; this implies 24 to 48 full-time employees needed to complete the analysis within one year. A lot can change in that time. Therefore, it is recommended to take an incremental approach and perform cloud rationalization per application or workload.

Cloud rationalization in 5 steps

When it comes to a full analysis of your digital estate and cloud rationalization, it generally takes place in 5 steps: discovery, tracking, analysis, dependency mapping, and reporting. The following sections describe the input, processing, and output of these steps, and in some cases some tools that support these steps. There are many tools available on the internet from different providers. It is up to the person conducting the analysis to choose the right tooling. The analysis leads to an overview of the targets, challenges, resources and costs needed to make rationalization decisions.

Prerequisites

As mentioned earlier, motives and expected business outcomes lead to a digital transformation program and/or a cloud adoption plan. The chosen (cloud) strategy is a fundamental part of this. The Microsoft Cloud Adoption Framework for Azure describes detailed examples and antipatterns for building a business case and cloud strategy. It is preconditional that these steps have already been taken before rationalization decisions are made; simply because these decisions must be based on previous strategic choices.

Lifecycle of the Cloud Adoption Framework. Lifecycle of the Cloud Adoption Framework by Microsoft on Microsoft Cloud Adoption Framework for Azure documentation - Cloud Adoption Framework | Microsoft Docs.

Step 1. Discovery

It all starts with inventorying and measuring the digital estate and assets owned by the organization today. The digital estate consists of assets such as virtual machines (VMs), servers, applications, data, and so on. How the digital estate should be measured depends on the desired business outcomes.

  • Organizations primarily looking to optimize costs, operational processes, agility, or other aspects of their operations focus on VMs, servers, and workloads.
  • Organizations that want to realize customer-centric transformations focus on applications, APIs, and transactional data that support customers.
  • Organizations focused on launching new products or services focus on silos of data across the organization to build a strong foundation of data.
  • Organizations that prioritize operational stability will need to include this as a focus area and measure business continuity, disaster recovery, and reliability of workloads and assets.

Organizations generally complete all these transformations in parallel. The prioritization must be determined on the basis of the previously drawn up cloud strategy. Remember it is best practice to go for an iterative approach. This is why having a clear cloud strategy is a precondition for all cloud adoption efforts. When you understand the most important form of transformation, digital estate planning becomes much easier to manage. Typically some form of inventory can be found in CMDB databases or IT spreadsheets. If you do not have an inventory of your digital assets in your organization, then you need to build one either in an automated way or manually. Example of tools that can support your discovery efforts are Azure Migrate, Lansweeper, SolarWinds, or other inventory and asset management software that is around on the market. An inventory is rarely complete in its first iteration. Therefore it’s recommended that the inventory is validated by stakeholders and power users.

When the inventory is complete, it provides an overview of the current digital estate and all assets owned by an organization. The form in which this is presented depends on the preference in which the inventory has taken place, but some examples are a CMDB database, IT spreadsheets and/or architecture diagrams.

Step 2. Tracking

The next step is to make a first selection of rationalization decisions based on the inventory. Some rationalization options can be crossed out immediately. By reducing the number of potential outcomes, it’s easier to reach an initial decision about the future state of an asset. When you reduce the options, you also reduce the number of questions asked of the business at this early stage. Aspects such as the makeup, compatibility and end-of-support of applications or workloads play a major role here. Some examples are for example:

  • A monolithic application that is no longer supported by the application vendor is not likely to qualify for a “Rebuild” or “Rearchitect” option.
  • A workload on an outdated operating system for which security updates are no longer available and which is no longer supported will not be eligible for a “Rehost” option.
  • A business-critical application that has recently invested heavily in customization to support specific business models and processes, will not likely qualify for a “Replace” option.

The preference is to reduce all rationalization options to two options that remain, which need to be further investigated and analyzed. For example, if the options are limited to rehost, or replace, the business needs to answer only one question during initial rationalization, which is whether to replace the asset. A powerful tool that can help the tracking and analyzing efforts of application rationalization is CAST Highlight. There are other tools on the market that support these efforts, but CAST Highlight is one of the more well-known and mature tools out there.

Step 3. Analysis

The quantitative and qualitative factors should be further analyzed in this step, so that a sound rationalization decision can be taken. In addition to these factors, the use of the workload or application in question (forecast), optimization of costs, and license offers are also considered. The analysis should lead to the results of the remaining rationalization options, looking at the final state of these options:

  • How does the choice relate to the motivations to drive cloud adoption and are the expected business outcomes being achieved?
  • What are the differences between the qualitative and quantitative factors?
  • What are the expected costs (the investment required to reach the final state and the expected total cost of ownership over a predefined period)?

This analysis means that the expected usage needs to be viewed both quantitatively (based on actual metrics and collected data) and qualitatively investigated (by talking to business and application owners about seasonal patterns, expected usage, etc.). Various monitoring tools can be very helpful for this analysis. Also Azure Migrate is a helpful tool to collect this quantitative data, which can immediately make recommendations for possible optimizations (all depending on the rationalization options).

To calculate the required investments you can use the Total Cost of Ownership (TCO) Calculator, Azure Pricing Calculator, or third party tools such as The Cloudlab Smart Calculator.

Step 4. Dependency mapping

The next step involves providing insight into dependencies and mitigating any issues. These dependencies can exist in several areas, such as:

  • Multi-tier applications, where a solution consists of a front-tier (web), middle-tier (processing) and backend (database). Depending on the rationalization options, a particular migration or implementation method and sequence may be preconditional or more logical.
  • System integrations, where applications or workloads integrate with each other to create one or more business processes.
  • Other dependencies, e.g. in connectivity.

It is highly dependent on the relevant application or workload where any dependencies lie. The previous inventories, analyzes and conversations with business and application owners will have to make these transparent.

Mitigating actions can be, for example, a sequence of migration and modernization actions, the joint migration and/or modernization, or a two-stage approach in which a Rehost is performed first before modernization is carried out.

Step 5. Reporting

Finally, it is important to compile good and reliable reports and present them to the decision-making body for cloud rationalization. If multiple scenarios are possible for an application or workload, these must be placed next to each other. The advantages and disadvantages, expected outcomes and mutual differences of the remaining options will have to be listed, so that a decision can be made.

All of the aforementioned tools have contributed to this point, and each of these tools provides information that is relevant to the reporting. To support a benefits review plan, tools like AppDynamics are a godsend. For a large digital estate, it is recommended to use a similar support tool, so that control and insight remain on all different applications and workloads. It is probably less relevant for the smaller digital estates.

Closing words

This blog article has explained what cloud rationalization is, why it is important, and in which steps you come to rationalization decisions, so that you can get the most out of the cloud. This is just one way to approach cloud rationalization, but there is no single road that leads to Rome, and no cloud adoption journey is the same. It is therefore important to delve into the possibilities and impossibilities of the cloud, to define what the intended results and expected outcomes are, and what implications possible choices may have. Microsoft, Amazon and Google have each written their own guidelines and documentation on this topic, which are definitely worth a closer look if you want to get started with cloud rationalization.

Defining a cloud strategy, drawing up a cloud adoption plan, choosing the right rationalization options, and migrating, modernizing and transforming your digital estate is not easy. There are countless examples where the digital transformation or cloud adoption has not been successful or has not delivered the expected business outcomes. In many cases, organizations would therefore be wise to hire a partner who will support and guide them in this.