I have a managed package in Bitbucket and want to work on it using DX. There are tons of articles on how to migrate to DX but I am still looking for a one page checklist that I can use for every project in the sense that a developer can prepare a DX conversion in a branch until everything works and then just merged the new structure into master and the remaining developers can basically work in DX from that on. It could start like:

  1. Branch your repo
  2. Create empty DX structure
  3. Move classes using command xyz
  4. Commit
  5. ...
  6. Test everything in scratch .org
  7. Merge into master

1 Answer 1


Here are the steps that I follow which worked for me .

  1. Retrieve source in DX Source format from the Managed Package directly using the SalesforceDX CLI .

This process generally involves first pulling all the metadata from the package using madapi command using package name and then running source convert command .

In order to make this seamless I have created a simple DX Plugin that should allow you to retrieve the source code in SalesforceDX Source format directly.

You can install the plugin using sfdx plugins:install mo-dx-plugin

You will need to authenticate with the packaging org using CLI and then retrieve source using

$ sfdx retrieve:pkgsource -n "packagename" -u <username/alias>

At this point if you are lucky the convert command succeeds (note that SFDX has still bugs on convert command for specific metadata types and hence this might fail as well) then you have the source folder that you need to commit to repo .

In case the source conversion fails then one would need to follow process listed in this blog .

  1. Create a new branch and commit the dx source format code. Note that git will not allow you to rename files and this blogpost will show you how you can get around this .

  2. Try to push the dx source format code to the scratch org .This again you need to be really lucky to get past this . If not then you may have to figure the errors and create a folder to use mdapi for unsupported metadata in scratch orgs .

  3. Load some test data in scratch org and run a full regression .

  4. Build a Continuous Pipeline to allow deployment from scratch org source format into both scratch orgs and other orgs .

  5. The merge to master again bump the limit of file renaming using below

    git config merge.renameLimit 999999

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .