Salesforce ships three seasonal releases a year. Each one can require a new managed package version. Upgrade work is the part of owning a package that never ends, and it's the part most builders underestimate when they sign the agency contract.

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 don't.

An upgrade is a new version of the same package. 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's 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.

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

Maintenance is the part of owning a managed package that never ends. Salesforce ships three seasonal releases a year. Each one 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. That 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. 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. 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

How many push upgrades have you actually shipped in the last 12 months?