First-Generation Managed Packaging Developer Guide

First-Generation Managed Packages
Why Switch to Second-Generation Managed Packaging?
Move to 2GP: Migrate Your Managed Packages with Ease
About Package Conversion and Package Migration
Three Phases of Package Migration Development
Plan Your Package Migration
Before You Begin Package Migrations
Convert Your Managed 1GP Package to 2GP
Migrate Your Subscribers from 1GP to 2GP
Move to 2GP Package Development
Considerations for Package Migrations
Troubleshoot Package Conversion Failures
Register a Namespace for a First-Generation Managed Package
Create a First-Generation Managed Package Using a UI
Create a First-Generation Managed Package using Salesforce DX
Components Available in First-Generation Managed Packages
Behavior of Specific Metadata in First-Generation Managed Packages
Package and Test Your First-Generation Managed Package
Update Your First-Generation Managed Package
Publish Upgrades to First-Generation Managed Packages
Manage Licenses for Managed Packages
Manage Features in First-Generation Managed Packages
AppExchange App Analytics for First-Generation Managed Packages
Developing and Distributing Unmanaged Packages
PDF

Newer Version Available

This content describes an older version of this product. View Latest

Before You Begin Package Migrations

If you’ve never created or worked with managed 2GP packages, scratch orgs, or Salesforce CLI, take some time to learn more about Salesforce DX and second-generation managed packages.

Review Know Your Orgs for Second-Generation Managed Packages, How Scratch Orgs Fit in the Package Development Workflow, and Before You Create Second-Generation Managed Packages and ensure you have enabled:

  • Dev Hub in your Partner Business Org
  • Second-Generation Managed Packaging in your Dev Hub

The Second-Generation Managed Packages Trailhead module is a great resource to learn more about 2GP.

Prerequisites for Package Conversion

Before starting package conversion, review the requirements regarding metadata support, API version, and managed-released versions. Ensure your package meets these criteria.

Metadata Support

If your 1GP package contains metadata that isn’t currently supported in 2GP packages, the package conversion fails. You can compare the metadata in your package against the Metadata Coverage Report and ensure the metadata in your 1GP managed package is also supported in 2GP.

Alternatively, you can identify metadata issues by running the CLI package convert command. The package convert CLI command detects and reports back to you any 1GP metadata types that prevent the package from being converted to 2GP. Using the package convert CLI command in this way lets you quickly assess whether you have any packaged metadata that isn’t supported in 2GP. During package conversion, your original managed 1GP package isn’t altered. It’s safe to test out the conversion command, before you are ready to migrate your packages to 2GP.

If your package contains metadata that isn’t supported in managed 2GP, either remove the metadata from your package, or wait to convert the package until managed 2GP supports that metadata type.

API Version
You can convert first-generation managed packages created using API version 57 (Spring ’23) or higher.
Managed-Released Package Versions
You can convert managed-released package versions only.
User Permissions

Package conversion and migration require the second-generation managed packaging user permissions. See Assign Second-Generation Managed Packaging User Permissions for details.