We have some exciting news to share for Salesforce ISVs – a chance to migrate your managed packages from the first generation (1GP) to the second generation (2GP) is on the horizon! Although the migration isn’t yet accessible to everyone, you can participate in the Salesforce pilot program together with us and prepare for the impending migration. In this blog, we will explain what managed packages are, the differences between 1GP and 2GP, why the migration is something you should consider for your organization, and how a PDO partner like Aquiva Labs can help you prepare!
What is a Managed Package?
A managed package serves as a receptacle for an application’s constituents, facilitating the installation of said application in a Salesforce environment. Additionally, it enables the application to be updated to a newer version, providing users with the latest supplementary features. This technique is Salesforce’s primary approach for third-party applications.
To gain a listing, ISVs are subject to an exacting procedure. These vendors use managed packages to safeguard their intellectual property (IP) by obscuring their Apex code from view.
Typically, ISVs create managed packages, but they need not be included on the AppExchange as a core feature. Open-source developers furnish them for free, making available application components for the community to use. These packages offer customized Flow components that supply supplementary common functionality, and they are disseminated via managed packages.
Comparing Managed 1GP Packages and Managed 2GP Packages
Salesforce offers two methods for producing managed packages: the older First Generation (1GP) and the more recent Second Generation (2GP). While both serve the same objective of creating a managed package for sharing applications with other Salesforce organizations, they differ in their approach to facilitating version comparison and creation.
| Managed 1GP Packages | Managed 2GP Packages |
|---|---|
|
The metadata in your package is considered authoritative if you're using a managed 1GP package, and it resides in the packaging org. |
If you're using a managed 2GP package, the metadata in your package is considered authoritative if you're using a source-driven system with version control, and there's no need for packaging or patch orgs. |
|
The packaging org is the owner of the managed package in a 1GP packaging model, and the packaged metadata is stored in it. |
The managed package in a 2GP packaging model is owned by the Dev Hub, but the packaged metadata is not stored in it. To use a 2GP package, it is recommended to enable Dev Hub in your Partner Business Org (PBO). |
|
In a 1GP packaging model, a packaging org can only own a single managed package. |
In a 2GP packaging model, a single Dev Hub can own one or more packages. |
|
The namespace of a managed package is created within the packaging org in a 1GP packaging model. |
In a 2GP packaging model, the namespace of a managed package is created within a namespace org and linked to the Dev Hub. Additionally, you can associate multiple namespaces with a single Dev Hub. You can link a namespace to a managed 2GP package by running the force:package:create Salesforce CLI command, and you need to specify the namespace in the sfdx-project.json file. For further details, refer to the Namespaces for Second-Generation Managed Packages documentation. |
|
In a 1GP packaging model, a namespace can only be associated with a single package. |
In a 2GP packaging model, multiple packages can use the same namespace. |
|
Global Apex is the only means of sharing code across packages in a 1GP packaging model.
|
In a 2GP packaging model, multiple packages that share the same namespace can share code by using public Apex classes and methods with the @namespaceAccessible annotation. |
|
Certain packaging operations, such as package creation and package removal, cannot be automated in a 1GP packaging model. |
In a 2GP packaging model, all packaging operations can be automated using Salesforce CLI.
|
|
Package versioning is linear in a 1GP packaging model. |
In a 2GP packaging model, package versioning is more flexible, allowing you to abandon unwanted package versions. This flexible versioning makes it possible to use branches and does parallel package development. |
|
Patch versions can only be created in specialized orgs called patch orgs in a 1GP packaging model. |
In a 2GP packaging model, patch versions are created using Salesforce CLI. The version control system is the source of truth, and there are no patch orgs.
|
Why Migrate 1GP and 2GP?
Now that Salesforce has shared the upcoming migration possibility, you might be wondering if it is worth investing time and resources in the process.
Here’s why you should be excited about this migration and consider it for your organization:
1. Increased Flexibility: With 2GP, you can offer more customized and flexible package options to your customers. You can create multiple package variants with different features, permissions, and customizations, tailored to your customer’s unique needs.
This flexibility allows you to customize your product to support customers using different Salesforce products, such as Revenue Cloud or Salesforce Field Service (FSL), as well as different Salesforce editions like Group and Professional, without needing to create separate packages with different namespaces as in 1GP-world.
2. More Control: 2GP provides better control over package upgrades and installs, making it easier to manage your package releases and dependencies. You can customize upgrade paths, control package access, and provide more granular installation options to your customers.
3. Improved Developer Experience: With GP, you can expect a more streamlined and efficient developer experience, which includes better package versioning and dependency management. This means you can easily add or remove components, configure package settings, and use source-driven development tools like Git and VS Code to manage your package metadata. This not only makes your developers happier but as well allows you to automate many tasks, which means lower development costs and increased speed and reliability.
How can Aquiva Labs Help you Prepare for Migration?
If the migration process sounds overwhelming, don’t worry! A PDO Partner can help you prepare for the migration and make the process smoother. A PDO Partner can help you assess your current package structure, create a migration plan, and handle the technical aspects of the migration, such as converting your metadata into source format, configuring the package.xml file, and uploading the package to the AppExchange.
While the migration is not yet available for everyone, you can already send a request to join the 1GP – 2GP Migration Pilot Prep Program, and let us help you prepare and support you in this journey.
To conclude, migrating from 1GP to 2GP is an exciting opportunity for Salesforce ISVs to improve their package quality, increase their market reach, and take advantage of the latest Salesforce platform features.