Making the business case for the transition to the cloud

09 June 2021 5 min. read
More news on

The Covid-19 pandemic has accelerated the transition to the cloud, with nearly two thirds of CIOs stating that cloud will be a huge focus for IT teams over the next twelve months. Despite the intentions, making the case for cloud investments can be challenging. Vishal Patel, Technology & Architecture lead at Coeus Consulting, outlines how the case for change can be made. 

1. Understand the “as-is” environment

A good understanding of the current environment is important in planning a successful cloud transformation. Clearly documenting the current technology landscape, as well as the organisation’s business capabilities and business requirements will help companies better understand which business areas they want to focus on and help articulate the benefits they intend to realise. 

2. Engage the business

Whilst transforming the IT infrastructure away from hosted model to cloud solutions may provide the CIO with a cost saving, the more compelling business case will be from the transformation of business processes and streamlining organisational data pipelines.

Making the business case for the transition to the cloud

Therefore, the success of any large transformation will be in getting business buy-in and more importantly helping the business understand the organisational and cultural change required to deliver the benefits and value to the organisation. 

3. Create the business case

Whilst this may seem straightforward, developing a business case for cloud services can be very complex. Cloud cost models are typically elastic based on usage or consumption, which can make it extremely difficult to model usage and demand, especially where the existing baseline is built up of fixed costs from capital depreciation of assets, licence, and support costs.

Modelling business elasticity and scaling is key
Modelling full costs for all environments and data is key – don’t just consider the production instance. 

The cost & risk of doing nothing is also key
Existing aged solutions may appear to be very low cost (no license fees, out of support - so no maintenance fees, infrastructure fully depreciated etc); however the real costs are often in risks, in people and skills availability, in interoperability. Whilst not easy, these all need to be factored when justifying any case for change.

Outline the business benefits
Along with the commercial benefits, outlining the business benefits will be important to help sell the transformation to the board and senior leadership. Outlining how pain points within the existing business processes will be addressed, how business processes can be streamlined and automated, as well as reducing the time and cost of change will be important considerations in developing the case for change. 

4. Create the compelling case

Trying to create a business case to move services to the cloud midway through a contract can be difficult; we recommend leveraging a natural tipping point to create a compelling business case. Such events could be when a significant upgrade to a business application is approaching, a large infrastructure upgrade is required or when a new business investment is being made which requires investment in new technology. 

5. Develop the operating model

A change in technology architecture will require new skills, processes and culture to realise the benefits of cloud services. For example, traditional change processes for releasing new functionality to the users may feel frustrating when SaaS providers release new functionality on a more frequent basis.

6. Start small and scale

Identify business capabilities or key business processes as pilot transformations, both with the technology and organisation. Ring fenced or pilot initiatives can help to demonstrate value to the business, address governance challenges and ensure that the change in culture can be embedded into the organisation. The ability to operate differently, accept change and risk may take time and focus to embed.

a) For IaaS and PaaS – don’t get fixated by cloud provider X versus Y, the market drives a commonality of core functionality, and there are providers regularly leapfrog each other on specific features or prices; the ‘big 3’ are all highly credible in this space.

b) Build foundational enablers as few times as possible, share architectures for connectivity, accreditation, authentication etc wherever possible, avoid ‘per project’ solutions for such things.

c) Don’t make your data-centres the gatekeeper or dependency for such services – ensure that your cloud services can still continue if your own data centres/services are unavailable for any reason. Remember that it’s more efficient and resilient for your users’ network traffic to go directly to the cloud provider than route via your data centres, although this will need some security and network adjustments through the technology stack.

d) Governance will need to change – many companies use finance as a threshold barrier for governance, with cloud these move from periodic larger negotiated values to continual smaller variable values. Governance needs to move to a usage & data based model, a “why & what” rather than “how much”.

e) Regulations and compliance – use of cloud services does not in any fashion absolve the business from sector of data privacy based regulations; indeed care will need to be taken on the assurance & compliance of these, including sovereignty aspects of cloud service provision.

f) Details – things that today may be a ‘silent one off cost’ (internal network bandwidth, information exchange between two data-centre applications) may now have usage based charges affecting them (network bandwidth, firewall traffic, API calls etc can all now be chargeable). You’ll need to both identify these, but also find ways to communicate them, and how to influence / control them, to the relevant parties.

g) Don’t forget the basics – the non-functional requirements still need validating and managing; you are still accountable for your business use of cloud! Do you diligence for “if it goes wrong” as this may have material impacts if you need to change. The use of business impact analysis approaches can help a lot for the triage and prioritisation here.