Power Platform ALM: How Does a Maker App Reach Managed Production?

Why ALM Matters Before Production

Maker-built solutions in unmanaged development environments look finished before they are governed. The move from unmanaged to managed is the move that puts the work under change control, gives it a repeatable release path, and produces the evidence a compliance review reads later. Skipping that move is how a working app becomes an unaudited dependency.

The Six-Stage Release Path

Stage 1: Build Unmanaged

Components organized into named solutions under a custom publisher. The custom publisher is what lets multiple solutions coexist without namespace collisions, and it is what appears on every component the solution owns.

Stage 2: Version and Commit

Exported files stored in source control with change history. Microsoft states that exported unmanaged versions of your solutions should be checked into your source control system. That commit is the audit anchor: the point in history a rollback deploys forward from.

Stage 3: Export as Managed

The same solution re-exported as a managed artifact for deployment. Managed is how the solution enters non-development environments; unmanaged is what you edit.

Stage 4: Test as Managed

Managed solution imported into a separate test environment for validation. Critically, Microsoft documents that you cannot import a managed solution into the same environment that contains the originating unmanaged solution. A separate test environment is a mechanical requirement, not a nice-to-have.

Stage 5: Deploy to Production

Unmodified artifact imported with environment-specific configurations. The artifact that lands in production is the same one that passed test; environment differences ride in configuration data, not in re-exported solutions.

Stage 6: Hand Off Ownership

Named business and technical owners receive the solution with documentation. Without the handoff, the solution belongs to whoever built it, and the build team owns operational risk indefinitely.

Managed vs. Unmanaged: The Distinction That Decides the Environment Count

Unmanaged solutions are development environments where changes occur. They are what makers edit and what source control commits capture.

Managed solutions deploy to non-development environments. Microsoft’s constraint is explicit: a managed solution cannot be imported into the same environment that contains the originating unmanaged solution. Test infrastructure separate from development is therefore a requirement of the platform, not a preference of the practice.

Four Common Failure Points

• Absence of auditable change records. Changes made in production leave no signed trail; the compliance review is the moment the gap becomes visible.
• Development and production operating simultaneously in one environment. One person’s experiment breaks another person’s process without either person knowing.
• Hidden dependency failures during deployment. A component in the receiving environment shifts, and a solution that passed test yesterday fails today.
• Solutions becoming unmaintainable when original creators depart. Without source control and named owners, the leaving individual is the documentation.

Testing Requirements

Three validation types precede each release, and each catches a different class of defect.

Static analysis via solution checker against best-practice patterns. Fastest to run, catches the mechanical mistakes that never should have shipped.

Deployment rehearsal through pipelines validating dependencies and configurations. This is where a missing dependency surfaces on a test import rather than a production one, at the cost of a test cycle rather than an outage.

Functional validation by personnel exercising the business logic as end-users. The tests the platform cannot write, done by the people who will suffer if they fail.

Rollback Reality

Recovery differs from reversal. Microsoft documents that when a managed solution is deleted, meaning uninstalled, all the customizations and extensions included with it are removed, including data in custom tables. Deletion is not a rollback strategy; it is a data-loss event.

Recovery relies on deploying the previous managed artifact forward, not on uninstalling the current version. That is the practical purpose of Stage 2’s commit: the point history a rollback deploys forward from.

Governance Handoff Elements

Sustainable solutions require four pieces at handoff. Dual ownership: a business owner accountable for whether the encoded process still fits, and a technical owner accountable for release management and environment integrity. Named deployment authority: who authorizes a promotion to production, and how the record shows they did. Source control access persistence: a maker’s departure cannot remove the team’s ability to build. And monitoring responsibility assignment: the person whose job it is to notice when the solution stops behaving as designed.

How i3solutions Runs Power Platform ALM

i3solutions has delivered on the Microsoft stack since 1997, with senior, 100 percent US-based teams. ALM runs the same discipline every governance-first program does: build under a custom publisher, commit before exporting, deploy the same artifact through test and production, and hand off with named owners and the evidence a review can read.