From perpetual licensing to SaaS: the two steps to take

An editor selling perpetual licences and maintenance has an installed base that pays every year without needing to be reconquered. It also has a problem the market reminds them of with every investor approach: that revenue does not command the same valuation as subscription revenue.

Hence the temptation to treat the issue as an infrastructure project. The product is rehosted, made multi-tenant, and opened via a browser. It is easier for the editor to maintain, more comfortable for the customer, and it is real.

But this is not a transformation. It is a move. And a move does not justify asking a customer to pay more. The customer would only pay if incremental value is created.

What follows is the recipe we apply — and the key point is that none of its ingredients works alone.

The initial misconception

When a customer is told their software is moving to the CLOUD, they hear one thing: my vendor will cut its operating costs, and wants me to pay more for it.

They are not wrong. A change in hosting model alone is an improvement for the editor. It only becomes value for the customer if it is accompanied by everything else.

And everything else is not an added touch: it is what makes the conversion acceptable, hence possible, hence profitable. A migration programme that only covers the technical side leads to client-by-client negotiations, exhausting and doomed from the start.

The valley of death, in two sentences

A licence is recognised at signing; a subscription is spread out. The day you stop selling the former to sell the latter, you lose immediate revenue before building the latter. The dip is not an execution accident: it is arithmetic.

What needs to be modelled before starting — and few do — is not the rise of the subscription — it is the erosion of maintenance.

The gain is written; the loss remains in an assumption no one has articulated. That is where the nasty surprises lie — not because the model is wrong, but because it is only half complete.

The recipe: five ingredients, and none works alone

① The shared platform

The foundation. One version for everyone, continuous updates, industrialised operations. This is the prerequisite for everything else — and it is the only ingredient whose benefit is primarily for the editor. Hence the need for the next four.

② The rebuilt user experience

Not tweaked: rebuilt. This is the ingredient technical programmes sacrifice first, and it is the first thing the user sees.

A migration that changes nothing for those using the product fails by design: it mobilises neither internal teams, who do not grasp the effort, nor clients, who are asked to pay for a difference they do not perceive.

③ New features, new modules

Migration is the only time an editor can legitimately reopen their offering. It must be used to deliver what the installed base has been asking for years and the perpetual model made impossible — functions that require up-to-date data, continuous service, integration with external systems.

④ A catalogue of services, not just a product

This is the most underestimated ingredient, and it changes the nature of the offer. Alongside the software come:

The client no longer compares two prices. They compare a price to a price plus the cost centres they no longer bear: hosting, capex turned opex, IT resources freed for business projects, and a share of the security risk transferred.

A design detail that matters: some of these services are included and others optional. The distinction is not accounting — it signals what defines the offer and what is sold separately.

⑤ Artificial intelligence, in two places

This is the fifth ingredient, and it is what distinguishes a migration from a transformation.

An AI capability included as standard. It serves three ends at once, which is why it is so powerful: it justifies the price gap with the old maintenance contract; it instils credibility in the editor on the topic; and it creates appetite for the business modules that, in turn, are sold.

An editor of vertical ECM, speaking about its own migration.

Business AI modules in the catalogue. They do two different things that must be managed separately:

• Expand the product scope — automate what was entered manually, qualify what was sorted, extract what was copied. The benefit is measured in time saved and defended in price. This continues the transfer of workload: more work is removed from the client.
• Open new use cases — services the product did not deliver, not for lack of ambition, but because they required an interpretation capability that was not available at scale five years ago. This is where new revenue lines are created.

The first front defends and enhances the base. The second broadens it. A programme that only addresses the first improves a margin; a programme that addresses both changes a trajectory.

The change no one announces: you are no longer in the same business

This is what is written in serious migration plans, under internal risks, and omitted from press releases:

You move from being a software editor to a service provider.

These are not the same skills, organisation, or culture.

This is the deepest transformation in the programme, and the least visible from the outside. An editor that migrates without owning it ends up with contractual commitments it cannot meet.

Managing the migration

• Close the door before the exit

  The old model stops being offered to prospects well before the installed base is approached. Exceptions remain possible — written, tracked, approved, never negotiated case by case.

• Migrate at renewal, not convenience

  The migration moment for a client is their renewal: the only time renegotiation is natural.

• Provide an intermediate mode

  Subscription without delegated infrastructure, with part of the catalogue à la carte. Some clients want control; losing them costs more than accommodating them.

• Review variable pay

  Converting an installed base without touching commission structures means asking teams to earn less for working more.

The transition lasts several years; it is worth organising it. The migration plan and the commission plan must be designed together, or neither will work.

Three causes of failure, and they look alike

• A migration instead of a transformation

  The infrastructure changed, the user saw nothing. No one mobilised, inside or outside.

• Unmodelled erosion

  The cash-flow dip arrives when there is no margin left to absorb it. Yet it was arithmetic.

• No one aligned

  Neither the teams, whose objectives did not change; nor the sales force, whose remuneration penalises conversion; nor the clients, who were told about an architecture instead of a benefit.

A transformation rarely fails on technology. It fails when no one has an interest in its success.

The path is known

Nothing above is experimental. These steps have been taken at scale by editors with more constraints than most: products installed for twenty years, clients who asked for nothing, and a shareholder expecting quarterly results.

What distinguishes those who succeed is neither technology nor budget. It is treating migration as a corporate programme — its vision articulated, its economic model, its internal and external adoption plan, its incentives, and a governance that measures the dip instead of hoping it will be short.

And understanding that the ingredients do not add up: they multiply. Each without the next falls back:

• The platform without the experience

  No one is convinced — the user sees no change.

• The experience without the services

  The price is not justified — it is prettier, not more useful.

• The services without AI

  They do not stand out — everyone knows how to run an on-call roster.

• AI without the platform

  It cannot be deployed — there is no corpus, no elasticity, no path to the installed base.

This is a recipe. You do not succeed by doing only half of it.