Ownership can move without a support ticket
A Power Pages site can now have its primary owner reassigned from inside the product. A Power Platform blog post dated September 27, 2026 and written by Apurba Sinha Roy says eligible site owners and service administrators can hand a site to another eligible user in the same tenant without raising a support request.
The action sits in the Power Platform admin center, under Manage, then Power Pages, then Site Details, then Edit, then Owner, then Save and Transfer. That is a handful of clicks in a screen most Power Pages admins already keep open.
Microsoft Learn is specific about who can perform the change. It lists a website owner who is a system administrator as well, a Dynamics 365 administrator, or a Power Platform administrator. The receiving side is constrained too. Learn says the new owner must be an enabled Microsoft Entra user with a Member user type, which rules out guest accounts. If a partner administers your portals, nobody at that partner can be made the owner.
The sites whose owner left two years ago
Most admins reading this did not build the estate they run. You inherit a tenant, open the site list, and find owner names you have to look up in the directory, several of which resolve to people who left before you arrived. Fixing one of those used to mean opening a support case and waiting.
A site with no real owner is a governance problem rather than untidy metadata. Nobody is accountable for what it publishes, nobody reviews who can sign in, and nobody can answer whether it should still be running at all. It carries on serving pages while that question goes unasked.
This belongs in the same family as the ownership debt that builds up in Power Automate, where a flow keeps firing long after its maker changed jobs. The difference with a portal is the audience. A broken flow fails quietly inside your tenant. A portal puts your organisation's name in front of anyone with the URL.
Microsoft's own warning is the part to read twice
Learn puts an important callout on the transfer page. "You can't automatically undo an ownership transfer." It separately notes that the previous owner might lose access to the site. Both statements come from Microsoft, and neither is our reading of the risk.
Set those two sentences side by side and the danger is plain. An administrator tidying up the owner field can lock out the one person who still knows how the site was built, which forms write to which Dataverse tables, and why that odd redirect exists. Microsoft offers no single control that puts the arrangement back.
The feature is still worth having. The sequence is what carries the exposure. The hour you spend establishing what a site does and who currently reaches it belongs before the transfer, because afterwards the person who could have answered may no longer be able to open the site.
What the post does not say
Microsoft never puts a release stage on this. The blog post does not say generally available and does not say preview, so treat the stage as undisclosed until Microsoft states one. The Learn documentation also carries date metadata of September 21 to 23, 2026, roughly six days ahead of the blog, so the capability was documented before it was written up.
Two claims in the blog do not appear in the Learn how-to. The blog says a transfer captures information including the previous owner, the new owner, who started it and when it happened, and that relevant stakeholders are notified by email. Those are the blog's statements rather than documented behaviour, which matters if you planned to treat that email as your change record.
A note on our own reading. Two automated passes over the blog body disagreed with each other, so the facts above come from parsing the raw page. We have also seen claims elsewhere that the feature went generally available on September 15 and that an advisory feature surfaces sites without a valid owner. Neither appears in Microsoft's material, and we are not repeating them as fact.
Read the owner field before you change it
Start with what the site actually does. Work out which tables its forms write to, which audience signs in, and whether anybody still depends on it. A portal with three internal users and a portal taking customer submissions deserve very different care, and the owner field tells you nothing about which one you hold. The Power Pages security checklist is a reasonable pass to run while you are in there.
Then choose an owner who holds a role rather than whoever is nearest the ticket. A named individual with no role attached is the same problem again on a longer timer. Teams who already run governance that keeps low-code moving tie portal ownership to a function, such as the service owner for that business area.
Record why each transfer happened in your own change log, since the detail the blog describes sits in Microsoft's records and not in yours. Then do the part that costs nothing. Open Site Details on every production site and read the Owner field. Write down each site whose owner has already left the company. That list is the governance gap you have been carrying without seeing it, and building it transfers nothing.
