From Perpetual License to SaaS Delivery

Part 5 moved the backend toward a multi-tenant deployment — the architecture that makes hosted, cloud-style delivery efficient. But delivering software as a service is not only a technical change. It is a commercial one, and for most established ISVs the commercial change is the harder of the two, because it touches the contracts, the revenue model, and the installed base all at once. This part is about modernizing how the product is licensed and sold, in step with how it is built.

Two migrations, not one

It helps to be explicit that this is two migrations happening together. The technical migration is making the product subscription-capable and hosted: licensing that understands terms and renewals, entitlement that turns capabilities on and off per customer, and the multi-tenant backend that makes running it for many customers economic. The commercial migration is changing the business model: from a large one-time license sale plus annual maintenance to recurring subscription revenue, with everything that implies for packaging, sales, renewals, and how revenue is recognized.

These have to stay in step. Subscription pricing with no technical way to enforce entitlements is a promise the product can’t keep; a perfectly metered product with no commercial transition plan strands the existing base. The modernization succeeds when the technical capability and the commercial model advance together — which is why the licensing change belongs in the same incremental program as the architecture, not bolted on afterward.

What the product needs technically

The perpetual-license world asks little of the software commercially: sell a copy, perhaps check a license key, ship maintenance updates to whoever paid for them. Subscription delivery asks for more, and these capabilities are added the same incremental way as any other slice — behind stable interfaces, proven before they ship.

Subscription-aware licensing. The product has to grant access for a term, understand expiry and renewal, and behave correctly when a subscription lapses or upgrades — rather than the binary “licensed forever or not” of a perpetual key.

Entitlement and tiering. Capabilities need to be switchable per customer, so that a subscription tier maps to what a given customer can actually do in the product. This is what lets packaging evolve — editions, add-ons, seat counts — without shipping a different build to each customer.

Metering, where pricing is usage-based. If the model charges by consumption, the product has to measure that consumption reliably and feed it to billing. Metering is a correctness-sensitive slice: customers are charged on its output, so it earns the same parity scrutiny as any other.

Billing and renewal integration. Recurring revenue depends on the machinery that drives renewals, dunning, and changes to subscriptions — usually an integration rather than something built from scratch, but one the product’s entitlement layer has to talk to cleanly.

None of these require a rewrite. They are slices added to the modernizing product, sequenced like the rest.

The hard part: the installed base on perpetual licenses

The genuine difficulty is not the new customers — they can simply be sold a subscription. It is the existing base, who bought perpetual licenses and hold contractual rights you cannot unilaterally revoke. They own the right to run the version they bought. Many pay annual maintenance and regard that as the deal. Telling them the product is “subscription only now, please start paying monthly for what you already own” is how a vendor breaks trust and contracts in a single move, and hands the renewal conversation to a competitor.

So the commercial migration follows the same principle as the technical one: no forced cutover. You run both models in parallel. Perpetual customers keep their rights; new customers go onto subscription; and existing customers are invited across with a transition path that makes moving attractive rather than coerced — credit for maintenance already paid, access to hosted delivery and the current version, new capabilities available only on the subscription model, pricing that makes the math work in their favor. Customers convert as renewals come up and as the subscription’s value becomes clear, and perpetual licensing is retired only as the base voluntarily moves off it. This is the strangler fig applied to a business model: the new model grows up beside the old one and takes over gradually, with both supported during the overlap.

Why the incremental discipline transfers

The same method works on the commercial side for a specific reason. A forced license migration is a big-bang cutover in commercial clothing — a flag day where the whole base is meant to change at once — and it fails for the same reasons technical big-bangs do: the blast radius is the entire customer relationship, there is no gradual validation, and there is no clean way back if it goes wrong. Running both models in parallel makes the commercial transition incremental, validated customer by customer, and reversible in the sense that a customer who balks simply stays on their existing terms rather than being lost. The discipline that protects the codebase protects the revenue base too.

The payoff, honestly stated

Done well, this transition changes the shape of the business: recurring revenue is more predictable and typically valued more highly than one-time license sales, hosted delivery collapses the support cost of the version sprawl from Part 1, and the vendor finally controls the runtime instead of shipping into environments it can’t see. Those are real and they are the reason to do it. But they are earned over the transition, not on day one — recurring revenue ramps as the base converts, and support savings arrive only as old installs are actually retired. The financial case has to model the transition, not just the destination, which is exactly what Part 7 takes up.

Where subscription is the wrong model

Not every product or customer base should move to subscription, and pretending otherwise is how these transitions go wrong. Some customers — in regulated, air-gapped, or sovereignty-constrained environments — cannot accept hosted delivery at all and will keep needing an on-prem, licensed option indefinitely; for them, “SaaS or nothing” loses the account. Some markets still prefer ownership to subscription, and pushing too hard invites churn. And the revenue transition itself has a trough: recurring revenue starts small and grows, so a vendor moving off large one-time license sales can see revenue dip before it compounds — a real cash-flow consideration, not a footnote. The right design is usually a model that supports both delivery modes for as long as the market needs both, converting where it makes sense rather than mandating a single answer.

Where this leads

The product is now modernized not just technically but commercially — subscription capability added behind stable interfaces, and the base migrated without breaking the contracts they hold. Across six parts the program has touched architecture, front end, tenancy, and commercial model, all slice by slice. The question any leader will now ask is the one that decides whether the program gets funded: what does it cost, and what does it return? Part 7, ISV Modernization Cost & ROI, builds the financial case in the terms an ISV’s economics actually turn on.