Over the last few months, I’ve been chatting with customers about managing cloud licenses and one observation from these conversations is that ‘managing cloud software’ can mean different things to different people. I believe this is due to the changing roles and responsibilities in organizations regarding managing IT assets and related costs, driven by the shift in where workloads are hosted and how applications are purchased.
The risk of this confusion is that there’s no clarity of what is needed to manage these environments, who is responsible, and which tools are best suited for enabling this visibility.
To manage software costs and risks well, ITAM and FinOps professionals need to have the right tools, governing policies, and processes to:
- Respond to a vendor audit
- Prepare for a vendor renewal
- Ensure their organization is adhering to regulatory requirements
- Mitigate against security threats
- Reduce software sprawl and spend
The above tasks are extremely challenging due to the distributed nature of where software is hosted, how it’s licensed, who manages it, and how it is purchased.
At the basic level, organizations have assets they manage both on-premises and in the cloud. According to the 2025 State of Cloud Report, cloud resources comprise 55% of workloads.
There are two main categories of cloud software – SaaS (end-user applications like Microsoft 365, Salesforce, and IT applications like Datadog), and data center software running on cloud workloads, such as SQL Server and Windows Server.
Cloud vs. on-premises software procurement
One of the main reasons it is so hard to govern cloud software is that it’s not centrally purchased. In the olden days, IT purchased most software. With cloud, it can be purchased in a multitude of ways, by almost anyone.
- With SaaS, a company can enter into a contract (direct/partner/MSP), or an individual can get access via their credit card and expense it or get access through the cloud marketplace. The implication of this decentralization is there’s no one department that holds the information of what the organization purchased, unless the organization is intentional about how SaaS applications are governed.
- For datacenter apps running in public cloud environments, organizations can use software already purchased through their enterprise agreement (also known as Bring Your Own License/BYOL), or those spinning up cloud instances can have the cloud provider give a license. It’s pretty easy to add a license to your cloud instance or check the box that you have a BYO license to cover use of the software. This is why it’s also easy to overspend on software licenses included in your cloud bill or over-allocate BYO licenses that you can’t cover in your existing contracts.
How cloud software is licensed
On-premises software licensing is relatively straightforward. Normally, you count the number of installations for end-user devices or named users for end-user software. For datacenter software running on-premises, virtualization and containerization have made licensing a bit more complicated, but the principle is the same – the count CPUs/vCPUs.
The cloud has enabled more innovation with how vendors license offerings, with licensing metrics having a stronger tie to value and how the product is used.
For SaaS, user and named user is frequently used, but now we have user type or application bundles that group use of certain features. There are also consumption metrics like the number of terabytes used, number of API calls made, and so on. The implication of these new license metrics is that organizations need additional methods to identify use of products and features to ensure they are getting the most (or any) value from what they’ve purchased. One basic example out in the market for a while is the various packages for Microsoft 365 – E1/E3/E5 – which have different features. If you’ve enabled E3 for users, and they are only using E1 features, then there could be a lot of potential savings in downgrading to another license tier.
For licenses used in the cloud, organizations can bring their own license (there are multiple rules around what is/is not allowed) or users can leverage the pay-as-you-go (PAYG) model and purchase a license from the cloud provider. The choice of license model should factor in how long the workload is planned to run, the cost of the license compared to buying it direct, and whether there are licenses available already purchased but not allocated.
Who should govern cloud and SaaS application licenses?
The teams responsible for managing SaaS and cloud software licenses vary depending on who you ask. When you ask ITAM professionals, 56% currently manage SaaS apps and 55% manage licenses in the public cloud. From the viewpoint of cloud management professionals responding to the State of Cloud survey, the SAM team is responsible for SaaS/cloud licenses less than 10%, and these assets are thought to be managed more by FinOps/CCOE/IT Ops teams. And according to Gartner, there is no single team responsible for governing SaaS applications.
To get started wrapping your arms around this problem, we recommend you map out your top applications in each category, and identify who is responsible for managing the costs, license compliance risk, sprawl risk, and with what tools. With this information, you can start collaborating across your organization to fill in gaps and improve processes and tooling to get better outcomes. Here’s an outline and questions to get you started.
- Who is responsible for responding to vendor audits and calculating the effective license position?
- Who owns finding un-used software and reclaiming those licenses? Who owns the vendor renewal strategy?
- Who is responsible for taking out spend? Do costs get allocated to lines of business?
- Who is leading the charge for application rationalization/standardization across your organization?
Learn more about managing cloud software by speaking to one of our experts at Flexera.
