Power Platform ALM that survives the second year

There is a familiar arc to Power Platform adoption. Someone builds an application that solves a real problem in a fraction of the time a traditional project would have taken. It works. Word spreads. A second department wants it.

That second request is where the trouble usually starts — not because the platform cannot scale, but because the first application was built without the lifecycle decisions that a second team makes unavoidable.

The three symptoms

You can usually diagnose the problem from three symptoms.

Changes happen in production. There is no development environment, so improvements are made directly in the live application. Everyone knows this is wrong and everyone does it anyway, because the alternative was never set up.

Nobody can list what exists. Apps and flows have accumulated across personal and default environments. When someone leaves, their flows keep running until they quietly stop, and the first sign of trouble is a business process that has failed.

Reuse means copy. The second department gets a copy of the first application. Now there are two applications diverging from a common ancestor, and every fix has to be applied twice — until it stops being applied twice.

None of these are platform limitations. They are the predictable result of skipping lifecycle decisions during a phase when skipping them was genuinely faster.

Environment strategy is the first decision

The default environment is not a development environment. It is shared, it has no meaningful isolation, and it accumulates everything nobody found another home for.

A workable minimum is three environments per solution area — development, test, and production — with the default environment treated as a personal productivity space rather than anywhere business-critical runs. That is not a large amount of setup, and it is the prerequisite for every other practice in this article.

Two decisions make environment strategy work in practice. First, decide who can create environments — unrestricted creation produces the sprawl you are trying to avoid, and no creation at all pushes people back into the default environment. Second, decide what makes something production-worthy: the point at which an application stops being someone's useful tool and becomes something the business depends on. That threshold should be written down, because everything after it — backup, support, change control — follows from crossing it.

Managed solutions, and why unmanaged in production hurts

The distinction matters more than it first appears.

An unmanaged solution is an authoring container. Components inside it can be edited directly, and the solution is essentially a working set.

A managed solution is a deployment artefact. Components arrive as a unit, they are not directly editable in the target environment, and when the solution is removed its components go with it.

Deploying unmanaged into production means production becomes another authoring environment. Layers accumulate, the relationship between source and deployed state is lost, and eventually nobody can say with confidence what is actually running. Cleaning that up later is significantly more expensive than doing it correctly at the start, because by then a business process depends on the mess.

Managed solutions in production, unmanaged only in development. This is the single highest-value practice on the list.

Source control is not optional because it is low-code

Low-code changes the authoring experience. It does not change the fact that you have a codebase.

Exporting solutions as unpacked source into a Git repository gives you what any other codebase gives you: history, the ability to see what changed between two versions, review before deployment, and a recovery path that does not depend on someone's memory. When an application breaks after a change, "what changed" should be a question with an answer.

The practical objection is that unpacked Power Platform source is verbose and not always pleasant to read in a diff. That is true, and it is still better than the alternative, which is no record at all.

Pipelines make the right thing the easy thing

Power Platform pipelines let you promote a solution from development through test to production as a repeatable operation rather than a manual export and import.

The value is behavioural more than technical. When deployment is a manual, error-prone process, people avoid it — which means they batch changes into large risky releases, or they bypass it entirely and edit production. When deployment is a button, the safe path becomes the convenient one, and change sizes shrink naturally.

Start simple. A pipeline that promotes a single solution through three environments with an approval before production is enough to change behaviour. Sophistication can come later.

What to do with an estate that already sprawled

Most organisations reading this are not starting fresh. The practical sequence is:

1. Inventory first. What exists, who owns it, what data it touches, and what the business would notice if it stopped. The Center of Excellence toolkit helps here, but a spreadsheet built from admin exports is a fine start.
2. Triage by criticality, not by age. Business-critical items get environments, solutions, and source control. Genuinely personal tools can stay where they are.
3. Establish the target structure with one solution. Prove the environment and pipeline setup with a single real application before migrating anything else.
4. Migrate the critical items. One at a time, into managed solutions, deployed through the pipeline.
5. Set the rule going forward. New business-critical work starts in the structure. This is the step that stops the problem regenerating.

The order matters. Teams that start by writing policy before proving the structure tend to produce policy nobody follows.

Governance that makers do not resent

The version of governance that fails is a set of approval gates on ideas. The version that works removes decisions makers should not have to make.

Give people a clear environment to build in, a small set of standards, reusable components they did not have to create, and a defined route to promote something once it matters. That is faster for the maker than an unrestricted free-for-all, because they are not re-solving connection management, naming, or data access on every project.

The test is straightforward: if your governance model makes the sanctioned path slower than the workaround, people will take the workaround, and you will have neither speed nor control.