Power Pages vs WordPress for customer portals: keep the marketing site, move the sign-in

The usual way this question arrives: a company has a WordPress site that works, ranks for the things it should rank for, and is edited by someone in marketing without anyone filing a ticket. Then customers start asking to see their own orders, tickets, invoices or applications, and a quote lands for a membership-plugin build on top of the existing site. Somebody else in the room points out that the company already pays Microsoft for a lot of things, and asks whether one of them does this.

Both instincts are defensible, and the quote is not a trick. But the framing is wrong, because a portal is not a section of a content site. It is a different kind of software wearing the same URL.

This page is the outside-the-stack question: should the portal be built in the Microsoft stack at all? If you have already decided it should be, the next question is an internal one — an app for staff or a site for outsiders — and that is covered separately in Power Apps vs Power Pages for portals. We will not re-argue it here.

A portal and a content site want opposite things

A content site optimises for publishing: get a page written, styled and live quickly, make it fast, make it findable. A portal optimises for identity and records: prove who this person is, then show them their rows and nobody else's. Almost every portal project that goes badly went badly because it was scoped as the first thing and turned out to be the second.

Microsoft is unusually blunt about which job its product is for. Its introduction to Power Pages (opens in new tab) describes it as a low-code platform “for creating, hosting, and administering modern external-facing business websites” built on “the same shared business data stored in Microsoft Dataverse” used by the rest of the Power Platform. Note what is load-bearing in that sentence: the shared business data. Power Pages is a front door onto records. It is not a blogging platform, and nothing about it will make your content team faster.

WordPress is the mirror image. It is a mature content management system with an enormous plugin ecosystem, and it has had user accounts and roles for as long as it has existed. It can absolutely put a login on a page. What it does not have is a business data layer — so the moment the portal needs to show live records from a system of record, WordPress has to reach them across an integration that somebody has to build, secure and keep working.

Where each one is genuinely strong

Neither column below is a weakness list. They are two tools aimed at different halves of one website, and the honest comparison is which half you are actually building.

The identity row is the one people underestimate. Power Pages ships a list of providers rather than a plugin hunt — Microsoft’s authentication overview (opens in new tab) lists Entra ID over OpenID Connect, SAML 2.0 and WS-Federation, Entra External ID, Azure AD B2C, AD FS, and OAuth 2.0 sign-in with Microsoft, Google, LinkedIn, Facebook or Twitter accounts. It also says plainly that the local username-and-password option is not recommended, which is worth reading as guidance rather than a footnote: if you build the portal here, you are meant to let a real identity provider hold the credentials.

The split most SMBs should actually be quoted

Here is the answer that rarely appears in a proposal, because it is not the largest project either side could sell you: keep WordPress for everything a stranger reads, and use Power Pages for everything a known customer does. The marketing site keeps its domain, its rankings, its editing workflow and its theme. The portal becomes a separate signed-in property linked from the navigation, sitting on your business records.

This is not a compromise dressed up as a strategy. There is a hard technical constraint that makes it the natural shape. Microsoft’s guidance on adding a custom domain name to a Power Pages site (opens in new tab) states that you can add only one custom domain name to a website, that the hostname is created with a CNAME record at your DNS provider, and that you cannot use CNAME mapping for a root domain — so the root itself is not available as a Power Pages hostname. In practice a Power Pages site lives at something like portal.yourcompany.com, which means handing your marketing pages over to it would require moving them off the root anyway. Leaving WordPress on the root is the path of least destruction, not a consolation prize.

One practical detail worth designing around before launch rather than discovering at go-live: Power Pages identifies authenticated visitors by their Dataverse contact record, and Microsoft notes that each user must have a unique email address — if two or more contact records share one, including deactivated records, those contacts cannot sign in. Companies with years of accumulated duplicate contacts tend to meet that rule at the worst possible moment. Cleaning it up is part of the data work, which is why we scope that layer explicitly as Microsoft Dataverse consulting services rather than assuming it is free.

The two bills have different shapes

We do not publish figures for either platform, because both change and a stale number is worse than none. What matters more for a decision is the shape of the cost, and the shapes are genuinely different — which means the cheaper option depends entirely on how your portal grows.

Read the last two rows together, because they are the decision. WordPress wins on the first version and loses slowly; Power Pages loses on the first version and wins as the permission model gets real. The break-even is not a headcount — it is the moment your portal stops showing content and starts enforcing who may see which row.

Read the quote you were given

You can usually settle this from the proposal already on your desk, without another discovery call. Four signals point at WordPress:

The portal shows content, not records. A gated knowledge base, a client resource library, a members-only download area. There is no system of record behind it, so there is nothing for Dataverse to do.

Nothing needs to reach a business system. Submissions land in an inbox or a spreadsheet and a human takes it from there. That is a form, and a form plugin is the correctly-sized tool.

The audience is large, anonymous and occasional. If most visitors never sign in, you would be paying a portal platform to serve people who only read.

Marketing owns the site and there is no IT function. Adding a second platform with its own admin model has a real organisational cost, and it is fair to weigh that.

And four that point the other way:

The words “so they can see their own” appear in the requirement. Their own orders, their own tickets, their own invoices. That is row-level security on live records, and it is the single clearest signal in the whole exercise.

The records already live in Dataverse, Dynamics 365 or Business Central. Then WordPress needs an integration to reach what Power Pages reads natively, and you are funding a bridge to a building you already own.

Staff will work the same records from the inside. One copy of the data with two front doors beats two copies and a sync, every time. This is where a portal and an internal app get scoped as one project on one data layer.

Somebody has to answer for the security model. If a customer seeing another customer's invoice would be a serious incident, declarative table permissions you can review are a better place to stand than bespoke filtering logic in a theme.

What changing your mind actually costs

Cheaper than the equivalent mistake inside a single platform, which is the quiet advantage of the split. Because the two halves are separate properties joined by links, a portal that turns out to be the wrong shape is replaced without touching the marketing site — the pages that carry your organic traffic were never in scope. Going the other way, retiring a Power Pages portal in favour of a plugin build leaves the WordPress site untouched as well.

What does not survive either move is the front end: templates, forms, styling and the permission rules are platform-specific and there is no converter. What survives is the data model, if it was designed as one. Records, relationships and the rules about who may see which row are the durable half of a portal project, and they are worth an extra day at the start even when version one is small.

If the answer came out on the Microsoft side, Power Pages development services covers the build: external sites secured with web roles and table permissions, tested the way an attacker would test them. If the same records also need an internal screen for staff, Power Apps consulting covers that half, and we scope the pair on one Dataverse foundation rather than as two disconnected projects. Either way it is fixed-fee, typically two to four weeks, with 30 days of hypercare after go-live — you can read how the fixed-fee process works before speaking to anyone.