Cloud Migration Strategy Matrix

The biggest problem with most cloud migration assessments is that it focuses on VM-sizes and potential cost savings. Don’t get me wrong, this is a very important area of concern… and there are some immediate benefits to simple cloud migration… but why transition to a life in paradise only to maintain a similar lifestyle? Transitioning to the cloud should be about harnessing its full potential — embracing qualities like agility, elasticity, reliability, security, etc. It’s about making the most of the cloud’s transformative capabilities rather than just replicating existing setups.

cloud-benefits-pyramid Cloud Adoption Benefits Pyramid

Modernizing every workload is not a practical approach. To determine which workloads to modernize to cloud-native, migrate to IaaS, or refactor to serverless, a decision strategy is necessary. In this post, I will discuss the decision strategy that I use.

If you haven’t done a cloud migration assessment yet, this is a good place to start. I recommend using specialized tools to scan your digital estate as they discover workloads that you forgot or did not know existed. Migration tools generate a comprehensive list of servers with their corresponding CPU utilization. This provides insights into whether those servers are still in use, oversized, or candidates for decommission.

Cloud Migration Report Analysis

Step 1: Group Servers by Workload | Workload Inventory

The first step is to group your server list into a set of workloads. For example, a group of web, app, and DB servers may all be related to an intranet employee site. This gives you a clearer picture of what is represented by those servers.

#Server NameWorkload NameCPURAMDisk SizeCPU Utilization %
1mssqlsvr01Employee Intranet4 cores16 GB500 GB70%
2appsvr01Employee Intranet4 cores16 GB250 GB45%
3web01Employee Intranet2 cores8 GB250 GB85%
4mssqlsvr02CRM8 cores32 GB1 TB70%
5appsvr02CRM8 cores16 GB500 GB45%
6web02CRM4 cores8 GB250 GB85%
7mssqlsvr03Retail eCommerce8 cores32 GB1 TB30%
8web03Retail eCommerce8 cores32 GB500 GB50%
9mssqlsvr03Retail eCommerce4 cores8 GB500 GB20%
10filesvr01File Sharing4 cores8 GB2 TB20%
11mailsvr01Email Services8 cores32 GB1 TB75%
12cache01Caching Server2 cores4 GB250 GB90%
13backup01Backup Services8 cores32 GB10 TB55%

This table is oversimplified for illustration purposes. In reality, this is a tedious and manual process, but it is worth the time. Assessment tools will only be able to tell if a server is a web or DB server, but they won’t know if it’s an e-commerce site, a CRM, or something else. Someone will just have to do the work.

There are two common challenges I’ve encountered when creating this view:

  1. Servers may be shared and may contain multiple workloads: In this case, indicate the multiple workloads contained in those servers. Cloud sizing is elastic, so it is not a problem to split up the workloads into different cloud services with smaller sizes.
  2. It’s not easy to determine which workloads are running on each server: This will have to be resolved manually. It involves checking the dependency mapping (which is part of the cloud migration report) and inspecting each unknown server to discover what workload it is for.

Step 2: Create a Business Differentiation/Code Complexity Scatter Plot

Now that you have a workload inventory list, the next step is to understand the Business Differentiation and Code Complexity of each workload.

On a scale of 1 to 10, rate the business differentiation of each workload.

  • Is the workload revenue generating? How does it affect your bottom line?
  • Does it require frequent changes due to market changes, competition, or agile business priorities?
  • Is it a workload that you think will greatly benefit from the promises of the cloud?

On a scale of 1 to 10, rate the code complexity of each workload.

  • How easy is it to make changes to the code?
  • Do you still have developers who know the code?
  • If you make code changes, can you still do the regression tests required?
  • If you want to rebuild it, do you still have (or need) up-to-date functional documentation?
  • It is a bought solution and you do not own the code? Think of this as deployment complexity instead. How easy is it to redeploy this workload to the cloud?
  • Are there organizational, political hurdles or other non-technical factors that prevent you from making changes to the code or redeploying the workload to the cloud?

Using our example, we can rate the workloads as follows:

Workload NameBusiness DifferentiationCode Complexity
Employee Intranet24
Retail eCommerce107
File Sharing11
Email Services22
Caching Server31
Backup Services44

Continue doing this for all of your workloads and then create a scatter plot. The resulting graph will look something like this: workload-scatterplot Workload Scatter Plot by Business Differentiation and Code Complexity

The Cloud Migration Strategy Matrix

With this scatter plot, we can now group the workloads into three areas. Each area represents a different migration strategy.

cloud-migration-strategy-matrix Cloud Migration Strategy Matrix

  • Area I is about rearchitecting the workload to cloud-native. This almost-always involves a complete rewrite of the application and is only recommended for workloads with high business impact. As this takes time, most organizations will Rehost to IaaS or Refactor to Serverless first as they work on the cloud-native version in parallel.
  • Area II is about deploying the workload components to serverless. The cloud offers many services that require minimal-to-no code changes to migrate, such as PaaS web apps and databases. These services allow you to get many cloud benefits with minimal effort.
  • Area III is where you can do anything you want. It comprises of workloads that are low in business impact with varying code complexity. These are the workloads that you should do the least effort to migrate and to maintain (post-migration). Rehosting to IaaS will involve the least migration effort, but replacing with an equivalent cloud service will help you simplify your infrastructure and optimize your operations. These low differentiating workloads are also the top candidates to retire and exclude from the cloud migration effort.

It is important to emphasize that business differentiation does NOT mean business criticality. Having a reliable CRM is business critical but not business differentiating. Almost every successful business will have a good CRM system. The same is true for SAP. Is SAP business critical? Absolutely! But does it differentiate you vs. your competitors? No, they likely use SAP as well… and you don’t care if they are using a later version than you. Examples like CRM and SAP are great candidate workloads to migrate to solutions like D365 CRM or SAP RISE. Migrating to a SaaS or a cloud-managed service will allow you to focus operations to your business differentiating workloads.

Concluding our example, the resulting cloud migration strategy for our server inventory will result to this:

#Server NameWorkload NameCPURAMDisk SizeCPU Utilization %Business DifferentiationCode ComplexityAreaMigration StrategyNotes
1mssqlsvr01Employee Intranet4 cores16 GB500 GB70%24IIIRehost to IaaS 
2appsvr01Employee Intranet4 cores16 GB250 GB45%24IIIRehost to IaaS 
3web01Employee Intranet2 cores8 GB250 GB85%24IIIRehost to IaaS 
4mssqlsvr02CRM8 cores32 GB1 TB70%39IIIReplace with SaaS 
5appsvr02CRM8 cores16 GB500 GB45%39IIIReplace with SaaS 
6web02CRM4 cores8 GB250 GB85%39IIIReplace with SaaS 
7mssqlsvr03Retail eCommerce8 cores32 GB1 TB30%107IIRefactor to ServerlessRearchitect in Phase 2
8web03Retail eCommerce8 cores32 GB500 GB50%107IIRefactor to ServerlessRearchitect in Phase 2
9mssqlsvr03Retail eCommerce4 cores8 GB500 GB20%107IIRefactor to ServerlessRearchitect in Phase 2
10filesvr01File Sharing4 cores8 GB2 TB20%11IIIReplace with PaaSAzure Files
11mailsvr01Email Services8 cores32 GB1 TB75%22IIIReplace with SaaSM365
12cache01Caching Server2 cores4 GB250 GB90%31IIIReplace with PaaSAzure Redis Cache
13backup01Backup Services8 cores32 GB10 TB55%44IIIReplace with PaaSAzure Backup
This post is licensed under CC BY 4.0 by the author.