Talk to an Expert
[ When the model has to change ]

Pricing model transition
for B2B software.

Model transitions don’t fail on the new pricing. They fail on the existing customer base — and that’s where the work actually lives.

[ Plain answer ]
What is a pricing model transition in B2B software?

A pricing model transition is a deliberate shift from one licensing structure (perpetual, per-seat, per-transaction, consumption, hybrid) to another — designed to capture how customers actually realize value and how the product is now being used, without breaking existing ARR or renewal cadence. The transition lives or dies on the existing customer base: a blanket cutover date is a churn plan, not a transition plan.

Three signs the model is the unit of work, not the price level:

  • Customer expansion is happening, but the meter doesn’t capture it — growth shows up in usage, not in invoiced revenue.
  • Sales rooms keep negotiating around the published metric, not against it — deal-desk side letters and bespoke calculations have become the operative pricing.
  • Renewals require structural carve-outs the original license can’t accommodate — legacy holds, custom packages, and amended terms are the rule, not the exception.
The risk

Model transitions break on the customers you already have, not on the customers you want next. The transition has to serve both — or the new model breaks the base it was meant to grow.

The transitions

Four transitions where
the architecture has to flip.

01

Perpetual
to SaaS.

You’re moving from perpetual licenses to subscription. Every legacy customer needs an individual transition model, not a blanket cutover date. The migration is a portfolio of cases, not a milestone.

02

Open-source
to commercial.

How do open-source software companies transition from terms-of-service enforcement to commercial pricing? Without alienating the community that built the moat.

03

Services
to platform.

You’re a services firm launching a SaaS platform that cannibalizes billable hours. How do you price it? Pricing the platform without killing the services revenue is the real question.

04

Seats
to consumption.

A specific transition shape with its own playbook. Adding a usage metric to a seat-based product changes the commercial dynamic for every existing customer.

Chris Mele, CEO of Software Pricing Partners
About the expert

Chris Mele

CEO, Software Pricing Partners

Ranked #1 on OpenView’s list of B2B SaaS pricing experts. Chris leads every model-transition engagement, surrounded by a team that has held CFO, CPO, and CIO seats inside software companies. You get the pricing architect — not their associate.

LevelSetter runs the pricing infrastructure end-to-end so the experts focus on the calls only humans can make. It scales practitioner judgment — it doesn’t replace it.

Read more about Chris →
The discipline

Transitions are designed
customer-by-customer.

The failure mode in every pricing model transition is the same: a blanket cutover. “All customers move to SaaS by Q4” is not a transition plan; it is a churn plan dressed up in a project timeline.

[ Discipline 01 ]

Migration as a portfolio, not a milestone.

Real transitions are modeled customer-by-customer against the variables that actually matter: contract value, term remaining, renewal date, expansion path, ARR at risk. The migration becomes a portfolio of individual cases, not a single milestone.

[ Discipline 02 ]

Cohorts before timelines.

Before any date gets set, the existing base gets sorted into cohorts that share behavior — enterprise multi-year vs. mid-market annual, expansion-track vs. flat, healthy vs. at-risk. Each cohort gets its own transition path. The portfolio gets sequenced; nobody gets force-marched.

[ Discipline 03 ]

Instrumentation is non-negotiable.

The team instruments each cohort through the transition window via LevelSetter so actual behavior is watched in real time — not just at the renewal post-mortem. Cohorts that diverge from their designed path get re-cut before the cliff, not after.

Underneath all three disciplines is a single thesis: model transitions don’t break on the new pricing. They break on the existing customers — which means the existing customers are the design constraint, not the audience for an announcement.

The engagement

Existing customers,
or new pricing?

Legacy Software Monetization

The right entry when the existing base is the design constraint — perpetual to SaaS, on-prem to hosted, open-source to commercial. Cohort-by-cohort transition path, instrumented through the renewal cycle, with explicit off-ramps for customers held on legacy pricing.

See the engagement →

New B2B SaaS Product Pricing

The right entry when the pricing decision is forward-looking — a new product, a new module on an existing product, or a new metric added alongside an existing one. Architecture-first design (licensing metric, packaging boundaries, price level) so the new SKU lands on a foundation that will hold for three years, not three quarters.

See the engagement →

Frequently asked questions

It depends almost entirely on the contract terms of the existing base, not on the pace the team wants to move at. If the perpetual cohort is mostly on annual maintenance contracts, the transition window can be 12–18 months. If multi-year perpetual contracts are common, the window stretches to 3–5 years because the last contracts to renew set the natural finish line. The mistake is picking a cutover date and trying to bend the contract terms around it; the right pattern is to design transition paths against the actual renewal cadence and accept the timeline the base imposes.
No. Holding customers on legacy pricing is a transition tactic, not a permanent state. The right pattern is to define the hold with explicit boundaries: a term-end date, an upgrade trigger (new module purchased, seat-count threshold crossed), or a sunset window. An indefinite hold is usually a sign that the new pricing has a problem the legacy cohort already worked out — worth investigating before treating it as a customer-retention concession.
They stay on the existing contract through term, with the transition path designed against the renewal date. The mistake is trying to force a mid-term migration with concessions and side letters — that almost always costs more in negotiated ARR than waiting for the natural renewal point. The exception is when the customer is asking for the new pricing model (usually because expansion is bottlenecked by the current metric); then a mid-term amendment is the right move because the customer is pulling the change, not absorbing it.
The transition has to draw the commercial boundary at functionality that genuinely serves a different audience — enterprise compliance, multi-tenancy, governance, scale — not at features the community already relies on. The community moat exists because the open core does what individual developers and small teams need; pulling those features into the paid edition is what triggers pushback. The right pattern names the commercial boundary at the layer where audience changes (developer to platform operator, individual to enterprise), and stays explicit about what stays open in perpetuity.
Two questions decide it. First, is implementation actually different work, or is it the platform doing what services used to do manually? If it’s genuinely different work, it stays a separate line and the platform price excludes it. Second, what does the buyer expect the platform to come with? If buyers in the category routinely pay for platform plus services as separate lines, that’s the precedent; if the category bundles, the platform price needs to absorb implementation or buyers will read it as expensive. The boundary belongs at the line where the value driver changes, not where the cost driver does.

The transition succeeds when the existing base survives it.

If you’re flipping the pricing model, the existing customers are the design constraint.

Talk to a Pricing Expert See Legacy Monetization