How a Microsoft team transitioned from unmanaged to managed Power Platform solutions

Like many customers, many Microsoft teams have used unmanaged solutions in their Power Platform production environments for years, which is not aligned with recommended practices as defined in Solution concepts – Power Platform | Microsoft Docs. The Success Hub team at Microsoft was operating in just such a production environment with 37 apps developed by 18 different teams working in many different development environments. This resulted in a lack of clear component ownership, difficulty deprecating unused components, and developers making changes directly in production, among other problems.

We just finished transitioning this shared Power Platform production environment from unmanaged to managed solutions. The documentation article Move from unmanaged to managed solutions to support healthy ALM with Power Apps – Power Platform | Microsoft Docs has since been updated based on lessons learned during our conversion, simplified for customers with less complex environments. Our approach was more complex due to the number of teams sharing the environment working on separate apps, the work of establishing clear component ownership, the need to re-layer solutions to separate out common components, and the need to minimize disruption to those teams and the production environment. This post describes how we handled this conversion.

A broadly-used shared environment

The Success Hub environment originated from the merger of three separate environments, none of which had any formal ALM or even separate development and production environments. With a decision that we should invest in building this environment as a core capability to manage our business, the number of teams using the environment grew to such a degree that we had 9000 custom attributes across 300 custom entities used by 37 different apps, all using unmanaged solutions.

Solving circular dependencies with base solutions

During early proof of concepts investigating the conversion to managed solutions, we quickly ran into a challenge of circular dependencies between entities used across multiple solutions. If table A in Solution 1 has a lookup on table B and table B in Solution 2 has a lookup on table A, there’s no way to import these two solutions as managed. To get around this problem, the team built a base solution for entities having circular dependencies. The base solution included only the metadata for each table, eliminating the circular dependency problem. We also built a utility console app to generate a .CSV output file, which displays tables, forms, and views used by portal apps, determined by checking the entity forms and entity lists used in a portal. We used the output file to determine dependencies between portal apps and table forms and views.

The hard and worthy work of cleaning up solutions

With the circular dependency problem resolved, the most significant work of the conversion was cleaning up all the unmanaged solutions to make sure every component existed in only a single solution.

First step the team attacked was to eliminate unused forms, views, attributes, and entities, in that order. Eliminating forms & views first eliminated dependencies, so it was easier to know what attributes were not in use. We also considered how many records had been recently created or updated as records that were more likely important to retain.

Through this exercise, the team eliminated 1000 of the 9000 custom attributes and 50 custom entities.

With the schema clean-up complete, next up was to find a single solution home for every table and attribute. Any entities used in multiple applications were moved into a single common solution to avoid the circular dependency across solutions problem. The team developed a utility to find all components, attributes, and entities hosted in multiple solutions, which served as the basis to find a single home for each component. Through this part of the effort, the team eliminated almost 300 solutions.

Conversion waves

With 38 solutions still remaining after the cleanup, we decided to group the solutions into four waves to be converted together, the first being the base and common solutions and the last being reserved for solutions with known performance impacts during trial conversions.

Trial conversions

In addition to important internal scenarios, this environment hosts several Ideas sites used by hundreds of thousands of customers. As such, we needed to ensure we understood any potential performance impacts during conversion.

The team made multiple copies of our production and dev environments including associated portals and practiced converting each wave multiple times to confirm successful conversion and check for any performance impacts during conversion. Our strategy was to do final conversions outside of normal business hours and when no significant integrations are running, so we scheduled trial conversions during similar windows for the most comparable results. During the trial conversions, we focused on monitoring performance impacts on:

• App being converted
• Other core apps
• Portals

All dev teams had to sign off on the base and common solution trial conversions prior to the first wave conversion and on their own trial conversions prior to their own wave.

Final conversions

Final conversions were done first in the test environment as a final check for successful conversion. After all the careful planning and trials, final conversion in production succeeded without incident.

With the migration completed, the team is realizing the benefits of using managed solutions in production:

• Clearly defined component ownership
• Improved solution import performance with reduced performance impact on the production environment
• Better process for eliminating components that are no longer needed
• Eliminated direct changes to solutions in the production environment that caused unexpected inconsistencies across environments