To upgrade a managed package in Salesforce, you create a new package version with your changes, test it in a scratch or sandbox org, promote it to released, and then distribute the upgrade, either by letting customers install the new version or by pushing it to their orgs. Upgradeability is the core advantage of managed packages, and it is why they, not unmanaged packages, are used for commercial apps.

Pro Tip

TL;DR: Upgrade a managed package by creating a new 2GP version, testing it, promoting it to released, and distributing it via install link or a push upgrade (Salesforce 2GP Guide). Only managed packages support upgrades; unmanaged packages do not.

An upgrade is a new version of the same package. The sequence in second-generation packaging:

1. Make your changes to the package source (new components, fixes, improvements).

2. Create a new package version with the Salesforce CLI.

3. Test the version by installing it in a scratch org or sandbox to confirm a clean upgrade path.

4. Promote the version to released so it is available to customers.

5. Distribute the upgrade, either by sharing the new install URL or by issuing a push upgrade to installed orgs.

Because the package is namespaced and managed, the upgrade replaces the prior version in place without breaking the customer's data or customizations.

There are two ways customers get the new version.

Push upgrades let you update many orgs at once, which matters for security fixes and seasonal-release compatibility.

Pro Tip

Our finding: Maintenance is the part of owning a managed package that never ends. Salesforce ships three seasonal releases a year, and each can require a new version. That recurring upgrade work is a real cost most first-time builders underestimate.

Creating each new version traditionally means returning to the Salesforce CLI and the 2GP workflow, which keeps a developer in the loop for every release. A no-code platform that generates and maintains the package can produce new versions from your updated description and handle the versioning and seasonal-release maintenance for you, which removes the ongoing developer dependency, not just the first build. See building a managed package without a Salesforce developer.

Make your changes, create a new package version with the Salesforce CLI, test it in a scratch org or sandbox, promote it to released, and distribute it via an install link or a push upgrade (Salesforce 2GP Guide).

A push upgrade is when the publisher applies a new package version directly to customers' orgs, rather than waiting for each customer to install it. It is used for critical fixes, security patches, and keeping orgs current with seasonal releases.

No. Because the package is managed and namespaced, an upgrade replaces the prior version in place without overwriting the customer's data or org customizations, which is a key reason commercial apps use managed packages.

Salesforce ships three seasonal releases a year, and each can require a new package version for compatibility, plus your own fixes and features. This recurring maintenance is a real ongoing cost of owning a managed package.

About the author. Sunny Chauhan is the founder and CEO of Appnigma AI, a no-code platform that generates and maintains Salesforce AppExchange-ready managed packages. He helps SaaS teams keep packages current without an engineering team.

To upgrade a managed package in Salesforce, create a new 2GP version with your changes, test it in a scratch org or sandbox, promote it to released, and distribute it via install link or push upgrade. Push upgrades let publishers update many orgs at once. Only managed packages support upgrades. Appnigma AI generates and maintains versions no-code, including seasonal-release upkeep.

• What is a managed package in Salesforce

• How to create a managed package in Salesforce

• How to build a managed package without a Salesforce developer

• Salesforce app development cost

1. Salesforce 2GP Developer Guide (versioning, promote, push upgrades)

2. Salesforce ISVforce Guide, push upgrades