Migrating customizations to Salesforce Managed Packages using Gearset

Andrew Hunter on

Share with


When a managed package is installed into a Salesforce organization, that managed package can augment the organization with new metadata such as CustomObjects or by making modifications to existing metadata such as adding a new CustomField to a standard object. These modifications can be an issue when dealing with a traditional deployment tool like Ant, as all of this extra metadata will now be mixed in with your existing metadata.

It’s possible to ignore this metadata altogether, but this can be an issue as it’s possible that you will customize some of it after installation, adding new fields that model your quoting process for example. Without careful tracking, it’s very hard to tell apart the metadata that the package installed from the customisations that you made to the package’s metadata.

Gearset provides a solution to both these problems.

Hiding things you can’t act on

Gearset will hide metadata that belongs to managed packages that aren’t installed on both the source and target organizations. This ensures that when a deployment needs to include a new managed package, Gearset will only prompt to deploy the InstalledPackage metadata item itself and not list the entire set of extra objects that it will introduce. This means the package is responsible for installing all of the metadata in the target org, without the Salesforce admin or developer having to pick and choose. This is particularly important to making it possible to use the continuous integration feature to install managed packages.

Easy migration of your customizations

Once both the source and the target have the same version of a managed package deployed, it’s possible to deploy customisations to it. Gearset’s deployment strategy is based around comparisons between organizations, and with managed packages this means that any customisations will become clearly visible as differences, making them easy to deploy even if they weren’t tracked when they were originally added.

One thing to note about this is that it’s necessary to install or update the package before running another comparison to find any customizations that might need to be deployed. Gearset won’t display customisations if the package versions don’t match on both sides of the comparison. This is something that prevents inadvertent deployments that use features that are not available on the target, as well as making sure that it’s not necessary to manually remove parts of the package during an upgrade.

Sign me up!

We provide a full and unlimited free 30-day trial. No need to create an account or provision an environment and you’ll join our happy customers that trust Gearset to manage all their Salesforce release needs.

Try all of Gearset for free