Proper Power Platform ALM: Moving from Manual ZIP Files to PAC CLI and Pipelines

Because it fails the change management controls most audit frameworks test, not because the tooling is old. When changes are exported and imported by hand, made directly in production, or deployed at weekends with no test environment, the organization cannot show four things an auditor looks for: that environments are segregated, that each change was reviewed and approved before production, that a production component can be traced back to an approved requirement, and that a bad release can be reversed. The fix is to put those controls in place and keep the evidence they produce, which is what solution-based deployment, source control, a service principal pipeline and a gated approval do. Read the exact wording of your own finding, since frameworks and auditors phrase the requirement differently.

That changes are built and tested somewhere other than production, and that the people who build them cannot also change production directly. In Power Platform that means separate development, test and production environments, unmanaged work only in development, managed solutions only in test and production, maker and customizer rights removed in production, and deployments run by a service principal rather than a named person. The evidence is the environment list with purposes, the production role assignments, the pipeline identity, and a periodic check showing no new unmanaged layers in production.

A record, made at the time, that someone other than the author reviewed the change and someone with authority approved its release. The practical form is a pull request on the diff produced by pac solution sync, approved by a second person, and an approval gate on the production stage of the pipeline in Azure DevOps, GitHub or Power Platform Pipelines. Both tools keep the approver and timestamp. An email saying a change was approved is weak evidence because it is not tied to the artefact that was deployed.

Build a chain that can be walked in both directions. Every branch or pull request references the work item behind it, the build stamps a version with pac solution version and packs the artefact only from committed source, and the release records which artefact went to which environment. An auditor can then start from a requirement and find the production version that delivered it, or start from a component in production, read the solution version with pac solution list or the solution history, and walk back through the release, build, commit and pull request to the requirement.

By doing it once in test and keeping the record. Build managed solutions from tagged source, keep previous artefacts in the pipeline, take an environment backup before production releases where your environment type supports it, and rehearse either a rollback or a roll-forward fix through the same pipeline. Record what was reverted, how long it took, and what it did not reverse, such as data written by the release. Reinstalling an earlier managed version can require removing the newer one first, with consequences for columns it added, which is exactly why auditors ask for a demonstration rather than a statement. Check current Microsoft documentation for backup and restore options for your environment type.

Eight controls, in this order. Remove direct change rights in production and keep one logged break-glass administrator. Stand up development, test and production and move to solutions, managed downstream. Put the solution in source control with a pull request reviewed by someone other than the author. Deploy through one pipeline running as a service principal with an approval gate before production. Reference a work item on every change. Rehearse a rollback once and record it. Define an emergency change route that still uses the pipeline with retrospective approval. And check production for unmanaged change monthly, keeping the result. Full test automation and multi-environment standardisation can follow later.

Give them a defined fast path rather than an exception. An urgent fix is still made in development, still packed by the pipeline and still deployed by the service principal, but with a shortened review and an approval recorded retrospectively within an agreed period, and a note of why it was urgent. The break-glass administrator account exists for the rare case where even that is too slow, and every use of it is logged and reviewed. Without a fast path, the first Friday outage produces a direct production edit, and that edit becomes the next audit finding.

Six commands cover almost everything. pac solution export downloads a solution from the connected environment as a ZIP, taking the solution unique name, an output path, and whether it is managed or unmanaged. pac solution unpack explodes that ZIP into a folder of individual component files, with an option that also unpacks canvas app sources so they are diffable. pac solution pack is the inverse, rebuilding a ZIP from an unpacked folder as managed or unmanaged. pac solution import pushes a ZIP into the connected environment, with options to publish customizations, activate plugins, run asynchronously and apply a deployment settings file. pac solution clone does export and unpack in one step and also writes the project files, which is what you use for the first baseline. pac solution sync refreshes an already cloned folder from the environment, which is what you use every day afterwards. Around those sit pac auth create for authentication, pac solution version for the build number, pac solution check for static analysis and pac solution create-settings for the per environment values. Flags change between CLI releases, so confirm yours with pac help solution.

They are consecutive halves of the same operation and people conflate them constantly. Export is a server operation: it asks the environment for a solution and gives you a ZIP file, which is a single binary that no diff tool can read and no reviewer can review. Unpack is a purely local operation on that file: it takes the ZIP and writes out a folder tree with one file per component, so a form is a file, an option set is a file, a plugin step is a file. Export gets the change out of the platform, unpack makes it reviewable and mergeable. Committing the output of export rather than the output of unpack is the most common way teams end up with version control that gives them almost none of the benefit of version control.

Clone once, then sync from then on, and reach for the explicit pair when you need control. Clone runs export and unpack together and additionally creates the project files that let the folder be built as a repeatable artifact, which makes it the right command for taking the first baseline of a solution that has never been in source control. After that, sync refreshes the cloned folder from the environment and gives you the change set as a diff in your working tree, which is the daily loop. The explicit export and unpack pair is still worth knowing and still worth running once, because it is what the pipeline and the tooling are doing underneath, and because there are situations, such as exporting with specific included settings or against a target version, where you want each half separately.

You can, and for a single developer on a single small solution it is a defensible choice for a while. The point at which it stops being defensible is not a headcount, it is the arrival of any one of four things: a second person making changes, a production environment that real money depends on, an auditor or a customer asking what changed and when, or the first release that has to be rolled back. Each of those turns a hand carried ZIP from an inconvenience into a risk. The cheap middle position is worth naming: get the solution unpacked into Git and use sync on a branch, which takes an afternoon and delivers history and review, and leave promotion manual for a while longer. That gets you most of the benefit before you have written a line of pipeline.

Unmanaged is the editable state, which is why development environments hold unmanaged solutions and why that is the only place components should be edited. Managed is the sealed state: the components are locked to the solution that installed them, and crucially the whole thing can be uninstalled, which is what makes a release reversible. The rule that follows is simple and should never be broken, not even once under deadline pressure. Development is unmanaged, test and production only ever receive managed. The reason it should never be broken is that an unmanaged component imported into a target becomes part of the base layer of that environment permanently, with no uninstall available, and the only routes back are a restore from backup or undoing it by hand. That single exception, made once, is how a large share of the environments we are asked to take over reached the state they are in.

Take them out of the components. Every value that differs between environments becomes an environment variable, and every connector a flow uses becomes a connection reference, so that no component contains an endpoint, a site address or an identity directly. Then run pac solution create-settings against the packed artifact to generate a deployment settings file listing all of them, keep one filled copy per environment in the repository, and pass the right one to pac solution import at release time. Secrets stay as placeholders in the committed file and are substituted by the pipeline from its own secret store. Teams that skip this get a first pipeline that deploys perfectly and then quietly reads and writes development data from production, which typically goes unnoticed for a fortnight.

The first thing to check is the version number, because an import of a solution whose version was not incremented can complete successfully while the platform continues serving what it already had. Stamping the version in the build stage with pac solution version removes that failure mode entirely. The second thing is publishing, since some changes are inert until customizations are published, which is what the publish changes option on import is for. The third is that a plain import updates and adds but never deletes, so if what you expected was a removal rather than a change, it will not have happened and you need a staged upgrade instead. And the fourth, which is less common but wastes the most time, is a dependency that exists in the development environment but not in the target, so a component imported without the thing it depends on and behaves as though it is not there.

For many mid sized teams the in product pipelines feature is the right answer and it is available in a day, because it promotes solutions between environments with approvals and needs no YAML, no agent and no separate tool to administer. Choose Azure DevOps or GitHub Actions when the release has to do more than move a solution: build a plugin assembly or a PCF control from the same commit, run tests, run the solution checker as a gate, deploy configuration data, or coordinate with something outside this platform. Also choose them when your organisation already runs one of the two, because the pipeline that gets maintained is the one sitting in the tool people already open. It is a reversible decision either way, and it is far less important than whether the solution source is in a repository at all.

Not with the pipeline. Start with pac solution list against every environment and an honest inventory of what each one holds, including how much sits in the default solution, which is where anything made directly in an environment ends up. Then reconcile the publisher and prefix, decide the solution boundaries, and take a baseline of development into Git. The slow part, and it is genuinely slow, is going through the changes that exist only in production and deciding one at a time whether each is wanted, rebuilding the wanted ones properly in development so they arrive through the pipeline, and removing the rest. Until that is done the repository is not the source of truth and a pipeline is only automating a fiction. This is the shape of work we do as a project rescue, and it is described on our project rescue and takeover page.

In a fixed order. First inventory every environment and solution, using pac admin list for the environments and pac solution list plus the solution layers view for what each one holds. Second, separate configuration data from schema, moving reference data with the Configuration Migration tool or pac data and a committed schema file. Third, move every value that differs per environment or client into environment variables and connection references, with a deployment settings file per client per environment. Fourth, make every downstream environment managed only, with unmanaged work confined to development. Fifth, give every client the same release template: a shared core solution plus a client extension solution with its own publisher. Only then automate it with the Power Platform CLI and one parameterised pipeline in Azure DevOps, GitHub Actions or Power Platform Pipelines.

The core tools are free: the Power Platform CLI, Power Platform Build Tools for Azure DevOps, GitHub Actions for Power Platform and the Configuration Migration tool carry no charge of their own. Azure DevOps and GitHub have their own plans for users and pipeline usage. Power Platform Pipelines, the in product option, requires the target environments to be Managed Environments according to Microsoft documentation, and Managed Environments need qualifying premium licences for their users. Additional environments also draw on tenant Dataverse capacity. Microsoft revises licensing regularly, so confirm the current position with Microsoft or your licensing partner before choosing a route on cost grounds.

A shared core with client extensions, almost always. Copies of one solution per client diverge within months, and every fix then has to be applied several times by hand. A shared core solution, released as the same managed artefact to every client, plus a thin extension solution per client with its own publisher and prefix, keeps the common product in one place and the differences visible. Values that differ between clients belong in environment variables and deployment settings files rather than in the extension. The exception is a client whose requirements have genuinely become a different product, where a separate solution line is more honest than an extension that overrides most of the core.