Power Pages Configuration Keeps Vanishing Between Environments: A Repeatable Deployment Method

Why does Power Pages configuration disappear when you move a site between environments?

Because a Power Pages site is two different things, and most deployment methods only move one of them. The first is ordinary solution metadata: the Dataverse tables, columns, forms, views, cloud flows and plug-ins the site reads and writes. The second is the site itself: pages, templates, web roles, table permissions, site settings, snippets, web files, redirects, lists and forms, all stored as rows in Dataverse tables.

Export a solution from development and import it into test, and the first part arrives. The second part only arrives if those rows were deliberately included, and in the standard data model they are not solution components at all. The result is a site in test that renders but has no permissions, the wrong authentication settings, missing navigation or pages that return errors because a form refers to something that is not there.

The general move from ZIP files to the Power Platform CLI and pipelines is covered in our Power Platform ALM guide. This page is the part that guide does not cover: the site records.

What is the difference between the standard and enhanced data model for deployment?

It decides where the configuration lives and whether solutions can carry it. Check which model each site uses before choosing a method, because the CLI needs to be told and the answers differ.

What should go in a managed solution and what should move with pac pages upload?

Put everything the platform treats as a component into solutions, and move site records with the CLI unless you are on the enhanced model and have chosen to carry the site through solutions. Whichever you choose, do not mix routes for the same records, or two deployments will fight over which version wins.

How do you move a site with pac pages download and pac pages upload?

Treat the downloaded folder as the source of the site, exactly as the unpacked solution is the source of the solution. The command group was called pac paportal before it became pac pages, and names and flags continue to change, so confirm them with pac help for your installed version before scripting anything.

• Authenticate to the development environment with pac auth create, then run pac pages list to find the website identifier.
• Run pac pages download with --path, --webSiteId and --modelVersion to write the site to a folder, and commit that folder.
• Deploy the managed solution with the tables, forms, views and flows to the target environment first.
• Authenticate to the target with a service principal that has the rights to write the site tables, and run pac pages upload with --path, --modelVersion and --deploymentProfile for that environment.
• Upload only sends changed files by default; use the option to force a full upload for the first deployment to a new environment, after checking its name in pac help.
• If the target has no site bound to the uploaded records yet, create or reactivate the site against them in Power Pages, following current Microsoft documentation for your model.
• Clear the site cache or restart the site from the admin tools if changes do not appear, then run the verify step below.

How do deployment profiles keep environment-specific site settings out of manual edits?

A deployment profile is a YAML file in the downloaded site's deployment-profiles folder, named after an environment, that overrides chosen record values when you upload with --deploymentProfile. Instead of someone editing the authentication site settings in test after every release, the test profile holds the test values and the upload applies them.

Use profiles for anything that differs by environment: identity provider settings such as authority and client identifiers, redirect and callback URLs, external service endpoints, analytics keys, feature flags held in site settings, and snippets that show an environment banner. Keep secrets out of the file, and supply them from the pipeline or set them in the target once. Check current Microsoft documentation for which tables deployment profiles can override in your version.

In the enhanced model, when the site is deployed through solutions, the equivalent is a site setting that reads a Dataverse environment variable, whose value is supplied by the deployment settings file on import. That keeps site settings in the same mechanism as the rest of your solution ALM.

Which Power Pages records are routinely missed in a deployment?

These are the gaps we find when a site in test does not match development. Most are missed because a team deployed only what it had just changed, or because the item lives outside Dataverse and no file could ever have carried it.

How do you version many client Power Pages sites in Git so they all move the same way?

Make every site look identical from the outside: same folder layout, same profile names, same pipeline, different values. An agency or partner running many client sites loses configuration when each site was set up by a different person with a different habit, not because the CLI is unreliable.

• One repository per client, or one per site, containing the solution source and the downloaded site folder side by side, so the site and the tables it depends on are versioned together.
• Fixed profile names in every site, such as test and prod, so the pipeline never needs to know which client it is deploying.
• One pipeline template, in Azure DevOps or GitHub Actions, that deploys the solution, uploads the site with the matching profile and runs the verify step, referenced from each repository rather than copied.
• A service principal per client environment, with credentials held in the pipeline's secure variables, so nobody deploys as a person.
• A shared baseline, such as common templates, web files and a header include, kept in its own versioned folder or package and copied into sites deliberately, never edited in place in fifteen places.
• A rule that production is changed only by the pipeline, and that content edits made by clients in production are downloaded and committed before the next release so they are not overwritten.
• A short README per site recording its data model version, website identifier per environment and the admin center settings that live outside the repository.

How do you verify before go-live what did not come across?

Compare, do not assume. A deployment that finished without errors only proves that what was uploaded was accepted, not that the target matches the source.

• After upload, run pac pages download against the target into a separate folder and diff it against the committed folder. Differences outside the values your deployment profile changes are exactly what did not come across, or what someone changed by hand.
• Count records per site table in source and target, such as web roles, table permissions, site settings, snippets and redirects, and investigate any mismatch.
• Produce a matrix of web roles to table permissions with access type and scope from both environments, and compare it line by line. This is the check that catches a security gap before a customer does.
• Sign in to the target as a test contact in each web role and walk the main journeys, including a list, a form submit and any flow call.
• Test a sample of redirects, the sign-in and sign-out journey, and pages for anonymous visitors.
• Tick off the admin center checklist for the environment: domain, certificate, visibility, IP restrictions and firewall settings.
• Keep the diff output and checklist with the pipeline run, so the release has evidence of what was verified.

How do you avoid overwriting content that was edited in production?

Decide who owns what before the first release. Content editors legitimately change snippets, page copy and web files in production, and an upload from a repository that does not contain those edits will quietly put the old text back.

The simplest working rule: developers own templates, code, permissions and settings, which change only through the repository; editors own a named set of snippets and page copy. Before each release, download production and commit any editor changes, then build the release from that. If code lives in page copy, that rule cannot hold, which is one reason to move it out as described in our guide to custom JavaScript and Liquid in Power Pages. Permissions deserve particular care, because an overwritten table permission is a security change; our table permissions guide covers designing and testing them.

Should a portal with this deployment effort stay on Power Pages?

For most organisations on Dataverse, yes. Once the solution, the site folder, deployment profiles and a verify step sit in one pipeline, moving a site becomes as routine as any other release, and what a Power Pages build covers is on our Power Platform consulting page.

We recommend the right solution - whether that's Microsoft Dynamics 365, Power Platform, or a custom-built CRM. Some businesses need the Microsoft ecosystem. Others need full control without licensing. We deliver both. If the portal is really a bespoke application with Power Pages underneath, or Microsoft licensing does not fit the audience, a custom-built CRM or front end on React, Node.js, PostgreSQL or .NET deploys like any other web application, with all configuration in code from the start. Our Power Pages or custom front end comparison helps settle that choice.

How does Solzet help deploy Power Pages sites between environments reliably?

We start with the site that hurts most: download it from every environment it lives in, diff them to find what has drifted, and agree which version is right. Then we put the solution and site folder into one repository, create deployment profiles per environment, move secrets out of files, build the pipeline with the verify step and document what lives in the admin center. For agencies and partners with many client sites, we turn that into a template every site adopts in turn.

The work is done by senior consultants and full-stack developers delivering remotely from Yerevan, Armenia, with 8+ years of Dynamics 365 Customer Engagement and Power Platform work, directly for your team or white-label for Microsoft partners. Solution ALM beyond the site is covered in our PAC CLI and pipelines guide, and wider Power Pages delivery sits with our Power Platform consulting service.