top of page

Managed vs Unmanaged Solution - The Right Choice for Deployments

Writer: Leoza Kabir BarkerLeoza Kabir Barker

Dev, Test and Prod

Let's talk about Managed vs Unmanaged solutions, shall we?


There has been a lot of discussion in my project about which solution type should be used for deployments to User Acceptance Testing (UAT) and Production environments. Deploying unmanaged solutions to UAT and PROD, which has always been a big no-no for me, so I am writing this post to convince you that managed is better.


But before we get into the "which," let's cover the "what."


Unmanaged solutions

  • Used in development environments where you build and modify applications.

  • Can be exported as either managed or unmanaged.

  • Components can be added, removed, or modified.

  • Deleting an unmanaged solution does not remove its components—they stay in the default environment.

  • Used for initial development but should not be deployed directly to UAT or PROD.


Managed solutions

  • Used for deployment to non-development environments such as Test, UAT, and Production.

  • Created by exporting an unmanaged solution as a managed solution.

  • Components cannot be edited directly in the target environment. To modify them, they must be placed in the default solution first.

  • Editing a managed component creates dependencies between unmanaged customizations and the managed solution.

  • Cannot be exported from an environment once imported.

  • Deleting a managed solution removes all its components, ensuring a clean environment.

  • Enforces version control and structured deployment practices.


So now that we know the difference between the two solution types let's talk about the best option for deployment.


Deploying an unmanaged solution to UAT/PROD

While deploying an unmanaged solution allows direct modifications and quick fixes, it comes with it's risks:


  • Uncontrolled Changes – Anyone with permissions can modify or delete components in UAT or PROD, leading to inconsistencies between environments.


  • No Rollback Capability – If something breaks, it’s difficult to revert changes, as components persist even after solution removal. Imagine needing to undo a change that involved field creation, form modifications, automation, and business rules—without a rollback plan, this can be a nightmare.


  • Environment Clutter – Unmanaged components remain even after solution deletion, leading to technical debt.


  • No Clear Versioning – Makes tracking changes and maintaining versions more complex.


  • Difficult to Automate – Not ideal for ALM (Application Lifecycle Management) pipelines or CI/CD processes, as deployments become manual and inconsistent.


Deploying a managed solution

Importing a managed solution to your UAT and Production environments will allow for the following:


  • Enforces Governance & Security – Prevents unauthorized modifications in UAT and Production, ensuring consistency and compliance.


  • Easy Versioning & Upgrades – Supports versioning, controlled updates, and patches, allowing older versions to be rolled back if needed.


  • Rollback Capability – If an issue arises, changes can be reverted (as long as there are no dependencies).


  • Keeps Environments Clean – Deleting a managed solution removes all related components, avoiding clutter.


  • Supports ALM & Automated Deployments – Enables structured deployments using Azure DevOps or Power Platform Pipelines.


  • Prevents Configuration Drift – Ensures Dev, UAT, and PROD stay aligned, reducing inconsistencies.



Some argue that managed solutions come with limitations, but let’s reframe them as best practices:


  • Modification Not Possible in UAT/PROD


    Why It’s Good: This ensures that all modifications go through a proper development and testing cycle, reducing the risk of breaking functionality due to ad-hoc changes. It also keeps a single source of truth for all configurations and customizations.


  • Removing Managed Solutions with Dependencies Can Be Tricky


    Why It’s Good: Forces teams to deploy carefully and ensures no missing components, preventing partial deployments and broken dependencies.


  • Requires Proper Versioning & Planning


    Why It’s Good: Encourages accountability and ensures each release is properly documented. It also aligns with Agile and DevOps best practices, ensuring updates are tested before hitting production.


  • Layering Choice Fields Can Be Tricky


    Valid Concern: Sometimes deleted values reappear in the target environment, which can make it difficult.


  • Connectors Like SharePoint May Require Post-Deployment Edits


    Valid Concern: Some connectors require additional configurations in let's say a canvas app or power automate flow post-deployment, making them harder to work with in a managed solution..


Many of these "cons" actually enforce best practices and contribute to a more stable, maintainable, and scalable environment.

Managed solutions:

  • Protect system integrity

  • Ensure proper version control

  • Support ALM strategies

  • Enable automated deployments

  • Maintain clean and controlled environments


I don’t think I need to spell it out, but I am definitely team managed solutions for deployments. 😉 And just in case there was any doubt—Microsoft’s best practice is to use managed solutions!


About Me

I'm Leoza Kabir Barker, a Functional Consultant at XRM Vision with a focus on the Power Platform. Through my expertise, I aim to streamline processes, optimize operations, and maximize productivity. 


Connect with Me

コメント


ABOUT

1. _DSC0318-Edit-2.jpg

Welcome to my corner of the digital world! I'm Leoza Kabir Barker, a Functional Consultant at XRM Vision with a focus on the Power Platform.

My mission? To unlock efficiency through digital transformation. Through my expertise, I aim to streamline processes, optimize operations, and maximize productivity. 

CONNECT WITH ME

SUBSCRIBE

bottom of page