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.
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.
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.
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.
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:
| 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 |
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.
A package audit takes days; the incident it prevents takes weeks to clean up. Talk to Vantage Point about a Salesforce package audit.
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.
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.
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.
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.
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.
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?