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
View Details about Your Converted 2GP Package
Specify Dependencies on Unpackageable Metadata
Test Your Converted Managed 2GP Package
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
AgentExchange App Analytics for First-Generation Managed Packages
Developing and Distributing Unmanaged Packages
PDF

Note: This release is in preview. Features described here don’t become generally available until the latest general availability date that Salesforce announces for this release. Before then, and where features are noted as beta, pilot, or developer preview, we can’t guarantee general availability within any particular time frame or at all. Make your purchase decisions only on the basis of generally available products and features.

Test Your Converted Managed 2GP Package

Before you migrate your first subscribers, we strongly recommend you install your newly converted managed 2GP package into a new scratch org and test its functionality. If you prefer, you can also install the converted package in a sandbox, or developer edition org.
  1. Create a scratch org. When creating your scratch org, be sure to include a scratch org definition file that includes any Salesforce features that your package depends on. 
    1sf org create scratch --target-dev-hub MyHub --definition-file config/project-scratch-def.json
  2. Migrate the converted package.
    To verify the 04t ID of the converted package, run sf package version list and review the command output. Then run the package install command and specify the 04t ID. In this scenario, the package version is being migrated, not installed.

    Example:

    1sf package install --package 04t...

    Next, explore your package and test its functionality. Make sure everything is operating as expected. Note that the converted package is a beta version.

During phase one you can convert your 1GP package, install the converted package in a scratch org, and try out package migration by using packages that are installed in scratch orgs. By testing these steps in a scratch org first, you can understand how package migration works, before migrating packages used by active customers.