Move to managed solutions

My recommendation, as well as Microsoft’s, is to only use managed solutions for environments other than the development environment. This often leads to questions from colleagues and customers on how to move to managed solutions in a setup where previously everything was deployed as unmanaged. This blog post will explain exactly that.

Background

Let’s talk shortly about the background first. I sometimes come into projects where solutions have been deployed to downstream environments as unmanaged. One of the most common reasons is that the first implementation was a couple of years ago. Back then the whole Application Lifecycle Management (ALM) story wasn’t as mature and good as we have it today, therefore a lot of customers and partners chose to only use unmanaged solutions. Since then Microsoft has invested a lot in everything around ALM. There aren’t many excuses to use unmanaged solutions in downstream environments.

The question often is how one goes about when there are unmanaged solutions in the downstream environment which should be switched to managed instead.

Solution

The solution is rather easy. All we have to do is install the same components, which we already have in the downstream environment as unmanaged, again as managed. The system will then switch the components to being managed.

You could either install the same solution again, but this time as managed, or install a new solution containing the same components.

If you are installing the same solution make sure to uninstall the old one first. The same solution can’t be twice (once as unmanaged and once as managed) in the same environment. If you don’t do that you will get the following error:
The solution is already installed on this system as an unmanaged solution and the package supplied is attempting to install it in managed mode. Import can only update solutions when the modes match. Uninstall the current solution and try again.

There are different ways of deploying the solution again as managed and changing all components to managed.

UI

The first option is to install the solution through the UI. There is no option for it, but the UI will always switch components to managed.

Depending on the components you have in your solution you will see the following warning.

PAC

We can also use the power platform cli (pac) to import our solution. In the command group “solution” there is one command “import“. This command has several parameters, one is “–convert-to-managed”. When presented the import will switch all components in the solution to managed in the target environment.

Build Tools (ADO/GH)

The last option we will look at are Build Tools for Azure DevOps (ADO) and GitHub Actions for Power Platform. Both also have a task to import a solution. Both of those tasks have a parameter to convert components to managed.

For GitHub it is called “convert-to-managed”. For ADO it is called “ConvertToManaged”.

The following screenshot shows how this would look like in a yaml pipeline in ADO.

Please be aware that the ADO UI shows the wrong text for that config. It says “Import as a Managed solution”. This can be confusing.

The UI shows the following

Update 2025-02-04: As Parvez Ghumra pointed out in his comment it looks like that the flag “convert to manage” is now true by default. This might have an effect on import time.

Publisher

Often, when I move to managed solutions, I also clean up the solutions. This means I restructure them and make sure I only have as many solutions as I really need.

Here it is important to state that one has to take care of the publisher. All solutions from one environment should have the same publisher. This is important to be able to move components between solutions.

A component has to be in at least one solution of the publisher it has been installed with the first time. Which makes it harder to restructure solutions when there are different publishers.

Solution Layering

If you move your solutions to managed it is important to note that the solution layering will have an effect on the end behaviour of your implementation.

In short solutions layer by the date and time they were installed the first time whereas newer solutions layer on top of older solutions. The end behaviour of your implementation is the combination of all layers from bottom to top where the unmanaged layer is always on top.

This means that the order you install your solutions (and ISV or MS solutions) is important when you switch to managed.

Thanks to Felix Verduin for pointing out that this is an important area when moving to managed solutions and that he encouraged me to add it.

Conclusion

It is not very hard to switch a solution to managed, but it can sometimes be scary or confusing.

I hope this post helped. Please let me know when you have any feedback or questions