How to build a business case for cloud migration

Why you need a cloud migration business case

As with any project, you need to sell cloud migration to the stakeholders and decision-makers based on its value to the company. The value might seem obvious, but you need to quantify it as much as possible to paint a clear picture.

The value might be cost savings, more scalability and flexibility, enhanced security, improved collaboration and accessibility, or addressing business continuity and disaster recovery concerns, said Meghna Shah, technology and transformation partner at PwC. "Whatever the mandate may be, it has to be a north star or combination of north stars that influence and contribute to your cloud migration journey," she said.

The plan also serves as a template for executing the cloud migration project by establishing expected timelines, costs, resources and risk mitigations. "You don't want to focus on the migration and then later on find out that you should have done an analysis first," said Vikas Ganoorkar, global cloud migration practice leader at IBM Consulting.

Steps for producing a cloud migration plan

These are the core steps typically required to build a cloud migration business case.

1. Ensure buy-in from key stakeholders to begin a business plan

This step typically starts with a key stakeholder who can be a sponsor or project champion, someone whose line of business or workloads can most benefit from a move to the cloud. That person will be instrumental in lining up other stakeholders whose collaboration will be needed.

You want key stakeholders to at least be open to the idea of moving to the cloud because you'll need their cooperation when building the plan. Getting initial buy-in to explore a cloud migration plan results in better feedback and access to data. Make it clear that they haven't committed to the cloud quite yet and can make a go/no-go decision after seeing the completed plan.

Some stakeholders, such as IT operations, line-of-business owners and finance will be obvious, but it's also important to include human resources (HR), risk and compliance management, security and change management teams.

Moving even small workloads to the cloud could require retraining or hiring, and bringing HR onboard early ensures the skills will be available when you need them. Moving workloads to the cloud might change or create risks, especially in highly regulated industries. Involving risk and compliance teams from the start means you won't have to do mitigation after the fact.

It's a similar situation with security. The cloud changes your security posture, and your security team can help avoid introducing new security vulnerabilities. Finally, change management can help you with some key tasks, particularly training, upskilling and communication, according to Shah. It can also help people prepare for the new way of working, which is a critical part of adoption, she said.

Ganoorkar emphasized that vendor partners are important stakeholders. "[A cloud migration] might start as a very simple migration engagement, but then we realize at time of execution that the workloads are such that different entities and different organizations have to be on board," he said. "Their rules are required; their collaboration is required. If not, that causes significant delays later."

2. Identify and clearly explain the business benefits

You need to tie the cloud migration project to a business need or benefit. "What is the motivation?" Ganoorkar asked. "Why do you want to make a change? What are the business drivers? What is the core rationale for making the change?" The motivation might be a need for more speed or to be more competitive, or introducing new technology such as generative AI. An acquisition, merger or divestment might also spur an organization to consider a cloud migration or modernization, he added.

3. Map the current environment and compare against the cloud

Inventory all in-house assets and assess staffing and other resources that support the systems you hope to migrate. A technical assessment should include an evaluation of the current IT infrastructure, including hardware, software and networking capabilities. It should also include the compatibility of your current applications and workloads with cloud platforms, Shah said. You also need to know the performance metrics for the current system, which will serve as a baseline against projected performance in the cloud.

You will need to know the annual cost of the following:

• Running your current environment.
• Servers and other equipment.
• Relevant data center services.
• Staff and contractor services.

Once you understand the in-house environment, you can begin to map it to the cloud. The cloud comes in several forms, so you'll need to explain to stakeholders why you chose the type of cloud you're recommending.

In some cases, the migration is from one cloud platform to another. "It's not just on-prem to cloud. I would say in the past six or seven years we saw primarily business cases where clients moved their on-prem to cloud [to reduce costs]," Ganoorkar said. "Now, we are seeing clients thinking about reshuffling their public cloud workloads," and asking if they're better off sticking with one public cloud or moving to another, he said.

4. Measure and monitor cloud performance and ROI against existing environments

Here are the most common items to track and measure.

• Speed of service. The business plan might need to show how you plan to track performance against the expectations you've set. Shah said stakeholders will be especially concerned about this if you are moving applications that require low latency to cloud data centers that are geographically distant. In that case, the business should address potential issues with data center reliability and proximity as well as potential bandwidth limitations on the network.
• Cost control. Predicting cloud costs and savings compared to running an in-house system can be a challenge. Stakeholders will want to anticipate worst-case scenarios caused by things like delays or mistakes due to mismanagement, additional cloud resource requirements or underestimating the complexity of the project, according to Shah. She suggested focusing on constant cost monitoring and cloud resource optimization for cost control.
• Staffing and training. Map existing in-house skill sets against those needed for the cloud and include a plan to acquire talent where necessary and train existing staff.

5. Plan for cloud migration risks and challenges

Any business plan should identify potential migration risks and explain how your team will respond. These are the common risks associated with cloud migration:

• Inadequate training or missing skill sets. Explain how you plan to upscale your talent to provide the cloud engineering and other skills needed during cloud migration and after it goes live.
• Security. Anytime you move workloads, there are security risks from the big physical move to the target state, Ganoorkar said. "How do you make sure that your data is secure, your access is secure and that everything else is taken care of in a strong manner?" Describe what security responsibilities will remain in-house after the cloud migration and how you're prepared to fulfill them.
• Compliance. When you move workloads, data and applications to the cloud, you risk falling out of regulatory compliance. For example, Ganoorkar cited a client case where the organization wanted to move to a public cloud but had on-premises applications where the data, database and applications needed to be in one location. "If you don't have it in one place [in the cloud] and you're not managing it, then that becomes a problem," he said. Outline the laws and regulations relevant to the cloud migration and how you will ensure compliance.
• Data privacy. Explain how you will protect and maintain control over sensitive customer, partner and employee data once it's in the cloud.
• Vendor lock-in. Both Shah and Ganoorkar identified cloud vendor lock-in as a key concern among decision-makers, especially if the recommendation is to go with a single cloud provider. You will need to explain how the organization could move to a multi-cloud environment or another cloud host if necessary. If you go with a single cloud host, make sure the terms of the contract and service agreement don't create barriers to switching platforms in the future.
• Complexity. Ganoorkar said 20% of projects have complex workloads, large applications or monolithic legacy applications. The business plan should explain how you will add value by simplifying that complexity. "If I'm able to balance that, I have high velocity and low cost for simple workloads, and I have a mechanism and a robust methodology to help take care of the complex situations," he said.

6. Explain how you will measure cloud performance against ROI promises

Your migration plan should outline how you will monitor cloud performance and provide metrics for how it delivers on the benefits. "It's a whole lifecycle when it comes to the migration factory," Shah said. "It's not just a one-step thing. You're going to have the diagnostics, the design, the move to the cloud and DevOps."

Shah recommended creating dashboard reports to show how each workload is going through the process, as well as tracking and reporting the value the migration is delivering as defined in the business case. "Obviously, the big one is cost drivers. How is [the cloud] affecting your Capex cost? How is it impacting your Opex costs? Those are some of the pieces that will be big from a reporting standpoint."

Shah believes you should also report on how people will be affected. "[Don't] just look at it from a technology standpoint, but [from a] human aspect: The number of people who have been upscaled and trained. That becomes an important metric as well. Evaluate how the technology not only affects the business but is also improving [the] lives of people."

Michael Nadeau is an award-winning journalist and editor who covers IT and energy tech. He has held senior positions at CSO Online, BYTE magazine, SAP Experts/SAP Insider and 80 Micro.