The Power Platform CoE Starter Kit is retired, and nobody told your tenant

If your Power Platform governance runs on the CoE Starter Kit, the ground moved underneath it and there was no message centre post to tell you.

Microsoft’s documentation now opens with a note rather than an overview: the Power Platform CoE Starter Kit is no longer actively maintained. Its core capabilities have moved into the Power Platform admin centre. Issues raised against it are no longer reviewed or addressed, and it is receiving no further feature investment.

It has not been switched off. It remains available for existing deployments and, oddly, for new ones. That combination is the problem. Nothing breaks on a particular date, so nothing forces the conversation, and estates carry on running governance reporting on a solution that will not be fixed when it stops matching the platform underneath it.

What “no longer maintained” actually means here

Worth being precise, because this is softer than a deprecation and people are reading it as either more or less serious than it is.

The kit still works. Your inventory flows still run, your dashboards still populate, your existing deployment is not at risk today. What has stopped is the maintenance: no new capabilities, and issues are not reviewed or addressed. Security vulnerabilities are the single exception, and they go to the Microsoft Security Response Centre rather than through the usual channel.

So the risk is not a cliff. It is drift. The CoE Starter Kit works by reading the platform through APIs and connectors, and the platform is changing quickly. Agents, agentic apps, vibe apps, code apps and workflow agent flows are all resource types that did not exist when most estates deployed the kit. As the platform adds resource types, an unmaintained inventory solution does not report them as missing. It simply does not report them.

That is the failure mode to plan around: a governance dashboard that continues to look healthy while covering a steadily shrinking proportion of the estate.

What replaces it

Four experiences in the Power Platform admin centre, each mapping to something the kit used to do:

The honest summary is that the replacement is better than the kit at the thing the kit was worst at, which is being current. Inventory reflects created, updated or deleted resources within 15 minutes, against a solution that ran on scheduled flows and a Dataverse copy that could be a day or more behind.

It also covers resource types the kit never will. Inventory includes agents from both Copilot Studio and Microsoft 365 Copilot Agent Builder, apps built in Power Apps as canvas, model-driven, code and vibe apps, apps from Microsoft 365 Copilot’s App Builder, cloud flows, agent flows, workflow agent flows, environments and environment groups. Connector inventory is in preview and answers a question that was previously very hard: which apps, flows and agents use a given connector or operation, which makes deprecation planning, premium connector licensing and DLP scoping query-driven rather than investigative.

Actions are available on individual resources too. You can delete a resource, or block a published agent or canvas app, and blocking is reversible. A blocked agent stays visible and testable for its maker in Copilot Studio but cannot be used in any other channel, which is a proportionate response to a suspected problem in a way that deleting never was.

Two cohorts, and only one of them has an easy migration

The useful question is not whether you run the CoE Starter Kit. In our engagements roughly 60 to 70% of enterprise clients still have an active deployment. The question is whether you have built anything on top of it, and that splits the population almost exactly in half.

The inventory-only cohort. About half use the kit purely for asset discovery, connector auditing and the out-of-the-box Power BI tenant dashboard. For them the migration is genuinely straightforward, because the admin centre now covers all three jobs natively through Inventory, Usage and Monitor.

The custom Dataverse cohort. The rest have built critical business processes directly on the kit’s core Dataverse tables. In practice that means custom app registration forms, automated maker-compliance request flows, orphaned-resource archival workflows and bespoke DLP change-approval apps. For those estates this is not a switch to the admin centre at all. It is a rebuild of those approval and lifecycle workflows on a custom Dataverse model, and it has to be finished before the kit’s unmaintained sync flows degrade underneath them.

That distinction decides the entire plan, and you can settle it in an afternoon: open the CoE solution and look at what has been added to it since it was installed. If the answer is nothing, you are in the easy half.

The access model changed, and this will catch people

This is the migration detail most likely to generate a support ticket in week one.

Power Platform inventory requires a Microsoft Entra role. Global administrator, Power Platform administrator, Dynamics 365 administrator and Global reader see everything. AI administrator and AI reader see only AI-related resources, meaning agents, agentic apps, agent flows, environments and environment groups. Canvas apps, model-driven apps and cloud flows are out of scope for those two roles.

The trap is in the next line of the documentation. The built-in Power Platform roles used for role-based access control are not supported for inventory access. Estates that spent the last two years moving away from broad Entra administrator roles towards granular Power Platform RBAC will find that the granular roles do not grant access to the new inventory. The path back to visibility runs through exactly the high-privilege Entra roles they were trying to stop handing out.

Global reader is the useful one here, because it is read-only and sees all inventory resources. For anyone who needs to look but not act, that is the assignment to make rather than reaching for Power Platform administrator.

The gaps, in the order they will bite

The replacement is good. It is also new, and the known limitations list is long enough to plan around rather than discover. These are the ones with governance consequences.

The flow owner column is not the owner. For cloud flows and agent flows, the owner column shows the user who created the flow, and it does not update when ownership changes. Microsoft lists preventing orphaned agents, by finding resources owned by departing users, as a headline use case. For flows, that query returns creators. A flow correctly transferred to a new owner two years ago still shows the leaver. This is the single limitation most likely to produce a wrong governance decision, because the answer looks authoritative.

Model-driven apps have no owner at all. Dataverse has no ownership concept for them, so access is governed purely by licensing and environment permissions. Only published model-driven apps are captured, and three preinstalled apps in the default environment do not appear until someone edits and republishes them.

Agents do not report modification data. The modified on and last modified by columns do not work for agents and show a dash. Any “what changed recently” governance question cannot be answered for agents from inventory.

Classic chatbots are absent from the new inventory page. They are still reachable under Copilot Studio, classic chatbots, but they will not appear in the unified view or its exports.

Workflow agent flows have no environment. Since April 2026, workflows created by Microsoft 365 Copilot’s Workflows agent live in a single hidden environment that the platform provisions automatically, one per tenant, and which does not appear in the environment list or any maker portal. Those flows show up in inventory with no environment information. Environment-scoped governance does not reach them.

Filtering by environment needs the exact name. Partial matches and substrings do not work, which matters when your environments are named to a convention with a long prefix.

Conditional access can break it entirely. Inventory reads from Azure Resource Manager. If your conditional access policy enforces multi-factor authentication for Azure Resource Manager, inventory may simply fail to load. The fix is to include the Power Platform admin centre application and the Microsoft Azure Management resource in that policy, which is an Entra change rather than a Power Platform one.

And the gap that has no workaround

Power Platform inventory is not available in sovereign clouds. Not in US Government Community Cloud, GCC High or DoD, not in 21Vianet in China, and not in air-gapped environments.

For those tenants the position is that the CoE Starter Kit is no longer maintained and the replacement does not exist for them. That is not a migration, it is a gap, and it lands specifically on the organisations with the strictest governance obligations.

This is the one case in this article where we would contact a client rather than wait for them to raise it.

Native parity in sovereign environments consistently lags commercial releases by months or quarters. A commercial tenant can lean on native Inventory, Actions and managed environments features to replace the basic CoE functions today. A sovereign tenant faces delayed rollout timelines for the same replacements, with no published date to plan against.

The compounding problem is that the kit will not be patched. Because it receives no updates and no bug fixes, a sovereign estate cannot rely on a future kit release to accommodate platform API drift. So the tooling degrades on the platform’s schedule while the replacement arrives on its own, and the gap between those two dates is carried entirely by the customer.

The answer is a staggered migration rather than a wait. Work out which governance and compliance processes depend on the kit, establish which of them have a native equivalent available in your cloud today, and rebuild those first. Keep the kit running for whatever has no replacement yet, and add your own coverage checks against the Power Platform API so you know which resource types it has quietly stopped reporting. The objective is that nothing critical is still riding on an unmaintained sync flow on the day that flow finally breaks.

You do not have to use the interface

Worth knowing before anyone rebuilds a reporting layer, because the kit’s real appeal was always that the data was queryable in Dataverse.

The same inventory data is available three other ways. The Power Platform for Admins V2 connector exposes a query action, so you can pull inventory into Power Automate and keep whatever automation you had. There is a Power Platform inventory API. And you can query inventory through Azure Resource Graph with KQL, which Microsoft publishes sample queries for, covering resource counts, field discovery, lookups and connector usage analysis.

Azure Resource Graph is the interesting one. It puts Power Platform inventory in the same query surface as your Azure resources, which means one KQL query can span both. Anyone who built CoE reporting because they wanted the data in a tool of their choosing has more options now than they did, not fewer. The whole inventory also exports to CSV, not just the rows currently loaded in the grid.

Our position: migrate the reporting, keep the questions

Our position is that the retirement is right and the timing is awkward.

The kit was always a community-maintained solution doing a job the platform should have done natively, and organisations ran it in production because there was no alternative. Native, real-time, tenant-wide inventory with an API and an Azure Resource Graph surface is unambiguously the better answer. We would not deploy the CoE Starter Kit into a new estate today, even though Microsoft still permits it.

What we would not do is treat this as a like-for-like swap and migrate the dashboards. The dashboards were built around what the kit could see. Rebuild from the questions instead: who owns what, what is unused, what touches which connector, what has no owner at all. Several of those are easier to answer now, and one of them, the owner question for flows, is currently harder. Knowing which is which is the entire migration.

For the inventory-only half of our client base, this migration is smaller than it looks, and the sooner it happens the sooner the estate gets 15 minute data instead of an overnight sync. For the half that built approval and lifecycle workflows on the kit’s Dataverse tables, it is a real project, and treating it as a tooling swap is exactly how it gets under-scoped. Those two need different plans and different budgets, which is why the first task is establishing which one you are.

The bigger risk is not the tooling at all. It is that the kit was frequently the only thing producing a tenant-wide view, and an estate that quietly loses that view does not notice. App sprawl is not a problem that announces itself.

Where to start

Four steps in order, plus one that applies only to sovereign tenants.

Establish which cohort you are in. Inventory only, or custom work built on the CoE Dataverse tables: app registration forms, maker-compliance request flows, orphaned-resource archival, DLP change-approval apps. Open the CoE solution and look at what has been added to it since it was installed. That single answer decides whether this is a fortnight or a project, and it is the cheapest thing on this list to find out.

Check your role assignments against the new model before anyone needs the data. If your administrators hold Power Platform RBAC roles rather than Entra roles, they will not see inventory. Assign Global reader where read-only visibility is what is needed.

Run the new inventory and compare it against your CoE reports. The differences are informative in both directions. Resource types the kit never saw will appear. Owner data for flows will disagree, and inventory is the one that is wrong there.

Then decide what to do about the gaps rather than working around them silently. The flow owner limitation in particular needs a documented compensating process, because it will otherwise produce confident, incorrect answers about who owns what.

And if you are in a sovereign cloud, begin now rather than when something breaks. The native replacements land there later than in commercial, and the kit will not be patched while you wait, so the staggered migration above has to start before the gap opens rather than after.

This is the second Power Platform deadline this quarter that arrives without a hard date, alongside managed environments licence enforcement and the AI Builder credit change. The pattern is consistent: the platform is tightening up, and the estates that get caught are the ones running on assumptions set two years ago.

Veratas runs Power Platform governance reviews and, for estates we run under managed services, this migration is already on the plan.

If your governance reporting runs on the CoE Starter Kit and you are not sure how much of your estate it can still see, talk to our team. That is a measurable question and the answer usually surprises people.

Frequently asked questions

Is the Power Platform CoE Starter Kit deprecated? It is no longer actively maintained. It still works and is still available for existing and new deployments, but it receives no new features and issues are not reviewed or addressed. Security vulnerabilities should be reported to the Microsoft Security Response Centre.

What replaces the CoE Starter Kit? Four native experiences in the Power Platform admin centre: Inventory for a unified view of apps, flows and agents, Usage for adoption, Monitor for operational health, and Actions for governance insights and remediation.

How current is Power Platform inventory? Resources that are created, updated or deleted appear within 15 minutes, which is considerably fresher than the scheduled synchronisation the kit relied on.

What roles are needed to see inventory? A Microsoft Entra role. Global administrator, Power Platform administrator, Dynamics 365 administrator and Global reader see everything. AI administrator and AI reader see only AI-related resources. Built-in Power Platform RBAC roles are not supported.

Can we still find apps owned by people who have left? Partly. For cloud flows and agent flows the owner column shows the original creator and does not update when ownership changes, so it will not reliably identify current orphans. Model-driven apps have no owner concept at all.

How hard is it to migrate off the CoE Starter Kit? It depends entirely on whether you built on it. Roughly half the deployments we see use the kit only for asset discovery, connector auditing and the Power BI tenant dashboard, and those migrate straightforwardly to the native Inventory, Usage and Monitor experiences. The other half built app registration forms, maker-compliance flows, archival workflows or DLP approval apps on the kit’s Dataverse tables, and those need rebuilding on a custom Dataverse model before the unmaintained sync flows degrade.

Is inventory available in GCC or other sovereign clouds? No. It is not available in GCC, GCC High, DoD, 21Vianet in China, or air-gapped environments, and native parity in sovereign clouds typically lags commercial releases by months or quarters. Because the kit also receives no further patches, those tenants cannot rely on it being updated for platform API drift while they wait. A staggered migration, rebuilding first whatever already has a native equivalent in your cloud, is the workable approach.

Can we query inventory outside the admin centre? Yes. Through the Power Platform for Admins V2 connector, the Power Platform inventory API, and Azure Resource Graph using KQL. The full inventory also exports to CSV.

Anuj Kumar Mishra

Operations head with 20 years of experience delivering business intelligence, ERP and AI programmes across healthcare, finance and manufacturing. Focus areas include Power Platform adoption and governance, delivery models, and managed services.