Version Management Across Subscriber Orgs, and Why ISVs Still Do It by Hand

Version management across subscriber orgs means knowing, at any moment, which version of your managed package each customer is running, and being able to move them off it. Salesforce hands ISVs the raw materials for that job: the License Management App, the Subscriber Support Console, push upgrades. What it does not hand you is a running inventory. So most ISVs keep one by hand, in a spreadsheet, and pay for it in support hours.

What does version management across subscriber orgs actually mean?

It is three separate jobs collapsed into one phrase:

• Inventory. Which version is installed in each subscriber org, right now.
• Spread. How many distinct versions are live at once, and how far the oldest has drifted from current.
• Movement. Your ability to take a named set of orgs from version A to version B on a schedule you choose.

Most teams have a rough answer to the first, no answer to the second, and a manual process for the third.

Why does the version matrix decide ISV support cost?

Because every ticket opens with a question the ticket cannot answer. Before anyone reproduces a bug, someone has to establish which build the customer is on, whether the fix already shipped, and whether the behaviour is a defect or a version gap. Do that a hundred times a month and it stops being a nuisance and starts being headcount.

The spread is what compounds. Two live versions is a branch. Six is a support matrix, and every incoming fix has to be assessed against all six before you can promise anything. Collapsing that spread is the highest-leverage move an ISV support function can make, and it is why push upgrades exist in the first place.

How do you find out which version a subscriber is running?

Four routes, each with a catch:

• The License Management App. Installed in your partner business org, the LMA creates a lead and a licence record on every install, and carries Package and Package Version objects covering each 1GP or 2GP package you have listed on AppExchange. This is your system of record. Start here.
• The Subscriber Support Console. Precise, but it needs the customer to grant login access first, which makes it a per-incident tool rather than an inventory.
• Ask the admin. Setup, Installed Packages, read the version number. Fine once. Useless across two hundred orgs.
• Tooling API. Worth knowing that InstalledSubscriberPackageVersion is deprecated and slated for removal, so do not build a reporting layer on it.

None of these is a dashboard. That is the gap, and why the spreadsheet exists.

Why do ISVs still do this by hand?

Not laziness. The data sits in three systems that do not talk to each other: licences in the partner business org, package versions in the Dev Hub, and the actual release history in Git and your pipeline. Joining them is a small internal integration project that never wins a sprint against customer-facing work. So it stays a spreadsheet, someone updates it after each release, and by the third quarter nobody quite trusts it.

What does automating version management look like?

1. Treat the LMA as the source of truth for who has what, and sync it on a schedule instead of reading it ad hoc.
2. Join licence records to your release history, so every subscriber row carries the installed version, its release date, and what changed between it and current.
3. Compute the spread as a number you watch weekly: distinct live versions, and the age of the oldest.
4. Set a support floor, the oldest version you will still fix bugs on, and make it visible to support rather than only to engineering.
5. Group orgs into upgrade waves: your own orgs, then customer sandboxes, then friendly customers, then everyone else.
6. Make "which version" an automatically populated field on the ticket, not a question a support engineer has to ask.

Note what is not on that list: anything your customers have to learn. This is an internal reporting problem wearing a packaging problem as a disguise.

When should you push an upgrade instead of asking?

Push upgrades move subscriber orgs to a new version without the customer installing anything, and you choose which orgs, which version and when. The constraints worth planning around:

• Only packages that have passed AppExchange security review are eligible.
• For 2GP there is no point-and-click path. Push upgrades run through the CLI or the SOAP API.
• Stagger them. Salesforce's own best-practice guidance is to test in your own orgs, then customer sandboxes, then a small production batch, before the rest of the book, and to avoid financial close periods and the weeks right after a major Salesforce release.
• Since Summer '26 you can bound the attempt. A PushUpgradeCustomizationRepository record in your 1GP packaging org or 2GP Dev Hub sets an expiration window, after which Salesforce stops retrying.

A push is a deployment into somebody else's production org. Treat it like one: same review, same rollback plan, same change record.

Where does the tooling stand?

Most Salesforce DevOps platforms, Copado, Gearset, AutoRABIT, Flosum and the rest, are built around org-to-org and Git-backed delivery, and they do that well. Package delivery for ISVs has historically been the thinner half of the category. That is the half we built Serpent around: native 1GP, 2GP and managed-package workflows, cross-package dependency resolution, version management across subscriber orgs and AppExchange release workflows, on every plan including the free one.

FAQ

Can I see every subscriber's package version in one place by default?

No. The LMA in your partner business org holds licence and package version records, but turning that into a live inventory joined to your release history is work you have to do.

Are push upgrades safe for major versions?

They carry more risk than patches, because a major version can change behaviour a subscriber depends on. Test in your own orgs and in customer sandboxes first, then roll out in small batches.

How many live versions should an ISV support?

Salesforce sets no number. Pick a support floor you can actually staff, publish it to customers, and measure the spread against it.

Does the LMA cover both 1GP and 2GP?

Yes. Its Package and Package Version objects carry details for each 1GP or 2GP package and version you have listed on AppExchange.

Can I still query InstalledSubscriberPackageVersion?

It exists from API version 41.0, but Salesforce has marked it deprecated and slated for removal. Do not make it a dependency.

Version management across subscriber orgs is unglamorous, invisible to customers, and quietly decides what your support function costs. It deserves a pipeline, not a spreadsheet.