Perpetual Use or Usage-based Services

Hub owner: BRUNO SANTOS - Last updated on: 15th November 2022

When evaluating solutions with different commercial models, inevitably we rush into simple price point comparisons, or attempt to make multi-year cost projections searching for a breakeven point. While a projection like the one below may seem suited for small applications and static environments, it’s fairly limited and often not valid to most of today’s applications, as it only looks at Year 1 pricing and tries to extrapolate it to the following years. 

DataMiner cost projection example – perpetual vs yearly subscription
Simple cost projection example – perpetual vs yearly subscription. In the example the expected startup cost on year-1 is considerably higher for perpetual, with subscription’s projected long-term cost surpassing perpetual around year-3. 

By static environment we mean one where infrastructure or technology used, scope, requirements, processes, or workflows are predictable and not expected to change in the span of 3 to 5 years. In reality, most of the environments today are much more dynamic and uncertain, with shorter technology cycles asking for more agile commercial and technical solutions. 

Cost ≠ Value

Long-term value looks beyond the price of the solution today, in a real cost estimate it aims to anticipate also additional customizations and spending needs, and to identify the flexibility needed and potential evolutions. Factoring in these arguments now projections might be looking more like the one below, with the increasingly shorter technology lifecycles and agile markets pushing additional reinvestments much earlier than before. 

DataMiner cost comparison example for an agile solution – perpetual vs yearly subscription
Cost comparison example for an agile solution – perpetual vs yearly subscription. On year-2 some additional licenses not initially foreseen had to be added, as not everything was known upfront. On year-4 a change in technology considerably changed the initial intended use of the software solution, in the perpetual model some of the licenses purchased in Year-1 and Year-2 became obsolete, resulting in their write-off, and triggered the purchase of a new set of licenses; yearly subscription cost had a lower impact because it meant subscribing to a different set of services and not renewing the subscription for the services no longer needed.

Where is the breakeven point?

From a pure cost analysis – not value –, in addition to the above, the breakeven point or range can be estimated by comparing the cost of perpetual licenses and corresponding support with the closest equivalent services we expect to use. Acknowledging that mid- and long-term projections have a highly speculative nature, as seen above, this approach might still the be suitable for static environments (ref image 1), a single-purpose or narrow application or project. 

A breakeven point or range is much harder to estimate for corporate-wide or strategic platforms supporting our organizations’ digital transformation plans, as we seek continuous value from those. From a cost perspective those business relations are commonly supported with Enterprise Agreements, and the challenge is rather to make sure usage and value match the contracted levels - over dimensioning and under-utilization are not exclusive to perpetual licenses. 

Summary

We all need to make cost projections to compare different commercial models and estimate breakeven ranges, this is a best effort to establish a cost indicator, not a reflection of long-term value or the actual reality. It needs to be properly weighted with: 

  • a clear vision of your long-term goals going beyond what’s known today
  • commercial models’ characteristics and their value throughout the platform’s lifespan  
  • business relation i.e. is the platform intended to be a strategic, enabling asset or a one-time point-solution

In general, a perpetual model is usually suited for predictable, more static solutions, intended to run for several years, without too many changes or evolutions expected. When uncertainty and flexibility are the key requirements, an agile usage-based service is normally the default choice.  

Finally, we also need to match the model with the company culture: if our organization is used to work with project budgets and tends for lower recurring charges, a usage-based service may not be the best fit, even when other indicators would suggest otherwise.