There’s no question that the “Build” vs. “Buy” debate is a big one. The Salesforce AppExchange is a massive network of third party applications offered by Independent Software Vendor Partners (often referred to as ISV Partners). You can install these applications atop your Salesforce implementation to extend native functionality without having to do custom development yourself. 

‍

Oftentimes, acquiring a managed package has a smaller total cost of ownership compared to a homegrown application and can result in faster ROI. However, that doesn’t mean that managed packages are just an easy button. Even after implementation, it’s important to ensure your managed infrastructure is kept up to date on a regular basis.

‍

Technology is constantly evolving and advancing at an ever faster rate, and Salesforce is no exception. The platform gets major changes three times a year, releasing new features and deprecating out-dated functionality each time. If you’re not also keeping your managed packages up to date then you run the risk of outdated functionality causing performance issues or security vulnerabilities.

‍

Despite this, it’s not uncommon to have outdated managed packages installed, sometimes being multiple versions behind. We’ve seen packages as outdated as 15 years, which is a big problem! Usually this is because customers forget to uninstall unused packages or the old version never caused them any major issues so they’ve treated it like a “send it and forget it” scenario. But while keeping packages up to date can be challenging, having outdated package versions can pose serious risks and cause significant setbacks.  to keep packages up to date is far less than the time and cost of cleaning up a major security breach,realizing mission-critical business processes have broken, or having to delay critical initiatives.

‍

Let’s deep dive on why stale packages are such a risk.

‍

Why updating should be a priority

Outdated managed package versions can hurt your organization in more than one way. Here’s the top 5 reasons package updates should never sit in the backlog.

‍

1. Bug patches

No one likes bugs, but they do happen. Even with mature managed packages that have undergone Salesforce’s robust security review process, sometimes there are hidden issues that don’t arise until a customer reports a problem.

‍

When ISV partners identify a potential bug, they release a fix in a new version. By leaving old versions in your org, you may be inadvertently exposing your users to bugs. These bugs may have even caused you to develop a custom workaround, which just leads to more technical debt. Keeping your packages up to date can prevent bugs from causing grief down the line.

‍

2. Security

As Salesforce’s security requirements change and evolve, ISV partners will update their managed packages to stay aligned to best practices and system requirements. These new versions are vetted through Salesforce’s package security review process. This means if you still have old versions of packages installed then you don’t have the latest security reviewed version and may have security vulnerabilities installed.  Without the new version, the package may break or become a security risk for your company.

‍

For example, Salesforce released a security update to allow for protection against cross-site scripting (XCC) on Visualforce Pages. XSS is a type of cyberattack performed by injecting malicious scripts into a website to perform harmful actions such as identity theft. When this protection was added to managed packages, customers had to upgrade to benefit.

‍

Another example is the depreciation TLS 1.0 and 1.1. TLS (Transport Layer Security) is a security protocol for the transfer of data over the internet (HTTP calls). 1.0 and 1.1 are old, outdated versions of the protocol that Salesforce is about to deprecate, meaning any managed packages using these old protocols will need to be updated to avoid using deprecated security protocols.

‍

Additionally, as best practices evolve in cybersecurity, ISV partners will often add additional security to their managed packages. By upgrading, you’re staying ahead of the curve to keep your Salesforce implementation safe!

‍

3. Compliance

In addition to security updates, packages will often get updates for evolving compliance standards, like those for GDPR. They can also contain updates to stay compatible with changes to the Salesforce platform. 

‍

An example from the past couple of years is a change that Salesforce made to enforce ISO locale formatting. While originally announced in Winter 2023, Salesforce had to postpone enforcing the change several times because so many customers had customization or managed packages that used old formats. They finally made it mandatory in Summer 2025, when some ISV partners still had to scramble to upgrade their customers’ packages so their functionality was not impacted!

‍

4. Untapped ROI

A lot of packages have license costs associated, and that cost is the same regardless of what version you're on. By staying with old versions and stale functionality, you're not fully leveraging your company's Salesforce investment. It's like leaving money on the table!

‍

Furthermore, it isn’t unusual for your company’s IT roadmap to include items that are also on the roadmap for your managed packages. By keeping up to date with upgrades, you may be able to easily accomplish key roadmap milestones with minimal effort.

‍

5. Project dependencies

New initiatives may require the use of updated package features and settings. If you're not up to date, then suddenly your stale versions are becoming project blockers! Now the project's timeline and budget are at risk because you have to include package upgrades and testing to scope. Avoid having to tell key stakeholders that initiatives are delayed because you neglected updating packages!

‍

6. Improved product support

Most ISV partners have a product support team, so when you have an issue with the product you can log a ticket with them to investigate and help. Unfortunately, when you encounter a problem one of the first things they'll do is make sure your version is up to date and, if not, ask to upgrade and see if that fixes things. This just causes further delays with tedious back and forth questions about package versions and asking for upgrades. Not only does this delay getting help, it also distracts your team from doing the work that really matters–helping your customers and internal stakeholders. Don't let stale package versions hold you back from getting quick help!

‍

‍

Identifying Version Numbers

Before we continue onto considerations and best practices for upgrading, let’s explore how version numbers work. This can be important because it helps identify whether an upgrade is a major release with a lot of changes or something minor. Most versioning in IT uses a format called “Semantic Versioning”. This follows the format of #.#.#. The first number indicates a MAJOR release, the second number indicates a MINOR release version, and the third and final number indicates a PATCH of that minor version. Not all ISV Partners bother with the third and will sometimes just have major and minor releases in a #.# format. So version 12.5 to 12.6 is a much smaller change compared to 12.5 to 13.0!

‍

Comparing the installed version of your managed packages to the most recently released versions can be a good indicator of how substantially far back you are in terms of new content and bug fixes.

‍

‍

Package upgrade considerations

Now you know the importance of package upgrades, but that doesn’t mean you can just click the button and hope for the best! Sometimes upgrading a package is a seamless change, only affecting backend functionality, but sometimes it can have a very real impact on functionality and system behavior, especially if you have any custom/local automation built on top of it. 

‍

Unfortunately, upgrading Salesforce managed packages is a little more delicate than upgrading apps on your smart phone. Here are some pro-tips to make your upgrade go smoothly:

‍

1. Regression testing

This may go without saying, but new versions should always be tested to ensure no disruption to existing configuration. If the package is wide-spread and touches multiple processes in your org, then regression testing is always recommended.

‍

Never assume changes will be seamless and live by the “better safe than sorry” motto, because rolling back package versions can be messy, timely, and more expensive than having a professional do things the right way earlier on.

‍

2. Review the Release Notes

Most major ISV Partners keep updated release notes so you know what changes are coming in new release versions. It’s usually recommended to skim these before installing a new version so you can prepare for the changes that are coming, especially if it’s a major release!

‍

3. Explore Push Upgrades

ISV Partners have the option to mark certain minor upgrades as “Push Upgrades”. A Push Upgrade is an upgrade that is silently “pushed” to your Salesforce org so that small, incremental updates and bug patches can be applied without you, the customer, taking any action.

‍

Sometimes, however, ISV Partners make push upgrades an opt-in option. Depending on how much customization you have built atop the package, opting in to push upgrades can let you keep minor releases and patches on auto-pilot so you can focus on planning and testing the major releases.

‍

If you’re not getting automatic upgrades on your managed packages today, it may be a good idea to ask the package’s product support team and see if they’re an option. That team can also help you assess whether or not push upgrades are a good fit for you.

‍

4. Talk with your vendor

Speaking of ISV partners, they can be a great resource if you have any questions about package upgrades. Many vendors are more than happy to give inputs on potential “gotchas” or considerations for upcoming major release versions. From product support teams to customer success representatives, most ISVs have people dedicated to this task. It can’t hurt to reach out if you have any concerns or unease about an upcoming version.

‍

5. Prioritize and make an action plan

A big undertaking always feels smaller when you break it up into smaller milestones. Make sure there is a solid action plan in place. Review your list of installed packages and check the current version to see what needs attention most critically.

‍

Anything with major versions behind should usually be prioritized first. Additionally, if there are any mission critical applications out-dated, those should also be strongly assessed for potential risks. Lastly, if you have key initiatives that rely on any managed package functionality, then consider ensuring those packages are up to the task and up-to-date before they jeopardize other timelines.

‍

6. Prepare for “gotchas”

While uncommon, there are sometimes unexpected (and unfortunate) surprises that come when you update a package that is several versions behind or that has significant changes. Salesforce has documentation on some of these, but here’s some details on the main ones we’ve encountered in the past:

1. Package content changes: sometimes a managed package upgrade will include a deprecated field. These aren’t usually an issue, but if you have custom automation referencing these fields then suddenly things could start breaking! This is why regression testing is important, but you can also get ahead of these changes by reviewing the release notes.
2. Access to new functionality: if a new release brings new functionality, sometimes this requires additional permissioning for users to take advantage. Make sure you login as multiple user profiles while testing to make sure they have full access to the new functionality.
3. Compatibility with Salesforce licensing: many Salesforce products like Shield or Industry Cloud include additional functionality that can be applied to managed package components, such as platform encryption or using data processing engine on managed package data. In these scenarios, the latest package upgrade could conflict with this additional Salesforce functionality. Make sure you test in a sandbox with production configuration and licensing to identify these conflicts early on!
4. Org limits: Salesforce has a lot of limits in the system, such as the maximum number of lookup fields or rollup summary fields. While managed packages don’t count towards all of these limits, some of these limits are hard limits. If a managed package upgrade has new functionality that hits a limit in your org, then the upgrade will fail and you will have to clean up technical debt before proceeding. Thankfully, we have a post all about technical debt, so you can stay prepared! Read more →

‍

7. Partner with experts

As Salesforce consultants we have wider visibility into products in the ecosystem and have likely encountered the same managed packages in other organizations. This understanding allows us to quickly identify potential risks and benefits of package upgrades based on how you are using the package and the features contained in newer versions. Partnering with an expert can help you prioritize and plan your upgrades.

‍

We’re here to help!

Upgrading a managed package can sometimes be a daunting task, and not all teams have the bandwidth to juggle upgrades along with everything else going on. At Summit One, we’ve done our fair share of managed package implementations and upgrades, so we know what to look for and how to help plan your upgrade strategy. We offer free 24-hour health checks that help you uncover your technical debt and risks, including outdated managed packages.

‍

Get in touch to see how we can make sure you’re maximizing on your Salesforce investments and staying ahead of the game! Schedule your Health Check →

‍