Exploring Cloud Migration Cost Considerations
May 16, 2019
- Posted by: Nick Youell
This article is part of an ongoing series about the pros and cons of the cloud, cloud migration, cloud costs and cost control. Here we explore the importance of establishing a cost baseline as the first step of any cloud migration project.
The basic financial drivers for a cloud migration of an existing business system are usually cost clarity and predictability and/or cost reduction. That’s not to say these are the only drivers; agility is an oft quoted one, but if cost is your focus then it’s worth exploring some aspects to consider.
Cloud costs tend to be clear cut and relatively easy to understand, at least statically, before you start growing, but that’s for another article. On-premise costs are often shrouded in equipment depreciation and ongoing warranty calculations, maintenance costs, shared staffing and facility costs, management charges, etc., which makes them hard to accurately calculate.
Just gaining an understanding of the total costs of owning and running an existing business service are sometimes enough to justify a move to the cloud.
Cost reduction may require re-engineering to achieve – for example, periodic or light workloads may currently benefit from a serverless implementation rather than a “lift and shift” – but whatever form the migration takes you still need a baseline of current cost to measure against.
Any costs comparisons between on-premise and cloud hosted should be viewed over 7 to 10 years, as this is the typical life of most large systems.
A complex on-premise legacy business system is rarely hosted on a single server or device. Often the biggest problem is identifying all of the components that make up a “business service.” It could be “spread” over multiple devices, use currently unknown 3rd party services or even be a disparate set of interacting services sharing underlying hardware with other business systems.
Hardware CAPEX costs and tax breaks – often spread over a number of years – are hard to quantify and allocate to a specific business service; all the servers, switches, routers, firewalls, storage, etc., that together support the business service. Software maintenance adds another dimension to the calculation, but what and how much software does the business service use?
Before you can understand the current cost to run a business service, you need to understand what all the “pieces” are.
Having tools that can automatically discover all of the dependent elements of a business service – both hardware and software – and the potential dependencies on other 3rd party services is essential here.
Another large part of the costs of ownership are the staffing costs to maintain a business service. There are networking, infrastructure, DBA, NOC and other staffing costs to be allocated and considered as part of the ongoing cost of the service. Upgrades and enhancements to the service would happen regardless.
Hopefully IT has accurate records of time spent on these systems to allocate costs, but if not, it can be difficult and may mean interviewing employees to get a picture of the effort required.
Indirect staff costs should also be accounted for – costs allocated form other critical groups in the organisation, e.g. Procurement, HR and Finance – all very much part of the cost of deploying and maintaining a complex business service.
Another large contributor to consider is the cost of physical infrastructure. The data centre, the electricity to run and cool it, the network infrastructure, bandwidth, security systems, etc., all need to be calculated over time and apportioned to the business service that uses these facilities.
Once you understand all of the elements that combine to “create” your business service, facilities costs for each should be available from the IT group. Even if sometimes they are a bit granular – e.g. cabinet costs – some reasonable allocation of cost should be possible.
This article touches on the larger, more obvious elements of establishing a cost baseline. It does not explore the costs of any migration, the costs once in the cloud or how you control them. These are subjects for future articles.