Power Pages licensing: what a customer portal really costs before you build it

Power Pages licensing is capacity-based. You aren’t buying a licence for a named person, you’re buying a block of user capacity and attaching it to an environment.

Microsoft’s own wording on the UK Power Pages pricing page is precise about the unit. Authenticated plans are “sold in capacity packs of 100 and assigned at the environment level”, and a unit of authenticated capacity “provides access to one Power Pages website for a calendar month”. Anonymous plans work the same way in packs of 500.

The metering is usage-based rather than assignment-based. When Power Pages became generally available, Microsoft’s licensing announcement put it plainly: authenticated and anonymous users “are consumed/metered only when a user accesses a website in a calendar month”. The stated point of that design was to let organisations deploy sites broadly “without assigning licenses to individual users each month”.

Three things follow from that, and they’re the three that matter for your budget.

• A person who never visits in a given month doesn’t consume capacity that month.
• A person who visits two of your Power Pages sites in the same month consumes capacity on both.
• You buy in fixed blocks, so 101 authenticated users costs the same as 200.

That last point is the one that makes small portals proportionally expensive and large ones surprisingly efficient.

These are Microsoft’s UK list prices as shown on the en-GB pricing page as of September 2026. They exclude VAT and they’re the “paid yearly” figures.

Plan	UK list price	Unit as Microsoft states it
Power Pages authenticated users, per website	£153.80	100 users/site/month, paid yearly
Power Pages anonymous users, per website	£57.70	500 users/site/month, paid yearly
Power Pages free trial	Free	30 days

The en-GB page also notes that both monthly and annual commitments are available, with annual billable annually or monthly.

Those headline numbers are easy to under-read, so it helps to run them out. The arithmetic below is ours, applied to Microsoft’s published list prices, not figures Microsoft publishes in this form.

• The minimum realistic annual cost of one authenticated Power Pages site is one pack, at £1,845.60 a year.
• A portal with 500 authenticated users needs five packs: £769.00 a month, or £9,228.00 a year.
• A portal with 2,500 authenticated users needs 25 packs: £3,845.00 a month, or £46,140.00 a year.
• A public site expecting 10,000 anonymous users a month needs 20 packs: £1,154.00 a month, or £13,848.00 a year.

Divided out, a pack works out at £1.538 per authenticated user per month and £0.1154 per anonymous user per month. Microsoft doesn’t price it that way, and you can’t buy a single user, but as a modelling ratio it’s the number worth carrying into the design conversation.

Run those two per-user figures against each other and the verdict writes itself. An authenticated user costs roughly 13 times what an anonymous user costs. Every page you put behind a sign-in is a page that moves users from the cheap column into the expensive one.

That doesn’t mean authentication is wrong. It means authentication has to earn its place.

It earns it when the page shows somebody their own data, when you need an audit trail of who did what, when the process writes back to Dataverse under an identity, or when a regulator would expect access control. Those are real requirements and no amount of pricing pressure should move them.

It doesn’t earn its place when the sign-in exists because the page was designed that way out of habit. A published policy document, a service catalogue, a status page, an eligibility checker that takes an input and returns a generic answer: none of these need to know who the visitor is.

The practical move is to split the site. Keep the genuinely public material anonymous and put only the personalised, identity-bound journeys behind authentication. Do that at wireframe stage, because retrofitting it once the site is built means reworking table permissions and web roles, which is considerably more expensive than thinking about it early.

Here’s the clause that does the most quiet damage. Capacity “provides access to one Power Pages website for a calendar month”, and Microsoft states that users needing access to more than one site “will require additional authenticated user capacity”.

Read that against how portal estates actually grow. An organisation builds a supplier portal. It goes well, so a customer self-service site follows. Then a grant application site for a different department. Three sites, one shared population of external users, and every user who touches all three consumes three units of capacity in that month rather than one.

The same logic bites on environments. Packs are assigned at environment level, so capacity bought into production doesn’t float across to a site living somewhere else.

Worth knowing

Microsoft’s pricing pages don’t address non-production sites. The 30-day free trial is the only free entitlement shown, and nothing on the en-GB or en-US pricing pages says whether a development or test Power Pages site needs its own capacity. If your build plan assumes a free dev site sitting alongside production indefinitely, get that confirmed in writing through your licensing route before the plan depends on it.

The design response is consolidation. One site with well-structured web roles and table permissions will usually cost less than three tidy single-purpose sites serving the same people, even though three tidy sites feel like better architecture. That trade-off is worth making deliberately rather than discovering it at renewal.

Power Pages runs on Dataverse, and each capacity pack brings some Dataverse storage with it.

An authenticated pack carries 2 GB of database capacity and 16 GB of file capacity per subscription plan. An anonymous pack carries 0.5 GB of database and 4 GB of file capacity. Microsoft’s footnote is specific that “Dataverse database and file capacity entitlements for subscription plans are pooled at the tenant level”, so it accrues to the tenant pool rather than being ring-fenced to the site that generated it.

For a portal that mostly reads existing data, that bundled capacity is usually a rounding error against what the tenant already holds. For a portal whose whole purpose is collecting documents, it isn’t. An application process that takes three uploaded PDFs per applicant will eat file capacity fast, and file capacity is the entitlement most organisations have never looked at.

Check the tenant’s current Dataverse position before you model the portal, not after. The portal’s storage cost may already be sitting inside an existing overage, in which case the capacity packs aren’t the number to worry about.

Being straight about this matters more than filling the gap with something plausible.

Microsoft’s public Power Pages pricing pages, and the licensing announcement that accompanied general availability, are silent on several points that come up in every procurement conversation.

• Repeat visits. The pages say capacity covers a user “for a calendar month”, but they don’t spell out what happens when the same person signs in fifteen times in that month. The calendar-month framing strongly suggests one unit, and the announcement’s “metered only when a user accesses a website in a calendar month” points the same way, but the pages don’t state the repeat-visit rule outright.
• Rollover. Nothing on any of the pricing pages says whether unused capacity carries into the next month. There’s no claim either way.
• Overage. Nothing states what happens the moment you exceed purchased capacity, whether access is blocked, throttled or billed as overage. The only relevant wording is the generic note that offers are “subject to product service limits”.
• Pay as you go. Microsoft’s 2022 announcement listed pay-as-you-go rates for Power Pages. The current pricing pages don’t show a pay-as-you-go option for Power Pages at all, only prepaid capacity packs. Whether that route has been withdrawn or simply isn’t surfaced on the pricing page isn’t something the public pages resolve.
• Volume tiers. The 2022 announcement referred to additional volume tiers for both plan types. The current pricing pages show a single tier for each. That’s a straightforward conflict between two Microsoft sources, and the newer page is the one to treat as current, but if you’re buying at scale it’s worth asking the question directly.

Microsoft’s Power Pages FAQ on Microsoft Learn is the place to check current detail on several of these, and your licensing partner should be able to confirm the rest in writing. Take the written answer rather than the forum answer. Licensing terms change, forum posts don’t.

If your portal predates the rename, the position is settled and reasonably generous.

Power Pages was previously purchased as Power Apps portals and became a standalone product with its own plans when it went on sale on 1 November 2022. Microsoft’s announcement set a transition period through 31 March 2023, after which “new and renewing customers will use the Power Pages plans to purchase”.

Two things in that announcement are worth holding onto. Existing Power Apps and Dynamics 365 Enterprise customers using Power Apps portals through their internal use entitlements “can continue to access Power Pages websites (no change)”. And the newer Power Pages capabilities, including the design studio, were made available to existing portals customers “without any migration required”.

That announcement is from October 2022, so treat it as the origin of the current model rather than a current statement of your entitlement. If your renewal is coming up and your portal still sits on legacy portals licensing, that renewal is the moment the Power Pages plans apply, and it’s worth modelling the capacity packs before the renewal quote lands rather than after.

Power Pages is a genuinely good answer to a narrow question: how do we let people outside the organisation interact with Dataverse data, securely, without building a web application from scratch. Outside that question, it’s often the wrong tool, and the licensing model is part of why.

You don’t need it for a brochure website. If the site doesn’t read or write business data, you’re paying capacity charges for something a standard CMS does better and cheaper.

You don’t need it when the external population is tiny and occasional. Half a dozen suppliers submitting a form twice a year will be better served by a shared document library with external sharing, or a Microsoft Form feeding a flow. A single authenticated pack at £1,845.60 a year is a lot of money for six people.

You don’t need it when your data doesn’t live in Dataverse and there’s no good reason to move it there. Power Pages is Dataverse-native, and forcing a migration purely to enable a portal is a large project wearing a small project’s clothes.

And you probably shouldn’t use it when the external experience is your product. If the portal is the thing customers judge you by, is highly branded, and needs a design system you fully control, the constraints of the platform will start to bite. That’s a build, not a configuration.

Where it does fit, it fits well: supplier onboarding, grant and licence applications, customer self-service against records you already hold, partner portals, case tracking, anything where identity and record-level security matter and the underlying data is already in the Microsoft stack.

The model itself is uncomplicated once you know which questions to ask. Four numbers decide almost everything.

Work out how many distinct external people will access the site in a typical month, not how many are on your database. Split that number into those who must be authenticated and those who can stay anonymous. Count how many separate Power Pages websites those people will touch. Then round each population up to the next whole pack.

Multiply out and you have your annual figure, and you have it before anybody has built anything.

The useful part isn’t the total. It’s what the model tells you to change. Almost every time, the biggest saving available is moving a chunk of content from behind the sign-in to in front of it, and that’s a decision made in the wireframes.

If your team is going to own the portal after go-live, the Dataverse and Power Platform fundamentals matter as much as the licence model. Our PL-900 Power Platform Fundamentals course covers the platform concepts that sit underneath a Power Pages site, and it’s the usual starting point for a team inheriting one.

It’s also worth reading the capacity question alongside the wider platform picture. The same environment-level thinking that governs Power Pages capacity is what governs Power Platform governance generally, and the licensing logic will feel familiar if you’ve already worked through Power Apps licensing.