Revvly
Docs
Guide

Some customers are on a plan you stopped selling. Keep them there, on purpose.

Create the version of a product as it was — last year’s prices, an older set of modules, a metering model you have since changed — and put a client on it. For customers who predate Revvly, or who negotiated the plan you were selling at the time.

When you need this

Two situations, one mechanism. You are moving a customer into Revvly who has been with you for years: the plan they bought no longer exists in your catalog, and typing today’s price would restate their whole history at a number they never paid. Or you are keeping a customer where they are: you raised prices, and this account stays on the old ones because that is what you agreed.

Both need the same thing — the older version has to exist in the catalog before a subscription can point at it. That is what this guide covers. If you only need to stop an existing customer moving forward when you publish a new version, you do not need any of this: that is already how Revvly behaves, and it is described in Versioning & grandfathering.

How it goes

  1. 1
    Author the version that used to exist
    Open the product in your catalog — a bundle, a module or a usage component — go to its version history and choose Add a past version, then give it the date it took effect. Revvly copies the version that was in force closest to that date, so you start from something real rather than a blank form. Edit the prices to what the plan actually cost then, and publish.
  2. 2
    It publishes as a past version, not the current offer
    A past version lands Archived: it holds a closed window in the plan’s history. Your current version is untouched, still what new customers get, still what your pricing pages describe. Nothing changes for anyone already subscribed.
  3. 3
    Put the client on it
    A new client: show retired plans in the picker and choose the version. An existing client: open Migrate and pick it from the list. Either way Revvly asks why, because a client on a plan you no longer sell is a decision someone made, and the next person to look needs to know it was deliberate.
  4. 4
    They bill at that version’s prices, indefinitely
    Not a discount, not an override — the subscription is pinned to that version, and its invoices, renewals and MRR all read from it. Publishing new versions of the plan will not move them. Only an explicit migration will.

What you can author a past version of

Everything in your catalog that carries a price. Each keeps its own version history, and each is authored the same way — open it in the catalog, go to version history, choose Add a past version. The button is on the version-history screen, not the editor.

Bundle
The packaged plan you sell — Growth, Pro. A past version carries the base price it charged then, per currency and per region. This is the usual one: most legacy contracts are “they are on the old Growth price”.
Module
An individual product a client can hold on its own. A past version carries its price and the usage components attached to it, so a plan whose metering you have since restructured can be reconstructed as it was, not only repriced.
Usage component
What you meter and how. A past version carries its rates and its structure — tier boundaries, included units, the metering model — so a plan you have since restructured can be reconstructed as it was, not merely repriced.

Reconstructing a whole history

A customer who has been with you since 2023 was probably not on one plan the entire time. When you create their subscription you can set the start date back to when they actually signed and add each plan change since — the date it happened and what they moved to.

Revvly then treats their history as a sequence of periods rather than a single current plan. If you also ask it to backfill the invoices for those elapsed terms, each invoice is billed at the plan that was in force for its own period — the 2023 months at the 2023 price, under the 2023 plan’s name — and the revenue reports show the change where it actually happened, not all at once today.

One client, several plans
  1. Start date
    Signed on the first plan
    Those periods bill at that plan’s price and name.
  2. Each plan change
    Moved to the next plan
    Entered oldest first, each in the past.
  3. Latest change
    Current plan
    Later periods bill at its price.
Each backfilled invoice bills at the plan in force for its own period.
iChanges must be entered oldest first, each after the subscription started and each in the past. Revvly checks the whole list before writing any of it, so a mistake in the third step does not leave you with the first two recorded.

What you will see afterwards

On the subscription
Legacy plan, with the reason you gave — rather than a warning that the pin is out of date. The client is where you put them, and the page says so.
Plan history
The periods this client spent on each plan, with dates and the price each period billed. A change queued for their next renewal is shown as pending rather than as something already applied.
Outdated pins
They are not listed. That page is for subscriptions left behind by accident; a deliberate one would only be noise there — and it is one bulk action away from being repriced. Turn on Show grandfathered to see them deliberately.
On the product
Version history lists every version oldest first by when it took effect, so the one you authored for 2023 sits at the start of the timeline even though you created it today.

Rules worth knowing

Version numbers are the order you created them, not the order they applied
A version you author today for 2023 gets the next free number — so it can be your highest-numbered version while being the oldest in time. Read the dates. Every screen orders by the window a version was in force for, not by its number.
A past version has to take effect before your current one
Otherwise it would be the version in force today, while being marked as retired — and imports covering this month would attach to it. Revvly refuses that date and tells you which version is in the way.
A reason is always required
It is what separates a client you deliberately kept on an old plan from a subscription nobody got round to updating. The first is a contract to honour; the second is work to do. Revvly shows the reason on the client and leaves them out of the outdated-pins list.
Recording history moves no money
Reconstructing what a client used to be on writes history, not charges. It raises no invoice and adjusts nothing. Invoices for past periods come from backfilling them, which is a separate, explicit choice.

Undoing it

To move a grandfathered client onto your current pricing, migrate them like anyone else — choose the current version and a timing. Migrating at the next renewal is the usual choice: it avoids a mid-cycle adjustment invoice and the customer sees the change at a boundary they expect. Their history stays intact either way; the periods they spent on the old plan do not disappear when they leave it.

Next up