Friction-free process to switch to SalesforceDX with existing managed package

Summary The next generation of packaging is still very much a work in progress. The core focus is embracing the source control driven approach of DX into how we develop and distribute packages. The current road map shows that the first GA release is until Summer 2018:

Moreover, this schedule is really about migrating existing packages to use the DX format. The more difficult process of consolidating packages to take advantage of the new features that DX promises is still being discussed. So my approach for 2018 is to look at migrating some simple, standalone packages to DX to test out the new process and provide feedback, and look to incorporate some of the CI/Test capabilities of DX into my development process.

Discussion I went to the DX Packaging/Packaging 2.0 session in the partner lodge, and my takeaways were this...

Firstly, they can't decide on the name, though I think DX Packaging will eventually win out, but feels like that is symptomatic of the current state of DX Packaging...very much a work in progress

I might start the process with a free package I support for NPOs, but I am going to wait until next DF 18 to see where they are in the process before I start moving any commercial packages - it is too much of a moving target right now.

Most sessions I saw about packaging and DX admitted they weren't really using DX for development - more for CI and Testing (e.g. this session had some good examples). The ability to create multiple scratch orgs with different setups, configurations and test data was very appealing. If you have that one customer with x feature enabled, you can easily test that configuration with the right test data.

There was a lot of talk at this session about migrating packages - but that is specifically referring to migrating packages from the current Packaging Org approach to the new DX Source Control approach. It sounds like that by mid 2018, you will be able to convert a package to the DX format, build it and push the upgrade into a customer's org, and it will be invisible to the customer. But I think once you upgrade that customer, you have to keep going down the DX approach. However, it also sounds like you can/should keep building packages with the old format in parallel, and if you want to, keep customers on that format - so I guess you could have some form of pilot program from some customers that are using DX Packages.

But like you say, the bigger question for many ISVs is how to take multiple extension packages and create the single namespace that DX will provide better support for when you create different configurations of the package. This was referred to by some SFDC folks as consolidating packages, and seemed be more theory than reality. I need much more clarity about how I would consolidate my packages before I can move them to DX. I have customers with millions of records in an object that uses an extension's namespace - very unclear how that sort of migration will be handled. I think we might see more clarity at the DX Conference in March 2018, and I am waiting for that before I start considering DX for those packages.

I also felt there was some confusion for me because DX Packaging will be available/intended for use with any org, not just for managed packages for ISVs. (see this session for overview) So larger customers might decide to create multiple small modules via DX packaging to make development and deployment easier. But although that is a good direction to be going in, I think that might lead to some confusion about what makes sense for one org vs ISV creating a package - but that might just be my lack of understanding.

I would definitely check out the partner sessions on DX Packaging - the PM and Dev Engineer who presented are very active in the success groups...but for me, I'll try and take advantage of the CI/Testing functions of DX, and adopt a wait and see attitude for the rest...