One of the conversations I have had many times as a technology leader does not have much to do with actual technology at all, but how you pay for it – what does it really mean to move from a capital expenditure-centric and on-premises approach to an operational expense-centric cloud approach? In my experience, moving away from cap-ex and on-premises benefits everyone AND there are op-ex savings driven by the cloud, especially when it comes to enabling the team you have today to do more.
Tying up a bunch of capital in on-premises systems in a data center never really made much sense to me if there was an alternative. Companies want to use capital on investments to further the organization’s financial goals and strategy. I have never heard a CEO or CFO consider a network switch or data storage an “investment”. It was just paid for that way because the hardware and software required an expensive initial purchase and that meant capex. Further, 80% of the time the hardware or software that you purchased with a 5-year depreciation schedule would need to be replaced by something else in 3 years anyway.
Direct cost benefits:
Cloud SaaS licensing is a variable cost driven by headcount - It is easy to forecast, and easy to reduce software costs if it is no longer needed. Cloud IaaS is driven by business needs as well, and those costs are largely predictable. (You can even save some money by pre-paying for the year.)
Cloud costs tend to align with the business cycle - Rather than the peaks and valleys of an on-premises capex hardware refresh cycle, the cloud reduces peaks and valleys. Costs are more predictable and aligned with other business activity. For example, if you are acquiring another company or hiring seasonal staff then you will likely need to increase IT spend for that period, but you can avoid the lift-and-shift on-premises server lease renewals in the same year that revenue or margins are expected to be flat.
Telephony costs – Costs related to on-premises proprietary voice vendors are always high and enable what is seen by management as a commodity service. Moving to Teams can eliminate many of those costs, and it is also remote-worker native.
Facility costs – If you don’t purchase physical technology assets, you also don’t need a secure, climate controlled, and redundantly-powered places to put them. The cost of an on-premises system is increased by the overhead for data center space. Reducing your footprint means reducing your facility, networking, and telecom costs as well. (I am willing to bet that Microsoft’s facility overhead per server is probably lower than yours…😊.)
Enterprise software – Enterprise systems require a huge initial expense to acquire and operate on-premises. The technology world is moving away from an on-premises model, so much so that best-in-class choices can be limited to only the cloud. You can avoid large capex costs altogether if you operate your ERP or CRM in the cloud.
No more capacity hoarding – Every on-premises hardware item I have ever purchased was oversized, because I knew that it would need more capacity by the time it was retired. Overbuying to match a multi-year on-premises refresh cycle adds cost that could be applied to something more valuable. You can increase the resources on an Azure VM or add more M365 accounts on the fly and not have to pay for them until the moment you need them.
More accurate project ROI/TCO – Since cloud servers, services, and software are so modular, so are the costs. You can spin up new resources for a particular project and build that spend directly into the project cost, then delete them when no longer needed. This is very difficult to do in an on-premises environment and is another cause of capacity hoarding.
No more long-term contracts or equipment leases – Stop trying to predict what the future of technology will look like in 3 or even 5 years. I cannot count how many times the end of a long-term contract could not come fast enough because it was hampering the company in some way.
Lead times are almost zero – It takes a long time to buy and configure your own hardware and software, especially given some of the supply chain challenges the world has experienced lately. Adding some new cloud resources requires checking a few boxes and a comparatively simple configuration in a web interface. That’s it. And no racking, stacking, cabling, etc…..
Test environments are no longer a pain point in the cloud. (See my point above.) The creation and deletion can even be automated.
Cloud resources are zero-trust and remote worker native - VPNs as you know them can be eliminated. Nothing makes remote employees happier and drives productivity more than not needing to call the service desk. (Maybe this should be at the top of the list.)
Technology time benefits:
Flip the 80/20 rule – In my experience, the teams I led spent about 80% of their time managing the infrastructure, upgrades, trouble tickets, backups, facilities changes, and so on. As we would move to cloud services, many of those tasks simply stopped being necessary or could be completed in much less time. As we neared the end of our journey to the cloud, those same people could work on projects to improve value to the business rather than just “keeping the lights on”. Issues were resolved more quickly; they could spend that 70% or 80% of their time with other staff figuring out how to solve business problems and make sure that all those less-important tasks that used to be pushed off until later actually started getting done. (Having a clean and well-maintained Azure AD and Active Directory saves all sorts of time as you implement new projects and services…).
You can slow your headcount growth across the board - Hiring people is hard, and retaining people is sometimes harder. Cloud technologies allow the same team you have today to do more and engage with people outside of IT to solve problems and build solutions with the tools you already have. That saves everyone time.
How you use your time changes (for the better) – Moving to the cloud changed the way that people in the technology group spent their time. Much less on day-to-day issues and troubleshooting, but much more on planning, understanding cost, new features, and figuring out how to best make use of all the functionality offered. We would still use partners extensively to augment specialized functions and provide deep technical and product expertise, but the staff was able to broaden their skill sets and focus on delivering value rather than simply uptime.
This is the second part of an ongoing series about my time leading organizations to the cloud as a technology executive and sharing what I have learned. The first installment is here.