Salesforce Packaging Models for ISVs: 1GP vs 2GP vs Unmanaged

For an ISV building a commercial AppExchange product, the packaging model is a one-way door: your namespace, your upgrade path, and your IP protection are all set by this one early decision. Second-Generation managed packages (2GP) are the right default for almost every new commercial product today, with First-Generation (1GP) reserved for legacy edge cases and unmanaged packages ruled out entirely for anything you plan to sell.

What's the difference between 1GP, 2GP, and unmanaged packages?

An unmanaged package has no namespace and ships fully editable metadata. It's fine for open-source templates or a one-time deployment, but every component becomes indistinguishable from the customer's own customizations the moment it lands - you lose the ability to identify, support, or safely upgrade what you built.

A managed package, whether 1GP or 2GP, is namespaced and locked. Customers install it, use it, and cannot edit its internals directly. That's what makes it a product rather than a one-off deployment: you control the release cadence, and Salesforce enforces the boundary for you.

The 1GP vs 2GP split is about tooling and org dependency. 1GP packages are built and versioned inside a dedicated packaging org that becomes a permanent, irreplaceable part of your release pipeline. 2GP packages are source-driven, built from version control with the Salesforce CLI, and don't require a standing packaging org at all - which is why Salesforce has been steering new ISVs toward 2GP for years.

Why is your namespace a permanent decision?

Once a namespace is registered against a Developer Edition org and used in a released package, it cannot be renamed, transferred to a different org, or reused. Every Apex class, custom field, and object your product ever ships will carry that prefix in every customer org, forever. Typos, awkward abbreviations, and rushed naming choices don't get a do-over - plan the namespace like a product name, not a technical afterthought.

How do IP protection and licensing actually work?

Managed packages compile Apex into byte code that customers can't view or edit, which is the baseline IP protection any commercial product needs before it goes near the AppExchange Security Review. Unmanaged packages offer none of that - your business logic ships as plain, readable, forkable metadata.

Licensing is a separate layer entirely. To actually meter seats, trials, and expirations, you connect your package to a License Management App (LMA), which tracks installs against your leads and opportunities. This only works cleanly with managed packages - there's no reliable way to license and enforce entitlements on something a customer can freely edit.

What about unlocked packages?

Unlocked packages sit between these worlds: namespaced and version-controlled like 2GP, but with editable metadata and no licensing enforcement. They're built for internal, multi-org deployment inside a single company, not for selling to strangers on the AppExchange. Don't reach for them as a shortcut around commercial packaging.

Which packaging model fits your ISV stage?

• Building a new AppExchange product today: use 2GP. CLI-driven versioning, ancestry tracking for upgrades, and no dependency on a fragile packaging org.
• Inheriting or maintaining an older 1GP product: stay on 1GP until there's a deliberate migration plan - namespace and subscriber base carry across, but the conversion has real technical constraints.
• Distributing free, editable tooling or templates: unmanaged is legitimate here, precisely because you're not protecting IP or charging for upgrades.
• Standardizing deployments across your own orgs: unlocked packages, not managed packages built for resale.

Getting this wrong is expensive to unwind - Tekunda's product development work with AppExchange partners starts with exactly this decision, before a single component gets built, because every governance, testing, and release choice downstream depends on it.

FAQ

Can I switch from unmanaged to managed later?

Not directly. You'd rebuild the components inside a namespaced managed package and manage a real customer migration, since the underlying metadata and IDs don't carry over cleanly.

Can I convert a 1GP package to 2GP?

Yes, Salesforce supports converting 1GP managed packages to 2GP while keeping the same namespace and subscriber orgs, though it requires careful planning around package ancestry and existing installs.

Do I need a namespace if I'm not selling on the AppExchange?

Only if you're distributing a managed or unlocked package across multiple orgs. A single internal deployment via unmanaged metadata or change sets doesn't need one.

Is 2GP required for AppExchange listing?

No, 1GP packages are still supported and listed today, but Salesforce's tooling investment is squarely in 2GP, and most new ISV builds should start there. Talk to Tekunda or browse the blog if you're weighing this decision for an upcoming build.