Somewhere in nearly every long-running Salesforce org there is an AppExchange package installed three years ago and never touched since. The admin who installed it may be gone. The version number means nothing to anyone. And then a compliance review, a vendor support ticket, or a security audit asks the uncomfortable question: "which version of this package are we running — and is it current?"
Managed package drift is quiet. The package keeps working, so nobody looks at it — until a vendor deprecates the version you are on, a security advisory names it, or an upgrade to one package breaks another. A lightweight version audit turns that reactive scramble into a routine.
This guide shows how to inventory installed package versions, gap-assess what an upgrade changes, and sequence upgrades safely — sandbox first, approval trail intact.
Quick Answer
Audit managed packages by comparing each installed version (Setup → Installed Packages) against the vendor's current release on the AppExchange, then read the release notes for the gap. Flag security fixes and deprecations as urgent, test every upgrade in a sandbox against your customizations, and schedule production upgrades with a rollback note. Vantage Point runs package audits as part of org health checks so upgrade decisions are documented rather than improvised.
Key Takeaways (TL;DR)
- Inventory first: Setup → Installed Packages lists every managed package, its publisher, and the exact version installed.
- Compare to current: the AppExchange listing and vendor release notes show the latest version and what changed since yours.
- Not every gap is urgent: security advisories and deprecations are; cosmetic feature additions usually are not.
- Sandbox first, always: upgrades can alter components your flows, reports, and integrations depend on.
- Document the decision: an approval trail for each upgrade (or deliberate deferral) keeps auditors and successors sane.
Why do managed package versions drift?
Managed packages upgrade only when someone upgrades them. Unlike Salesforce's own releases, which arrive on a fixed schedule, a package stays on its installed version until an admin deliberately installs a newer one. Vendors ship improvements continuously; orgs absorb them sporadically. Over a few years, the gap between "installed" and "current" can span dozens of releases — including fixes, security patches, and platform-compatibility updates you never saw.
The risk concentrates in suites: organizations often run several products from one vendor (a document generation suite, a commission suite, a CLM stack), and those products depend on each other's versions. Upgrading one without checking the rest is how a routine Tuesday becomes an incident.
How do you inventory installed package versions?
In Lightning Experience, open Setup → Apps → Packaging → Installed Packages. For each managed package, record four fields in a simple spreadsheet: package name, publisher, installed version number, and installation date. This takes an afternoon even in a package-heavy org, and it only has to be built once — after that it is maintenance.
While you are there, note which packages are actually in use. An installed package nobody uses is a candidate for removal rather than upgrade, which is a different (and cleaner) project.
How do you find the current version and what changed?
Each package's AppExchange listing shows the latest published version. The vendor's release notes — usually linked from the listing or the vendor's support site — are the substance of the audit: read every release between your installed version and current. You are looking for four categories of change:
- Security fixes — always prioritize these.
- Deprecations and end-of-support notices — a version the vendor no longer supports is a liability even if it still runs.
- Platform-compatibility updates — releases that keep the package working with new Salesforce API versions and UI changes.
- Features and behavior changes — improvements you may want, and behavior differences your users or integrations may notice.
Which upgrades are urgent, and which can wait?
| Signal | Urgency | Action |
|---|---|---|
| Vendor security advisory names your version | Urgent | Schedule the sandbox upgrade this sprint |
| Your version is deprecated or out of support | High | Plan the upgrade path; check for required intermediate versions |
| Package breaks or loses functionality after a Salesforce release | High | Upgrade to the vendor's compatibility release |
| A needed feature exists only in a newer version | Medium | Bundle with the next planned release cycle |
| Routine minor releases, no gaps you care about | Low | Note in the audit; revisit quarterly |
What does a safe upgrade sequence look like?
- Get the install link from the vendor or listing — upgrades install over the existing package; they do not require uninstalling.
- Upgrade a full or partial sandbox first. Never test an upgrade in production for the first time.
- Regression-test what touches the package: the flows, Apex, page layouts, reports, and integrations that reference its components. This is where suites bite — check every product from the same vendor, not just the one you upgraded.
- Check for required intermediate versions. Some vendors require stepping through specific releases rather than jumping straight to current.
- Get sign-off where required. In regulated environments, compliance approval for changes that touch document generation, communications, or client data is part of the sequence, not an obstacle to it.
- Upgrade production in a low-traffic window with the rollback path written down — typically reinstalling the prior version's package link if the vendor still publishes it.
- Validate post-upgrade: run the package's core user journeys and confirm version numbers landed as expected.
What should businesses do next?
- Build the one-time inventory from Installed Packages — name, publisher, version, date.
- Compare every package against its current AppExchange version and flag the gaps by urgency.
- Schedule sandbox upgrades for anything security- or deprecation-related first.
- Add a quarterly package review to the admin calendar so drift never compounds again.
- Record each decision — upgraded, deferred, or retired — where an auditor can find it.
How Vantage Point Helps
Vantage Point audits installed AppExchange packages as part of org health checks and ongoing administration — version inventories, gap analysis against vendor release notes, sandbox-first upgrades, and the documentation trail auditors ask for. Senior consultants only — no junior handoffs; the experts you meet are the experts who deliver. Our Salesforce technology team handles the upgrades, and our managed services team keeps the version inventory current quarter after quarter.
When Did You Last Check Your Package Versions?
A package audit takes days; the incident it prevents takes weeks to clean up. Talk to Vantage Point about a Salesforce package audit.
Frequently Asked Questions
Where do I see which version of a managed package is installed?
In Lightning Experience, go to Setup → Apps → Packaging → Installed Packages. The list shows every managed package in the org with its publisher and installed version number — the starting point for any version audit.
Do Salesforce managed packages upgrade automatically?
Generally no. Most managed packages stay on the installed version until an administrator installs a newer one. Some vendors offer push upgrades for specific releases, but you should not assume a package is current just because it is working.
Do I need to uninstall a managed package before upgrading it?
No. Upgrades install over the existing package and preserve its data and configuration. Uninstalling is a separate, more destructive operation used when retiring a package entirely — not part of a normal upgrade.
Should every package upgrade be tested in a sandbox first?
Yes. Upgrades can change components your flows, reports, page layouts, and integrations reference. Test the upgrade in a sandbox, regression-test everything that touches the package — including other products from the same vendor — and only then schedule production.
How do I know if I can skip versions and jump to the latest release?
Check the vendor's release notes and upgrade documentation. Most packages support jumping to current, but some require installing specific intermediate versions in order. When the notes are unclear, ask the vendor's support before attempting the jump in production.
What should I document for a compliance or security audit of installed packages?
Keep the version inventory (package, publisher, version, date), the comparison against current releases, the approval trail for each upgrade or deliberate deferral, and the sandbox test evidence. That package answers the auditor's core question: who decided this version was acceptable, and when?
