Open Setup, then Installed Packages, in a Salesforce org that has been live for a decade. You will typically find somewhere between fifteen and thirty packages listed. Ask the IT director what half of them do, and the honest answer is usually “not sure.” Ask who owns the license for each one, and the answer gets quieter still.
That is not a hypothetical. It is the normal state of a mature higher ed Salesforce instance that has passed through several admins, at least one systems integrator, and a string of point projects that solved a problem in a given semester and were never revisited. Financial aid piloted a survey tool once. Admissions bought a text messaging connector for a single recruiting cycle. A departed vendor left behind an integration package that nobody turned off because nobody was sure what would break if they did.
The AppExchange marketplace has grown fast enough that this kind of accumulation is easy to explain and easy to ignore. As of May 2025, the AppExchange listed close to 6,000 apps, with more than 800 added and developer count up over 15% in the preceding twelve months, according to sfapps.info’s State of AppExchange market data. More apps on the market means more apps get installed for narrow, short-lived reasons, and fewer of them get uninstalled when the reason expires.
Technical Debt Is Not an Abstraction, It Shows Up on a Budget Line
Salesforce admins are already telling researchers that this is a problem they cannot keep up with. In a Salesforce Ben survey of Salesforce admins, 56.3% named managing technical debt as the hardest part of their job, and close to a third rated their own org’s technical debt as high or very high. Deloitte’s estimate, cited in the same reporting, puts technical debt at 21% to 40% of total IT spending across organizations generally. Salesforce-specific sprawl, unused packages, orphaned integrations, license seats nobody is using, is one of the more visible and most fixable slices of that spending.
Higher ed IT departments are absorbing this at the same time their budgets are shrinking. EDUCAUSE’s spring 2025 QuickPoll on technology budgets and staffing found that 42% of higher ed IT respondents expected a budget decrease for the 2025-2026 academic year, with a median cut of 8%. A lean team facing an 8% reduction has no room to keep paying for licenses tied to a system nobody remembers requesting.
None of this requires a breach or an outage to matter. It shows up quietly, in a renewal invoice for a package three people use, in an upgrade that fails because a five-year-old managed package was never updated for the current API version, in a security review that cannot say with confidence what student or financial data a given integration can touch.
A Four-Question Audit for Every Installed Package
Most IT teams have never actually inventoried what is installed in their org against what is still needed. The fix does not require a Salesforce admin on staff, and it does not require a rebuild. It requires a list and four honest questions asked against every row on it.
Start with the list itself. Setup > Installed Packages will show every managed and unmanaged package currently in the org, along with the publisher and version. Cross-reference that against Setup > Connected Apps for anything authenticating in from outside, since not every integration arrives through the AppExchange proper. For a ten-year-old org, this alone is often the first time anyone has seen the full picture in one place.
For each package on the list, ask:
Is it still used? Check login history for the associated user, or look at whether the objects and fields it created still have recent record activity. A package with zero touches in the last year is a candidate for removal, not renewal.
Is it still supported? Look up the publisher on the AppExchange listing itself. Publishers get acquired, discontinue products, or stop pushing updates. An unsupported package sitting on an old API version is a liability the day Salesforce deprecates that version.
Who owns the license, and what does it cost? Someone is paying for every seat-based or usage-based package, whether that is a per-user fee, a platform fee, or a bundled cost buried in a larger contract. If nobody in the current IT or finance team can name the owner, that is itself a finding.
What data does it touch, and what can it do with that access? Every installed package requests a set of permissions on install, often broader than the feature actually needs. For an office holding FERPA-protected student records and financial aid data, an integration with standing write access to contact or opportunity records that nobody is monitoring is exposure, whether or not it is ever misused.
Why This Is a Security and Upgrade Problem, Not Just a Licensing One
The license cost of orphaned packages is the easiest part to quantify, and often the smallest part of the real exposure. Every installed package is also a piece of code running inside the org with a defined set of API and data permissions, maintained by a third party whose security practices the institution has no visibility into. An unused package is not a dormant risk, it is an active one: it still has its permissions, it still has its API access, and it is still a target if that vendor’s own systems are ever compromised.
Upgrade risk compounds the same way. Salesforce ships three major releases a year, and Ellucian Banner integrations carry their own upgrade cadence on top of that. A package that has not been touched since 2021 is a package nobody has tested against the current release. When something breaks during a routine upgrade window, the first troubleshooting question, “what changed,” is much harder to answer when the org is carrying components nobody remembers installing.
Running This Without a Dedicated Salesforce Admin
Most VPs of IT at mid-size institutions do not have a full-time Salesforce administrator on staff, and this kind of audit is exactly the work that falls through the cracks of a lean team’s day-to-day ticket queue. It is also the kind of work an outside diagnostic partner can do in a defined, bounded engagement rather than an open-ended retainer: pull the inventory, run it against the four questions, and hand back a prioritized list of what to decommission, what to renegotiate, and what actually needs attention before the next upgrade cycle. This is the kind of audit Sanguine Tech Group runs for higher ed Salesforce and Banner environments, not to sell a bigger managed services contract, but because an institution cannot make a good decision about its platform without first knowing what is actually installed in it.
Where to Start
You do not need a full architecture review to get value out of this. Pull the Installed Packages list this week. Count the rows. For each one, see if you can answer who uses it, who owns the license, and what data it can reach. If you get through the list without a clear answer on more than two or three packages, that gap is the actual finding, and it is worth a conversation about what a full audit would surface before your next renewal cycle or your next Banner-adjacent upgrade forces the question for you.
Sources
- sfapps.info, “State of AppExchange Salesforce Apps Market 2025 (May ’25 Update)”: https://www.sfapps.info/salesforce-apps-stats-2025/
- Salesforce Ben, “Salesforce Admins Are Drowning in Technical Debt: It’s Time to Address It”: https://www.salesforceben.com/salesforce-admins-are-drowning-in-technical-debt-its-time-to-address-it/
- EDUCAUSE Review, “EDUCAUSE QuickPoll Results: Technology Budgets and Staffing” (April 2025): https://er.educause.edu/articles/2025/4/educause-quickpoll-results-technology-budgets-and-staffing
