The software industry has spent a decade moving its catalog from perpetual licenses to subscriptions. Productivity suites, creative tools, and self-hosted enterprise platforms have all shifted, and the reasons are commercial rather than technical: recurring revenue is more predictable, investors value it more highly, and access that ends when payment stops keeps pricing power with the vendor. None of that tells you which model is cheaper for your workload. The vendor's preferred model is rarely the one that minimises your cost.

The right answer is workload-specific, and most large estates run a mix. Here is how the two models actually differ, where each one wins, and the costs that hide in both.

What each model actually is

A perpetual license is a one-time purchase of the right to run a specific version of the software indefinitely. It is usually paired with an annual maintenance fee, commonly 18 to 22% of the license value, that buys support and version upgrades. Stop paying maintenance and the software keeps running; you lose patches and the right to new versions. In accounting terms it is a capital asset you own.

A subscription is a recurring fee that bundles the right to use, support, and upgrades into one payment. Everyone runs the current version, updates arrive automatically, and there is no maintenance contract to negotiate. Stop paying and access ends. In accounting terms it is an operating cost you rent.

The structural difference is ownership versus access. Perpetual hands you a durable asset and the option to walk away from maintenance. Subscription keeps the software current but ties its use to continuous payment. That single difference drives everything else: the cost curve, the exit options, the audit exposure, and the accounting treatment.

The total cost crossover

Subscription almost always looks cheaper at the start, because it spreads the cost that perpetual demands upfront. Over a long enough horizon that reverses. For a stable, long-lived workload, a perpetual license plus maintenance is frequently cheaper than the equivalent subscription across a decade, and the crossover point commonly lands somewhere around year five.

Three numbers decide where that crossover falls: the maintenance percentage on the perpetual side, the annual subscription price, and the subscription's built-in annual uplift. That last one matters most. Subscriptions carry yearly increases that compound, so a rate that looks modest at signing raises the price materially over the life of the workload, while perpetual maintenance rises from a fixed base. Model all three before committing, and price the subscription on its capped, escalated figure, never on the year-one quote.

When perpetual still wins

Perpetual is the stronger choice when the workload is stable, long-lived, and does not depend on a stream of new features. A back-office system that will run largely unchanged for years does not benefit from paying continuously for upgrades it will not deploy. Perpetual also suits organisations with the capital to absorb the upfront cost, the infrastructure to self-host, and, in regulated industries, the requirement to keep data on their own systems with direct control over retention and access. The optionality is worth money: for a frozen version, dropping vendor maintenance and moving to alternative support can cut ongoing cost substantially while the license keeps running, and subscription removes that option entirely.

When subscription is the right call

Subscription is the better fit when usage is uncertain or short-lived, when the software must stay current, and when cash flow matters more than long-run cost. Security tooling and fast-moving categories such as AI are the clearest cases: a product whose value depends on the latest threat data or the newest model is a false economy as a frozen perpetual version. Subscription also wins when the workload might be retired early, when the organisation may switch vendors, and when it wants to avoid the hardware, IT, and security overhead of self-hosting, all of which the subscription price absorbs. For genuinely cloud-native software there is often no perpetual option at all, and the decision becomes which term and commitment to take rather than which model.

The hidden costs on both sides

Both models carry costs that do not appear on the sticker.

On the perpetual side, the maintenance contract is effectively non-cancellable if you want support and patches, and lapsing it often triggers a reinstatement fee to rejoin later. The larger trap is end of life: every perpetual product eventually stops being sold and supported, and the vendor's next generation frequently arrives as a full re-purchase rather than an upgrade. The upfront saving becomes a long-term liability if that cycle is not modelled. Self-hosting adds the hardware, staff, and security infrastructure the invoice does not show.

On the subscription side, the uncapped annual uplift is the main risk, which is why the negotiation priority is a cap tied to a fixed figure or an inflation index. Data portability is the second: cancel, and access to cloud-stored data depends entirely on the contract's export rights and retention window, so a well-drafted agreement defines the export format and timeframe in advance. The third is quiet growth. Because each seat or module is a small recurring charge rather than a large approval, subscription estates drift upward through seat and tier creep unless someone governs them, which is the discipline behind our enterprise guide to reducing Microsoft 365 licensing costs and every other cost review in this area.

Most estates run a mix

The mistake is standardising on one model across all software. Buy perpetual for stable, long-lived tools where you can absorb the upfront cost and control the version, and subscribe to the services that must stay current, such as security and AI. The perpetual question is now mostly live for on-premises and self-hosted software, because cloud-delivered products rarely offer a perpetual equivalent. Once a workload is on subscription, the cost stops drifting through model choice and starts drifting through seat growth and tier changes, which is where a licensing review keeps it in check. Auditing the estate once a year and retiring what no longer earns its place is one of the simplest ways to cut software spend, and the full framework is in our enterprise guide to software licensing management.

Frequently asked questions

What is the difference between a perpetual and a subscription license?

A perpetual license is a one-time purchase to use a specific version indefinitely, usually with an annual maintenance fee (commonly 18 to 22% of the license) for support and upgrades. A subscription is a recurring fee that bundles use, support, and upgrades; access ends when payment stops. Perpetual is an owned asset; subscription is a rented service.

Is perpetual or subscription licensing cheaper?

It depends on the time horizon. Subscription is cheaper upfront and for short-lived or uncertain usage. Perpetual is frequently cheaper over a long horizon for stable workloads, with the crossover often around year five. The subscription's compounding annual uplift is what turns it more expensive over time.

Why are vendors moving to subscription?

The reasons are commercial. Recurring revenue is predictable and valued more highly by investors, and because access ends when payment stops, the vendor retains pricing power for the life of the workload. That benefits the vendor and only benefits the buyer when the software keeps delivering value worth the recurring cost.

What are the hidden costs of each model?

Perpetual carries non-cancellable maintenance, reinstatement fees, end-of-life re-purchases, and self-hosting infrastructure. Subscription carries compounding price uplifts, data export and lock-in costs on exit, and seat or module creep that grows the bill without a single large approval.

Should an enterprise standardise on one model?

No. Most large estates run a mix: perpetual for stable, long-lived tools, subscription for services that must stay current. The model should follow the workload, and the estate should be audited annually to retire what no longer earns its place.