Managed Environments and the Pipelines Deadline: Count Your Users Before You Flip the Switch

If your pipelines deploy to environments that aren't managed, you have a decision to make within 30 days of the notice, and it is not a checkbox. Managed Environments have no separate price: they are included with premium Power Platform and Dynamics 365 licenses. The cost is that everyone who runs apps and flows in the environment needs one of those licenses, including people using simple apps on standard connectors.

So the decision turns on one count: who actually uses the apps and flows in each pipeline target, and what license does each of them hold?

• Everyone already has a qualifying premium license. Enable Managed Environments now, and consider automatic conversion for future targets. You give up nothing and gain sharing limits, usage insights, and solution checker enforcement.
• Many users are on Microsoft 365 licenses only. Don't flip the switch yet. Choose between licensing them, moving their apps out of the pipeline target, or deploying that environment with Azure DevOps, GitHub Actions, or the Power Platform CLI instead of Pipelines.
• You don't know. That is the first week's work. Use the extension if you need it, once.

If you remember one test: before you approve enablement on any environment, could you name every group of people who run something there and the license each holds? If not, the approval is a licensing decision made blind.

Pipelines have always required Managed Environments on their targets. Microsoft's pipelines overview says the pipelines host doesn't have to be managed, developer environments don't have to be managed, and "all other environments used in pipelines must be enabled as managed environments." What is new is enforcement.

From Microsoft's admin deployment page documentation, updated September 30, 2026:

• The notice. Starting in October 2026, the admin deployment page notifies admins when pipelines deploy to an unmanaged target environment.
• The window. Admins must approve enabling Managed Environments for the target within 30 days of the notification, or future pipelines deployments to it are blocked.
• The extension. If more time is needed, admins can request one additional 30-day extension for each environment.
• The block. When the grace period or extension expires, pipelines deployments to that unmanaged target are blocked.
• What isn't affected. Microsoft is explicit that "these pipeline checks block new deployments; they don't disable anything already deployed."

Admins handle this in the Power Platform admin center under Deployment: select a pipelines host and review Environments to convert, where Power Platform and Dynamics 365 administrators can enable Managed Environments on one or more targets. Each pipelines host also has a setting under Deployment > Settings, "Enable automatic conversion of pipelines environments to managed environments." With it on, an unmanaged target is converted the next time a maker deploys to it.

The same page carries the sentence that matters most: "Separate licensing requirements still apply - review your license coverage, capacity, and auto-claim policy." The rest of this post is about that sentence.

Microsoft's licensing for managed environments sets the rule. Every user running an app in a managed environment needs a Power Apps Premium license, a Power Automate Premium license, or a Dynamics 365 Enterprise license that gives premium Power Apps usage rights. The same applies to every user running a Power Automate cloud flow there. One premium license covers both: someone who runs apps and flows doesn't need Power Apps Premium and Power Automate Premium.

Organizations on capacity licensing meet the requirement differently. For apps, the environment needs Power Apps per app plans, such as app passes, allocated to it. For flows, it needs Power Automate per flow plans, such as Flow per business process.

Two details catch people.

Standard apps count. The Power Apps licensing FAQ answers this directly. Once you activate Managed Environments, "all active usage requires a qualifying license," and "this requirement includes users who run standard apps, because the requirement applies to active usage in the environment rather than to the type of app." A canvas app built on SharePoint and Outlook connectors, used by staff who hold only Microsoft 365 licenses, falls under the rule the day its environment becomes managed. Microsoft 365 licenses are not on Microsoft's list of qualifying licenses.

The grace period has an end date. Microsoft has been running the compliance initiative in stages:

• Administrator notifications began in March 2026, through the Microsoft 365 Message center and Power Platform admin center recommendations.
• In-app notifications to end users started in June 2026: an informational message on day 0, a warning on day 7, and an error on day 14, each telling the user the app requires a valid Power Apps license.
• Starting February 2027, users without an appropriate license are blocked from opening apps in the managed environment after the final notification stage. Apps aren't removed, and access resumes once a license is detected.

The FAQ also makes clear that February 2027 is broader than Managed Environments. It lists other areas where the requirement "was applied leniently," including model-driven apps and custom apps used outside a Dynamics 365 environment context, which will also require an appropriate premium license.

Put the two clocks together and the trap is plain. Pipelines push you to make a target managed within weeks. Licensing in that environment is then enforced from February 2027. Approving the first without checking the second can leave you with a deployment path that works and users who can't open the apps it deploys.

Auto-claim changes the shape of the surprise. Microsoft supports auto-claim policies for Power Apps, created in the Microsoft 365 admin center by a global admin. With a policy on, a user without a standalone Power Apps license who launches an app in a managed environment is automatically granted a Power Apps per user license. That keeps people working. It also means that converting an environment can start assigning licenses as people open apps. Find out whether a policy is on before you convert, so the assignments don't surprise whoever owns the license budget.

For environments that are already managed, the admin center has a Users requiring licenses in managed environments report that lists the users who need a license, and View license consumption (preview) shows current usage.

There is no Managed Environments product to buy. Microsoft's overview describes them as included as an entitlement with standalone Power Apps, Power Automate, Microsoft Copilot Studio, Power Pages, and Dynamics 365 licenses. Trial licenses can license users in managed environments, with their usual restrictions; Microsoft's example is that trial licenses only last 30 days. The Developer Plan doesn't include the entitlement when users run their assets.

So the cost of a managed environment is the licensing of the people who use it:

• Nothing extra where every user already holds a qualifying premium Power Apps, Power Automate, or Dynamics 365 license.
• Premium licensing for everyone else who runs apps or flows in the environment, per user or through capacity allocated to the environment.
• Admin time to configure the features, which is the cheap part.

We don't quote license prices here. They change, and agreements differ, so check current terms with your licensing owner at decision time.

Microsoft describes Managed Environments as "a suite of premium capabilities that allow admins to manage Power Platform at scale with more control, less effort, and more insights." The list is long. These are the features that change daily work for most IT teams:

• Limit sharing. Stop makers from sharing canvas apps with security groups or everyone, or cap how many individuals an app can be shared with. Similar controls cover solution-aware cloud flows and agents. Existing access isn't revoked, but an item that is out of compliance can only be unshared until it complies.
• Weekly usage insights. A digest to Power Platform and Dynamics 365 administrators covering overall activity, apps and flows nobody has launched in a while, and the most used resources and top makers. It needs tenant-level analytics turned on.
• Solution checker enforcement. Static analysis of every custom solution at import, in Warn or Block mode. Block cancels an import with highly critical issues before anything changes in the environment.
• Environment groups and their rules. Groups can only contain managed environments. Rules apply settings such as sharing limits, solution checker, usage insights, backup retention, and generative AI settings across every environment in the group.
• Pipelines and Dataverse Git integration. Pipeline targets need Managed Environments, and Git integration needs development and target environments to be managed, per Microsoft's Azure DevOps setup article.
• Maker welcome content, a custom onboarding message for makers in the environment.

The rest of the list is aimed at security and compliance teams: IP firewall, IP cookie binding, customer-managed keys, Lockbox, extended backup, Virtual Network support, conditional access on individual apps, control over which apps are allowed in the environment, and data masking rules. If your security team has asked for any of those, Managed Environments is where they live. If nobody has, don't let the length of the list make the decision for you.

Most of this is Power Platform governance work you would want anyway. The question is only which environments it should cover, and who pays for the people inside them.

The decision is per pipeline target, not per tenant.

Moving standard apps out of a pipeline target is often cleaner than it sounds. A production environment that mixes premium line-of-business apps with simple standard apps nobody deploys through a pipeline already has an environment strategy problem. The deadline just puts a date on fixing it.

Pipelines is one of several Microsoft-supported ways to move solutions between environments. Where making a target managed doesn't fit your licensing, the options below have documented, supported paths. Each one still deploys managed solutions to test and production, which is the part of ALM that protects you. Choose by the skills and platforms your team already has, not by which one sounds most advanced.

Azure DevOps with Power Platform Build Tools

Power Platform Build Tools are Microsoft's Power Platform tasks for Azure Pipelines. They export, unpack, pack, and import solutions, run solution checker, set solution versions, and manage environments. Microsoft states that the build tools are available at no cost, and that you need an Azure DevOps subscription to use them. Azure DevOps has a free tier sized for small teams; check the current allowances in Microsoft's billing overview.

What makes it a replacement rather than a workaround:

• Environment requirement. Microsoft's Build Tools documentation lists a Dataverse database as the environment requirement. Unlike the Pipelines and Git integration documentation, it doesn't list Managed Environments.
• Identity. The service connection authenticates as a service principal, and Microsoft recommends workload identity federation for tenants that require multifactor authentication.
• Connection references and environment variables. The Import Solution task accepts a deployment settings file that sets both during import.
• Approvals. Azure Pipelines approvals and checks on an environment let a named approver gate the production stage, which serves the same purpose as approval-based delegated deployments in Pipelines.
• History. The Unpack Solution task writes solution source to a repository, which gives you version history without Dataverse Git integration.

The cost is skill, not licensing. Someone on the team has to build and maintain the pipeline definitions, and that is a different discipline from building apps.

GitHub Actions for Power Platform

For teams whose code already lives in GitHub, GitHub Actions for Power Platform offers the same model: Microsoft-published actions for exporting, importing, unpacking, packing, and checking solutions, authenticated by a service principal. Microsoft's documentation states the same environment requirement, a Dataverse database.

The Power Platform CLI, scripted

For a small team with no DevOps platform, the Power Platform CLI runs the same operations from a script: pac solution export --managed from development, pac solution create-settings to generate a deployment settings file, and pac solution import with that file into the target. It is repeatable and adds no platform. It has no approval step, so who runs it and when becomes a written rule rather than a system control, and history depends on keeping the exported solutions or unpacked source in a repository.

Manual export and import

Still supported and still the baseline. It suits occasional deployments of a small number of solutions, and it is the route most exposed to skipped steps.

What every route outside Pipelines has to handle

Connections come first. A deployment settings file points each connection reference at a connection ID, and Microsoft's instructions take that ID from the target environment's Connections list. During import, connection references are validated to make sure their connections are usable by the connection reference owner, so each connection must be owned by that owner or shared with them. When a release adds a connection reference, create its connection in the target before the import that needs it, and regenerate the settings file with pac solution create-settings for each release so a new reference isn't missed.

Ownership. Service principal application users can own and run flows, and solution flows don't require their connections to be shared with the service principal. Premium flows owned by a service principal need a Power Automate Process or per-flow license, membership in a flow group with a Process license, or a designated licensed user.

Licensing doesn't disappear. Leaving an environment unmanaged avoids the Managed Environments requirement, not premium licensing in general. Apps and flows that use premium connectors still need premium licenses. Microsoft's February 2027 change also covers other areas where the requirement "was applied leniently," including model-driven apps and custom apps used outside a Dynamics 365 environment context. Read the licensing FAQ before treating an unmanaged environment as license-free.

Dataverse Git integration is not an alternative here. It requires development and target environments to be managed.

The 30 days run from the notification, so start on the day you see it.

Days 1–5: find the targets. In the admin center, open Deployment, select each pipelines host, and list the Environments to convert. Note the date each notice appeared. For each target, list the apps and flows deployed there; the Power Platform inventory lists apps and flows by environment and owner, and downloads to CSV.

Days 6–12: count the users. For each target, work out who runs those apps and flows and which license each person holds. Check whether an auto-claim policy for Power Apps is on in the Microsoft 365 admin center.

Days 13–20: decide and act. Apply the table above environment by environment. Approve enablement where users are covered. License, split, or change the deployment method where they aren't. Request the extension only for environments where the count isn't finished.

Days 21–30: configure what you now have. Set sharing limits, include the environment in the weekly usage digest, set solution checker to Warn, and read its summary emails before moving to Block. Then decide whether automatic conversion should be on for future targets, now that you know what conversion means for licensing.

Then put February 2027 in the calendar. For every managed environment, run the Users requiring licenses report well before then, so nobody discovers the change by finding an app they can no longer open.

Treating automatic conversion as the fix. It is the right setting once you know that the users of every future target are licensed. Turned on first, it converts environments as makers deploy, and the licensing question arrives afterward.

Assuming standard apps are exempt. In a managed environment they aren't. Microsoft's FAQ says the requirement follows active usage in the environment, not the type of app.

Spending the extension early. There is one per environment. Save it for an environment with a real reason.

Switching solution checker straight to Block. Block cancels imports with highly critical issues, which can stop the deployment you just rescued. Run Warn first.

Planning to switch it off later. Managed Environments can be disabled, but Microsoft's enablement instructions say to make sure none of its capabilities are in use first, and pipeline targets and Git integration need it anyway. Treat enablement as a commitment.

Reading this as a Pipelines-only change. Git integration has the same requirement, and the February 2027 licensing change reaches model-driven apps and custom apps outside Managed Environments too. Read the licensing FAQ end to end.

Microsoft's own documentation for the platform facts above. Requirements, dates, and licensing change; check them at decision time.

1. Overview of pipelines in Power Platform: the Managed Environments requirement for targets, the developer-environment exception, the example setup, and pipeline capabilities.
2. Admin deployment page: the October 2026 enforcement, the 30-day window and extension, Environments to convert, and automatic conversion.
3. Licensing for managed environments: which licenses qualify, capacity options, the notification stages, the February 2027 block, and the license report.
4. Power Apps licensing FAQs: standard apps in managed environments, and the broader February 2027 enforcement.
5. Auto-claim policies for Power Apps: automatic license assignment when a user opens an app in a managed environment.
6. Managed Environments overview: the feature list and the licensing entitlement.
7. Enable Managed Environments: required roles, Dataverse requirement, and the condition for disabling.
8. Limit sharing: sharing rules for canvas apps, solution-aware cloud flows, and agents.
9. Weekly usage insights: the digest's contents, recipients, and prerequisites.
10. Solution checker enforcement: the None, Warn, and Block modes.
11. Environment groups: groups contain only managed environments, and the rules they apply.
12. Connect Git integration to Azure DevOps: Managed Environments required for development and target environments.
13. Power Platform inventory: apps and flows by environment and owner, with CSV download.
14. Power Platform CLI: pac solution: managed export, import with a deployment settings file, and creating that file.
15. Microsoft Power Platform Build Tools for Azure DevOps: no-cost tools, the Azure DevOps subscription requirement, service principal authentication, and the Dataverse environment requirement.
16. Build Tools tasks: the Import Solution task's deployment settings file parameters and the solution task list.
17. GitHub Actions for Power Platform: the equivalent actions, authentication, and environment requirement.
18. Pre-populate connection references and environment variables: the deployment settings file, connection IDs, and connection validation at import.
19. Service principal owned flows: ownership by service principals and licensing for premium flows they own.
20. Approvals and checks in Azure Pipelines: gating a stage that deploys to an environment.
21. Azure DevOps billing overview: the free tier and paid allowances.