Own or rent? Choosing between one-time licences and subscriptions

The software industry defaulted to subscriptions roughly fifteen years ago, and it has been treated as settled ever since. Recurring revenue is easier to forecast for the vendor, easier to sell against a small budget line, and easier to cancel if it turns out to be the wrong fit. All of that is true, and none of it tells you which model is actually cheaper, or safer, for the business paying the bill.

A one-time licence plus an annual maintenance contract (AMC) has a large cost in year one, the licence fee, and a smaller, flatter cost every year after, covering support, fixes and updates. A subscription has a small cost in year one and the same cost every year after that, indefinitely, for as long as the software is in use.

Plot those two lines and there is almost always a crossover point: a year at which the cumulative cost of the subscription overtakes the cumulative cost of the licence-plus-AMC. Where that crossover sits depends entirely on the numbers involved, the size of the licence fee relative to the subscription price, and the AMC rate relative to the subscription rate. Run your own numbers with your actual quotes rather than trusting a rule of thumb; the shape of the curve matters more than any specific year.

What the crossover chart leaves out is the line underneath it: switching costs. A subscription that becomes expensive, or whose vendor changes terms unfavourably, is easy to cancel on paper and often very hard to leave in practice, the data migration, the retraining, the months of running two systems in parallel. A one-time licence has the opposite problem in reverse: you're more exposed to the choice being wrong on day one, because you've already paid for it. Neither model removes switching cost. They just place it at a different point in the relationship, subscriptions defer it to the exit, licences front-load it to the decision.

This isn't a case against subscriptions. Some categories of software are subscriptions for good reason, and forcing them into a one-time-licence shape would be worse for the buyer, not better.

Living services, anything whose value depends on staying current rather than staying the same, fit a subscription naturally. Threat intelligence, market data feeds, anything where last year's version is materially worse than this year's, not just older. You are not really buying software in these cases; you are buying an ongoing service that happens to be delivered through software, and paying for it continuously matches how the value actually arrives.

Short-horizon needs are the second honest case. If you genuinely don't know whether you'll need a system in eighteen months, a pilot, a seasonal operation, a team that might not exist next year, a subscription's low commitment is the correct trade, not a workaround.

It's worth being specific here rather than abstract: in our own product registry, the Financial Dashboard is sold as a subscription while the rest of the suite is sold as a one-time licence plus AMC. That's not an inconsistency; dashboards live and die by the currency of the data feeding them, which puts them squarely in the living-service category above. Everything else in the registry is a system of record, which is a different kind of software with a different economic shape, covered next.

A system of record, the software that holds your customer data, your inventory, your payroll, the numbers that other systems and other decisions depend on, behaves differently to a living service. Its value doesn't come from being updated constantly; it comes from being correct, available, and unlikely to disappear from under you.

For that category, three things tend to favour ownership. First, time horizon: if you expect to run the system for five or ten years, the total cost tends to favour the licence-plus-AMC model once you're past the crossover point discussed above, the earlier and lower that crossover sits, the stronger the case. Second, budgeting: a one-time licence fee and a fixed annual maintenance figure are two numbers you can put in a capital plan and an operating plan respectively. A subscription is a single number that can move at every renewal, at the vendor's discretion, which is harder to plan five years of budget around. Third, and this is the one vendors talk about least, leverage at renewal. Under a subscription, non-renewal generally means losing access to the software outright. Under a one-time licence with an AMC, non-renewal typically means losing updates and support, while the system you already paid for keeps running. That difference in what happens if you walk away changes who holds the leverage in the renewal conversation, well before either party has to test it.

Six questions, worth answering honestly before the demo rather than during it.

1. 1.Is this a system of record, or a living service? If the value is in staying current rather than staying correct, lean subscription. If the value is in being reliable and available, lean ownership.
2. 2.What's your real time horizon? Not the horizon you'd like to have, the one you'd bet the budget on. Under two or three years, subscription flexibility usually wins. Five-plus years, run the crossover math.
3. 3.What does your own crossover chart say? Get the actual licence fee, the actual AMC rate, and the actual subscription price, and plot the cumulative cost yourself. Don't take anyone's word for where the lines cross, including ours.
4. 4.What happens on day one of non-renewal, under each model? Ask the vendor directly. If they're vague about what a lapsed subscription costs you versus a lapsed AMC, that vagueness is itself information.
5. 5.How would a migration actually go, under each model? Data export terms, format, and cost should be part of the decision before signature, not a discovery you make during a difficult exit.
6. 6.Who is accountable for the answer to all of the above changing? Pricing, terms and vendor circumstances shift over a decade. Ask what recourse you have if they do, under a subscription and under a licence, before you need it.

None of this is a verdict in favour of one model over the other. It's a way of making sure the model you end up on was chosen for the software in front of you, rather than inherited from whatever the industry happened to default to the year you were shopping.