Dataverse Plugin Packages Are Code-First Now. Your Azure DevOps Pipeline Still Has to Script Around Them.

Solutions architect and developer reviewing a Dataverse deployment pipeline diagram on an office monitor

A solutions architect on a mid-size D365 F&O implementation recently ran into a problem that had nothing to do with business logic. Her team had finally moved their plugin assemblies into proper NuGet-based Dataverse plugin packages, the newer code-first model that the Power Platform CLI now supports directly. The build worked. The package generated correctly. And then the pipeline stalled, because nobody could answer a simple question: how do you tell Azure DevOps to actually deploy the thing you just built, when Microsoft’s own build tools extension has no task for it?

That gap is worth understanding in detail, because it sits at the exact point where Dataverse plugin development is genuinely improving and where its ALM tooling has not caught up.

Solutions architect and developer reviewing a Dataverse deployment pipeline diagram on an office monitor

From Manual Registration to Code-First Packages

For most of the last decade, deploying a Dataverse plugin meant compiling a class library in Visual Studio, opening the Plugin Registration Tool, and manually selecting an assembly to register or update. It worked, but it kept plugin deployment outside the discipline that governs everything else in a mature ALM pipeline: predictable artifacts, versioned builds, and a repeatable path from commit to environment.

The Power Platform CLI changes that equation with two commands: pac plugin init, which scaffolds a plug-in class library project, and pac plugin push, which imports the resulting artifact into Dataverse. The output of a build is no longer a loose assembly file. It is a NuGet package, generated automatically in the bin\outputPackages folder on every build, containing the plugin assembly and its dependencies bundled together. That single change, treating the plugin as a proper package rather than a file you happen to compile, is what makes plugin code finally look like the rest of a modern .NET pipeline.

What Dataverse Plugin Packages Actually Solve

The practical win is dependency handling. Under the old model, any third-party or shared library your plugin referenced had to be merged into the assembly or registered separately, and both approaches created their own headaches around versioning and duplication across solutions. A plugin package bundles dependent assemblies inside the same NuGet artifact, so the whole thing deploys and updates as one unit.

Signing works differently here too, and it is worth getting the policy decision right early rather than discovering it mid-project. Microsoft’s own guidance is explicit that signing is all-or-nothing: if the primary plugin assembly is strong-name signed, every dependent assembly in the package must be signed as well. Most teams find this impractical once they start pulling in third-party libraries they do not control, which is why pac plugin init exposes a --skip-signing flag, and why it has effectively become the default choice for anyone using dependent assemblies rather than a single self-contained plugin.

The Immutability Trap

Here is where the model’s real character shows up, and where a team can get burned if nobody flags it in advance. Once a plugin package is created in Dataverse, its name and version are fixed. An attempt to change either afterward, including through the API, simply fails. Every build produces a package with a new version embedded in its filename, which means there is no such thing as “redeploy the same package again.” Each build is a new, uniquely identified artifact from Dataverse’s point of view, whether you intended that or not.

That has two consequences that matter for pipeline design. First, if a plugin update removes an assembly or a type that is still referenced by an active plugin step registration, Dataverse rejects the update outright. You have to go remove or repoint those step registrations first, then update the package, not the other way around. Second, you cannot unregister a package at all while any of its assemblies still have active step registrations attached to them. Both rules are sensible from a data-integrity standpoint, but they mean plugin retirement has to be sequenced deliberately: deregister the steps, confirm nothing else depends on the assembly, and only then remove or replace the package.

One independent practitioner account, documented on the .NET Dust blog in 2024, captured how disruptive the versioning behavior can be during ordinary iterative development, well before any pipeline is involved. Because pac plugin push has no built-in notion of “the current build,” the developer had to script around it: an MSBuild target increments the file version before compilation, a post-build event persists that value into the project file through a small helper utility, the NuGet package picks up the new version automatically, and only then does an automated pac CLI call push the exact resulting filename. What should be a single command turned into a four-step workaround, built by one engineer, to get a repeatable local deployment loop. That is a reasonable thing for an individual developer to solve on their own machine. It is not something you want reinvented independently by every team building a Dataverse ALM pipeline.

The Build Tools Gap

That last point is the one worth taking to whoever owns your ALM strategy. Microsoft’s Power Platform Build Tools extension, the standard toolkit for Dataverse pipelines in Azure DevOps and GitHub Actions, covers an extensive set of operations: importing, exporting, packing, and unpacking solutions, applying upgrades, managing environments, running the Power Platform Checker, and even a preview set of catalog-submission tasks. Reviewing the current task reference, plugin packages and pac plugin push are not among them. There is no first-class, Microsoft-supported pipeline task for deploying a plugin package, in contrast to the mature tooling that already exists for solutions.

In practice, that means every team adopting code-first plugin packages has to write its own pipeline stage: typically a script task that installs a pinned version of the PAC CLI, authenticates against the target environment (a service principal, not a personal login, for anything beyond a developer sandbox), locates the build output, and issues the push. None of that is exotic engineering. It is, however, unsupported custom scripting sitting next to a set of Microsoft-maintained tasks that get security updates, documentation, and predictable behavior across CLI versions. That asymmetry is easy to miss until a CLI update quietly changes an argument name and a script that nobody has looked at in eight months starts failing in production.

Developer typing on a laptop with a monitor showing an abstract NuGet package deployment graphic

Building This Into an ALM Pipeline Properly

A few decisions are worth making explicit rather than leaving to whichever developer happens to write the first plugin deployment script. Pin the PAC CLI version in the pipeline definition itself, not just on developer machines, so a CLI upgrade cannot silently change push behavior in production. Treat the plugin push step as its own reviewed pipeline stage with the same environment gating and approval flow as solution deployment, rather than a script someone bolted on during a sprint to unblock a release. Decide the assembly-signing policy at the team or center-of-excellence level, since the all-or-nothing signing rule effectively locks in a convention for every future package once dependent assemblies enter the picture.

Sequence retirements carefully. Before removing or consolidating an old plugin package, confirm which step registrations still point at it and clear those first, since Dataverse will otherwise block the change regardless of what your pipeline script assumes should happen. And build the versioning logic into the pipeline itself, following the pattern the .NET Dust workaround demonstrated, rather than trusting a developer’s local environment to produce a consistently versioned artifact that a shared pipeline can then find and deploy.

None of this makes the code-first plugin package model a bad idea. It is a genuine improvement over registering assemblies by hand through a desktop tool, and it brings plugin code closer to how the rest of a .NET codebase is built and shipped. The catch is that Microsoft shipped the authoring half of that story before the deployment half, and the gap between them is exactly where implementation teams are currently improvising. Firms that have already built Dataverse ALM pipelines from the ground up, Routeget Technologies among them, have generally closed that gap with a small, explicitly maintained script stage rather than an ad hoc one, which is the difference between a pipeline that survives a CLI version bump and one that quietly breaks the next time someone updates it.

#Dataverse #DataversePlugins #PowerPlatformALM #AzureDevOps #ExtensibilityAndProDev #EnterpriseArchitecture

The Power Pages Enhanced Data Model Migration Tool Reached GA. The Four Templates That Couldn’t Move Now Can.

Solution architect reviewing data migration dashboards on a dual-monitor workstation in a modern office

The Migration That Kept Getting Delayed

If you have maintained a Dynamics 365 Customer Self-Service, Partner, Community, or Employee Self-Service portal since before the Power Pages rebrand, you have almost certainly run into this wall: everything Microsoft has shipped for Power Pages application lifecycle management over the last three years, solutions support, Power Platform pipelines, environment variables, faster provisioning, has applied only to sites built on the enhanced data model. Your site, built on the standard data model with its familiar adx_ prefixed tables, has been sitting outside that perimeter the entire time. You could read every announcement, watch every demo, and still not be able to touch any of it, because the migration tooling that was supposed to bring your site along explicitly excluded the four Dynamics 365 portal templates. That changed on September 7, 2026, when Microsoft moved the standard-to-enhanced data model migration utility in the Power Platform CLI to general availability and, for the first time, extended it to Customer Self-Service Portal, Employee Self-Service Portal, Community Portal, and Partner Portal sites.

This is not a small technical footnote. For a lot of organizations running production portals on these templates, it is the first realistic path off a data model that Microsoft has been quietly deprecating in practice, if not in name, since 2023.

What the Standard Data Model Was Actually Costing You

The distinction between the standard and enhanced data models is not cosmetic. On the standard data model, website configuration lives in a set of legacy adx_ entities: adx_webpage, adx_webrole, adx_weblink, and so on. Those tables were never built for the deployment discipline that modern ALM assumes. Configuration changes get made directly against a live environment, promotion between environments means manually reconciling records or wrestling with unmanaged solution exports, and Microsoft has to maintain backward compatibility with a table structure that predates Dataverse solution awareness altogether. The enhanced data model consolidates that configuration into the newer powerpagecomponent table structure, which is solution-aware, supports environment variables, and plugs directly into Power Platform pipelines. Sites on the enhanced data model also provision faster and pick up feature and security updates automatically, rather than waiting on package installs that someone on your team has to remember to schedule.

None of this was news. What was missing, until this month, was a supported way to get an existing site there without rebuilding it from scratch. Microsoft’s own documentation was blunt about the gap as recently as March 2026, stating outright that sites created with the four Dynamics 365 templates could not be migrated and that only new sites on those templates would land on the enhanced data model. If you were running a production Partner Portal from 2021, your only two options were live with the limitation indefinitely or replatform the entire site.

What the Enhanced Data Model Migration Utility Shipped at GA

The migration utility itself is not new. Microsoft first previewed pac powerpages migrate-datamodel back in April 2024, and it worked reasonably well for the templates it supported: starter layouts, application processing, blank page builds, program registration, and scheduling sites. What reached general availability on September 7 is both a maturity milestone and a scope expansion. The scope expansion is the four Dynamics 365 templates finally being added to the supported list, which is the headline for most technical teams reading this. The maturity milestone is three specific capabilities that were not reliable enough to trust in preview: a genuinely useful customization dependency report that tells you what will break before you commit to anything, a status-check command so you are not guessing whether a large migration job is still running or has stalled, and a formal rollback path if validation turns something up after the data has moved.

Running the migration itself still follows the same sequence architects who piloted the preview will recognize. You authenticate against the target environment, generate a customization report scoped to a specific website ID, and read that report closely before doing anything else, since it is the tool telling you exactly which of your customizations depend on tables that will not exist in the same form once you move. From there, you migrate configuration data and, separately, transactional data referencing that configuration, using mode flags that let you split the work rather than attempting a single all-or-nothing pass. A status-check command lets you monitor long-running jobs on sites with meaningful data volume, and only once you are satisfied do you run the command that actually switches the site over to serve from the enhanced data model record. The CLI now requires Power Platform CLI 2.11.2 or later, along with updated Dataverse base portal and Power Pages core packages, so confirm your tooling versions before you start rather than discovering a version mismatch mid-migration.

Close-up of a developer typing CLI migration commands with terminal windows and a data flow diagram in the background

The Five Things That Will Actually Break

The customization report is useful precisely because most Dynamics 365 portal implementations that have been running for several years have accumulated customizations the original template never anticipated, and those are where the real work lives. Five categories come up consistently. Custom columns added directly to the legacy adx_ metadata tables have no equivalent in the enhanced schema, so you will need to stand up a new custom table, add a lookup back to powerpagecomponent, and migrate the data across rather than expecting an automatic mapping. Relationships built between your custom tables and the old adx_ tables need to be recreated against their powerpagecomponent equivalents, which means auditing your solution for every such relationship before you migrate, not after. Liquid code that references entities directly, something like assigning a variable from entities[‘adx_weblinks’], needs to be rewritten to use the corresponding Liquid object instead, since the enhanced data model does not expose those legacy entity names the same way. FetchXML embedded in Liquid templates that queries adx_ entities by name has to be rewritten against powerpagecomponent with a componenttype filter, and getting that filter value wrong is a common source of queries that silently return nothing rather than failing loudly. Finally, any custom plugins or classic workflows registered against the old tables need to be re-registered against their enhanced equivalents, which is easy to forget if that logic was written by a developer who has since moved on and the automation itself has been running quietly in the background for years.

None of these are migration blockers on their own. They are the reason the customization report exists, and the reason this gets treated as a project with a real test phase, not a command run against production on a Friday afternoon.

How to Actually Run This

Start on a full copy of the production environment, not a shared sandbox someone else is also using that week. Run the customization report first and treat it as your scope document: every item it flags becomes a line in your migration plan, and if it flags nothing, that itself is worth double-checking against a manual review of your solution, since undocumented customizations from years back do not always get picked up cleanly. Migrate configuration data and configuration data references as separate, deliberate steps rather than reaching for the combined mode on a first attempt, since separating them gives you a natural checkpoint to validate before moving transactional data. Watch your table sizes going in: the migration processes records in batches of five thousand, so a site with a large volume of case records, form submissions, or forum content tied to configuration should expect the migration job to take real time, and you should plan your maintenance window accordingly rather than assuming it finishes in minutes. Once the migration completes, work through the five customization categories above methodically against your report before you consider the environment production-ready, and only then schedule the actual cutover during a low-traffic window given that end users will be locked out or degraded while the switch happens.

Treat this as a two-track modernization rather than folding it into the separate Bootstrap 5 template migration Microsoft made generally available for these same four templates back in June. One is about the underlying data model and ALM story, the other is about front-end markup and CSS, and combining them multiplies your testing surface for no real benefit. Sequence the data model migration first, stabilize, then take on Bootstrap as its own scoped effort.

Why This Is Worth Prioritizing Now

Every enhanced-data-model-only feature Microsoft has shipped since 2023 stays out of reach until you make this move, and the pace of that list is not slowing down. In our work at Routeget Technologies with legacy Dynamics 365 portal environments, we have consistently seen operational overhead trace back to being stuck on manual package management and unmanaged solution exports, simply because migrating never had a supported path for the specific template a client was running. That excuse is gone now. The work is not trivial, and the five customization categories above are real effort, not boilerplate. But for a portal your organization depends on, closing that ALM gap and getting onto a data model Microsoft is actively investing in is a better use of a sprint than continuing to work around a limitation that no longer needs to exist.

#PowerPages #EnhancedDataModel #PowerPlatformALM #DynamicsPortalMigration #LowCodeGovernance #PowerPlatformCLI

The Dataverse Git Integration GitHub Preview Needs a Key Vault, Not Just a Login

An IT solutions architect presenting a software deployment pipeline diagram on a large office monitor

A Power Platform ALM engineer at a mid-market manufacturer spent a Tuesday afternoon trying to move a client’s Dataverse Git integration off Azure DevOps and onto GitHub, where the rest of the company’s engineering org already lived. The Azure DevOps connection had taken fifteen minutes to set up the year before: sign in, pick a project, pick a repository, done. She assumed GitHub would be the same flow with a different login screen. Four hours, one Azure Key Vault resource, one GitHub App registration, and one role assignment to a service principal she’d never heard of later, she had a working connection, and a much clearer idea of why Microsoft shipped Azure DevOps support first.

That gap between expectation and reality is worth understanding before any team commits to the GitHub option, because it is not a bug or an oversight. It reflects a real architectural difference in how the two providers authenticate, and it changes the planning and staffing conversation for anyone treating this as a same-day migration.

An IT solutions architect presenting a software deployment pipeline diagram on a large office monitor

What Dataverse Git integration actually does

Dataverse Git integration is Microsoft’s native, in-product answer to a problem that Power Platform teams have patched around for years: getting solution components out of an environment and into a real source control history without standing up a full pro-dev toolchain. Instead of relying solely on the Power Platform CLI, Azure Pipelines, and a developer’s local machine to export, unpack, and commit solution XML, makers and admins can now connect an unmanaged solution directly to a Git repository from inside make.powerapps.com, commit changes as they’re made, and let Power Platform Pipelines handle promotion to test and production from there.

The mechanics matter because they explain the limits. Only unmanaged solutions in development environments connect to Git; managed solutions still move downstream through Power Platform Pipelines, not through branch merges. Component changes sync to a human-readable, YAML-based file format designed to diff cleanly, a deliberate departure from the sprawling XML that classic solution exports produce. And a full solution commit is atomic: you cannot cherry-pick individual component changes within a solution the way you would stage individual files in a typical Git workflow. Teams coming from a code-first background, expecting Git semantics all the way down, tend to hit that ceiling first.

Azure DevOps was the first provider Microsoft supported, and it reached general availability well ahead of GitHub. The connection setup leans on infrastructure Azure DevOps and Dataverse already share inside the same Microsoft Entra tenant: create a project with Git version control enabled, confirm the connecting user has Contributor access to the repository, enable managed environments on both the source and target environments, and connect from the solution’s source control panel. There is no separate secrets store to provision and no custom application registration required, because the trust relationship rides on existing Azure identity.

Why the GitHub path looks different

GitHub support entered public preview in the 2026 release wave 1 cycle, and the setup reflects the fact that GitHub sits outside the Azure AD trust boundary that made the Azure DevOps connection comparatively simple. Rather than a native OAuth handshake alone, the documented path requires registering a dedicated GitHub App under organization settings, granting it read-and-write access to repository contents, generating a private key for that app, and then storing that key somewhere Dataverse can retrieve it securely. That somewhere is Azure Key Vault, in the same Microsoft Entra tenant as the Dataverse environment, which means a team without an existing Key Vault footprint is now standing one up specifically to support source control.

Abstract illustration of a secure vault connected to a code repository network and a cloud identity shield, representing credential management between GitHub and Dataverse

The chain continues from there. After the private key lands in Key Vault, the environment’s own managed identity, provisioned automatically as something like PPMI-githubappconfigmanagedidentity followed by a GUID, needs the Key Vault Crypto User role assigned to it through Key Vault’s access control settings before Dataverse can actually use the stored credential. Only after that RBAC assignment resolves does the GitHub connection in the solution’s source control panel have what it needs to authenticate. None of this is exposed as a single wizard; it’s a sequence across GitHub’s developer settings, the Power Apps maker portal’s Connections page, and the Azure portal, and a missed step in any of the three stops the whole chain cold with a generic authentication failure that doesn’t point back to which link broke.

Two additional constraints are worth flagging before a team plans around this path. GitHub-based connections are not currently compatible with Dataverse environments that have virtual network support enabled; if VNET injection is part of your environment’s security posture, the documented workaround is a GitHub personal access token instead of the OAuth connection, which trades one credential management problem for another. And if the organization has restrictions on third-party OAuth application access, which many regulated enterprises do by default, an org admin has to explicitly approve the GitHub App before any maker can complete the connection, adding an approval-queue dependency that Azure DevOps setups don’t carry.

Planning the rollout instead of the demo

None of this makes the GitHub option a bad choice. For an organization that has already centralized its application source, its pull request review culture, and its CI/CD runners around GitHub, keeping Power Platform solutions in a second, Azure DevOps-only silo creates its own governance problem: two source control systems, two access review processes, two places an auditor has to look. The GitHub preview closes that gap. It just closes it with real infrastructure work attached, not a checkbox.

Two prerequisites tend to get discovered late rather than planned for. Managed environments must be enabled on every environment in the chain, development and target alike, and that entitlement itself is included at no extra cost with standard Power Apps, Power Automate, Copilot Studio, Power Pages, and Dynamics 365 licenses, but explicitly excluded from the Developer Plan. A team piloting this in a free developer environment will hit a wall before they hit the GitHub App registration screen. Second, this is explicitly documented as a preview capability intended for development environments only, not test or production, so any rollout plan that assumes it is production-ready today is planning against documentation that says otherwise.

The practical sequencing that avoids the four-hour surprise looks like this: confirm managed environments are already enabled or budgeted for, decide up front whether VNET requirements in any target environment rule out the OAuth path in favor of a PAT, and treat the GitHub App registration, Key Vault provisioning, and managed identity role assignment as three discrete, ownable tasks rather than one setup step, ideally assigned to whoever already owns Key Vault and Entra app registrations in the organization rather than the Power Platform maker who happens to be doing the connecting. Teams that scope it that way tend to get through it in an afternoon. Teams that treat it like the Azure DevOps flow tend to get the same four-hour afternoon the engineer in the opening scenario had, just with more frustration attached.

Routeget Technologies has walked several clients through exactly this kind of ALM tooling decision, usually as part of a broader review of where Power Platform governance sits relative to the rest of an organization’s engineering practices. The right answer isn’t universally GitHub or universally Azure DevOps; it’s whichever one matches where the organization’s source of truth already lives, evaluated with the actual setup cost in view rather than the marketing description of “now supports GitHub.”

For architects scoping this now, the preview label matters less than the identity and secrets infrastructure it assumes you’re willing to stand up. If that infrastructure already exists in your tenant, the GitHub path is a reasonable few hours of work. If it doesn’t, budget for building it before you budget for the migration itself.

#DataverseGitIntegration #PowerPlatformALM #GitHubIntegration #EnterpriseDevOps #ITGovernance #PowerPlatform

What Actually Breaks First in a Power Apps Code Apps Rollout

Developer reviewing a Power Apps code app in a code editor next to a web application preview

A team at a mid-market manufacturer spent three weeks building their first Power Apps code app: a React front end wired to Dataverse through the generated TypeScript services, styled with Fluent UI, running clean in local development. The day they pushed it to their first pilot users, the app loaded, authenticated through Microsoft Entra ID without a single line of auth code, and then silently failed to render three of its five widgets. The culprit wasn’t a bug in their code. It was a tenant-wide Content Security Policy that Microsoft had already turned on weeks before their app was even scaffolded, quietly blocking every request to a domain outside the Power Apps allowlist. Nobody on the project had heard of it, because nobody had read the message center post that announced it.

That kind of surprise is a fair preview of what a Power Apps code apps rollout actually looks like right now. Since February 5, 2026, Power Apps code apps have been generally available, letting developers build full front-end web applications in React or Vue inside a code-first IDE like Visual Studio Code, then run and host those same apps inside the managed Power Platform, with the platform handling authentication, connector access, and lifecycle management underneath. For architects who have spent years explaining why a canvas app can’t do what a pro-code team needs, this closes a real gap. GA status makes it easy to underestimate three things that behave nothing like a typical canvas app rollout, though: a content security policy that was already enforcing before most organizations had even piloted the feature, a licensing model built around Premium seats rather than the cheaper per-app plan many teams still lean on for canvas apps, and an ALM story that looks familiar until you notice which pieces are missing.

The CLI Workflow, In Practice

A code apps project starts from the pac code command group in the Power Platform CLI rather than from the maker portal. After scaffolding a project (Microsoft’s own quickstart pulls a Vite template via degit), pac code init --displayname "App Name" registers the app against an environment and writes a power.config.json file tying the local project to that registration. Adding a Dataverse table as a data source looks like this:

pac code add-data-source \
  -a "shared_commondataserviceforapps" \
  -c "<connection-id>" \
  -t "accounts"

That command handles the unglamorous but genuinely useful part of the job: it generates a typed service class in ./generated/services/, so the resulting TypeScript reads like AccountsService.getall() and AccountsService.create({ name: "Contoso Ltd" }) rather than hand-rolled HTTP calls against the Dataverse Web API. The connection itself, though, has to already exist in make.powerapps.com. The CLI wires up access to an existing connector connection; it does not create one. That means whoever owns the pilot needs a connections strategy in place before a developer ever opens an editor. Once the app is built, npm run build followed by pac code push ships it to the platform, where it inherits the same sharing limits, quarantine behavior, and Conditional Access controls that already govern canvas apps in that environment.

That inheritance is the real point of running code apps inside Power Platform instead of standing up a bespoke Azure Static Web App: Data Loss Prevention policies still apply at runtime, tenant isolation and Azure B2B rules still apply, and the app shows up in Power Platform Monitor for health telemetry the same way any other maker-built app would. None of that governance has to be rebuilt by hand.

Developer working on a code apps project across two monitors showing a code editor and a web application preview

Where the CSP Wall Actually Sits

Microsoft began enforcing a strict Content Security Policy against code apps in two stages: introduction on January 26, 2026, and full enforcement on January 30, 2026, communicated through message center post MC1218747. Past that date, any request a code app makes to a domain outside the Power Apps allowlist gets blocked by default, silently, at the browser level. The app itself keeps running. It’s the fetch calls to a third-party API, the image tags pointed at an external CDN, or a web font loaded from outside Microsoft’s own domains that quietly stop resolving, which is exactly the kind of failure that reads like a rendering bug rather than a policy block until someone actually opens the browser console.

The fix isn’t difficult, but it has to happen before a real rollout rather than after users start filing tickets. Microsoft’s own guidance describes a five-step sequence: temporarily disable the “Enforce content security policy” setting in the Power Platform admin center, turn on CSP reporting instead, exercise the app enough to surface every external domain it actually calls, add those domains to the allowlist, and only then re-enable enforcement. Skip the reporting step and jump straight to a hand-built allowlist, and a team ends up chasing one broken image or one failed API call at a time, across three environments, for weeks.

The License Model Nobody Priced In

The other assumption worth checking before a pilot expands past a handful of users is licensing. Microsoft’s documentation is specific on this point: end users running a code app need a Power Apps Premium license, full stop. That catches teams who assumed code apps would ride along on whatever licensing already covers their canvas apps, particularly organizations that still lean on the per-app plan for cost control. That plan is in the middle of its own wind-down: as of January 2, 2026, it’s no longer available for purchase by new customers, though existing Enterprise Agreement and Cloud Solution Provider customers can keep renewing it under current terms, and MPSA customers get a 60-day migration window after their agreement ends. None of that grandfathering helps a team piloting code apps for the first time this year, because a per-app license was never going to cover a code app to begin with. The practical move for an architect scoping a rollout is to put the Premium requirement into the business case during the first conversation with finance, not to let it surface when the pilot tries to onboard its fifteenth user.

What ALM Actually Covers, and What It Doesn’t

Solution architects evaluating code apps for a broader rollout should also be honest about what doesn’t carry over from the rest of the Power Platform toolbox. Native Power Platform Git integration doesn’t support code apps today, so a team can’t rely on the same solution-based source control workflow it might use for a model-driven app. The practical workaround is treating the code app’s own repository as the system of record and running a standard CI pipeline against it, GitHub Actions calling pac code push after a build step is a common pattern, rather than expecting Dataverse solutions to manage the app’s lifecycle end to end. Code apps also can’t run offline, aren’t supported in the Power Apps app for Windows, don’t support Secure Implicit Connections, and can’t be embedded inside other app types except through a Power BI Visual. For a field service scenario that genuinely needs offline capability, or a mobile-first workflow, this rules code apps out entirely. They’re built for client-side, standalone, always-connected line-of-business scenarios, and treating them as a drop-in replacement for every canvas app on a roadmap produces a project that fights the platform instead of one that benefits from what GA actually delivered.

Solution architects reviewing a governance and security policy dashboard in a meeting room

Planning a Power Apps Code Apps Rollout

None of this argues against adopting code apps. It argues for sequencing the rollout the way any new application platform deserves, rather than the way a low-code feature update usually gets treated. Before the first pilot ships to real users, confirm the environment has code apps enabled deliberately, through Settings, Product, Features, rather than left to whichever admin happened to click through a prompt. Run the CSP disable-report-allowlist-reenable cycle against the actual pilot app, not a hello-world sample that calls no external services and tells an architect nothing useful. Get Premium licensing into the cost conversation before the user list grows past the pilot group, not after. And decide early which category of app actually belongs here: a case-management tool for an internal finance team, wired to Dataverse and a couple of line-of-business connectors, is a strong fit. A field technician’s offline inspection app is not, regardless of how appealing the React tooling looks to the team building it.

Code apps are a genuine expansion of what Power Platform can host, and for organizations with pro-code developers sitting next to citizen developers, they finally give both groups a shared platform instead of two disconnected ones. Getting there without a production incident, though, means treating the CSP policy, the licensing model, and the ALM gaps as part of the architecture decision, not as details to sort out after the first app is already live. Routeget’s team has walked several clients through exactly this sequencing on early code apps pilots, and the pattern holds: the rollouts that go smoothly are the ones where governance and licensing get scoped in the same week as the first line of code, not after the first support ticket comes in.

#PowerAppsCodeApps #PowerPlatformGovernance #PowerAppsLicensing #ContentSecurityPolicy #PowerPlatformALM #EnterpriseAppDev