A single premium connector pulled 20 to 40 percent of makers into a band their app never justified
Two SKUs cover most of what an estate needs, and the licence band is not decided by the app. It is decided by whether any connector in that app happens to be premium, which is a build time choice made by someone who never sees the bill.
Prepared by Redress Compliance · August 16, 2026 · Microsoft advisory. 30 to 40 Power Platform reviews, 2024 to 2025.
Executive summary
One premium connector escalates the whole licence band. It pulled 20 to 40 percent of makers into a higher band than their app justified, and the decision that triggered it was made in a build rather than in procurement.
Plan mismatch stranded licences on both sides. Per app suits the long tail of makers running one or two apps; per user suits heavy builders. Getting it wrong wastes money in both directions at once.
Dataverse capacity bills separately and overage surprised most estates. Storage is a recurring true up line that nobody forecasts because it is not part of the seat conversation.
Sprawl drives overspend, not unit price. Governance beats licence shopping here, which makes this a control problem wearing a procurement costume.
Plan fit, and where each one strands money
Two SKUs handle the bulk of deployments and premium beyond that is the exception. The mismatch is expensive in both directions, which is why it survives: neither side of the error looks like waste on its own.
| Plan | Best fit | Watch out for |
|---|---|---|
| Per app | Long tail makers running one or two apps | Counting apps as they multiply past the break even |
| Per user | Heavy builders across many apps | Assigned to light users who never reach the break even |
| Pay as you go | Sporadic apps with irregular use | Metered billing on something that becomes routine |
| Dataverse capacity | Storage behind the apps | Bills separately, and overage lands at true up |
The band is set by the connector, not by the app. A single premium connector inside an otherwise ordinary application pulls its maker into a higher licence band, regardless of how simple the app is or how rarely it runs. That is what makes this a governance problem rather than a purchasing one: the escalation is triggered by a build time decision, made by someone solving a technical problem, who has no visibility of the licence consequence and no reason to look for one.
Sprawl is the cost driver, and unit price is the distraction
Power Platform cost conversations usually start on unit price, because that is the part procurement controls and the part a benchmark can address. Across the reviews we ran, plan selection and connector sprawl drove cost more than seat count did, and Microsoft's own SKU guidance was rarely mapped to real use. The estate grows through hundreds of small, individually reasonable decisions, and the licence position is the sum of them rather than the result of any single purchase.
The premium connector mechanism is the clearest example and the most expensive. A maker building an app to solve a departmental problem reaches for the connector that does the job. If that connector is premium, the maker's licence band moves, and it moves for the whole of that person's usage rather than for the app in question. Twenty to forty percent of makers sat in a higher band than their app justified on exactly this basis. Nobody made a bad decision. The person who chose the connector was not shown a price, and the person who pays the bill was not shown the connector.
Plan mismatch compounds it from a different direction. Per app fits the long tail of makers running one or two applications; per user fits genuine heavy builders. Estates that standardised on one or the other stranded licences on both sides simultaneously, paying per user rates for people who build almost nothing while paying per app rates for people who have quietly accumulated six applications. Neither error is visible in a total, which is why the reconciliation has to be done per maker rather than in aggregate.
Dataverse then arrives at true up. Capacity bills separately from the seats and is rarely forecast because it is not part of the seat conversation, so overage produced unplanned charges in most estates reviewed. The correction across all three is the same and it is not a purchasing move: a light but real governance gate that records which connectors an app uses, which plan its maker holds, and what it stores, before the app reaches production. Sporadic apps can sit on metered pay as you go rather than standing licences. The negotiation itself is worked in the Power Platform negotiation brief, and the wider library in the Microsoft practice.
- Usage exports analysed: inactive accounts, plan right sizing, per user reassignment
- Your renewal quote benchmarked against real closed Microsoft deals
- Every risky clause flagged with the exact quote, the page, and the replacement language
The controls that actually reduce the bill
- Record connector use per app before production, because a single premium connector escalates its maker's band for everything they do, not just for that app.
- Reconcile plan against behaviour per maker, not in aggregate, since per app and per user errors offset each other in a total and cancel out the signal.
- Forecast Dataverse capacity alongside seats, since it bills separately and its overage lands at true up rather than in the renewal conversation.
- Route sporadic apps to pay as you go rather than issuing standing licences for something that runs a few times a quarter.
- Treat sprawl as the primary cost driver, because governance beats licence shopping and unit price is the smallest of the three levers.
- Benchmark before renewal, once the estate is reconciled, so the discount applies to a corrected position rather than to accumulated drift.
What the Power Platform reviews showed, 2024 to 2025
Across roughly 30 to 40 Power Platform reviews, plan selection and connector sprawl drove cost more than seat count:
Share of makers pulled into a higher licence band than their application justified, by premium connector use alone.
Per app against per user errors stranded licences in both directions simultaneously, which is why a total hides them.
Dataverse capacity overage produced unplanned true up charges in most estates. Microsoft's own SKU guidance was rarely mapped to real use, which is the underlying condition all three findings share.
None of these are pricing failures. They are visibility failures, and they are corrected by a governance gate that costs almost nothing rather than by a negotiation that costs a quarter.
Watch the briefing · 5:46Five Mistakes Microsoft Sales MakesWhere the Microsoft licensing conversation goes wrong, and what a prepared buyer does differently.
Your first five moves
- Inventory connector use per app and identify every maker whose band was escalated by a premium connector rather than by their actual workload.
- Reconcile plan against behaviour maker by maker, counting apps per person rather than looking at estate totals.
- Forecast Dataverse capacity as its own line, because it bills separately and surfaces at true up.
- Move sporadic apps to pay as you go and retire standing licences that exist for occasional use.
- Put a light governance gate in front of production recording connectors, plan, and storage. The Microsoft practice runs the reconciliation with you.
Frequently asked questions
Which Power Platform plans cover most needs?
Per app and per user handle the bulk of deployments, with premium beyond that as the exception. Pay as you go suits sporadic apps that do not justify a standing licence, and Dataverse capacity bills separately from all of them.
What does a premium connector actually do to the bill?
It escalates the licence band for the maker, not just for the app. A single premium connector inside an otherwise ordinary application pulled 20 to 40 percent of makers into a higher band than their app justified.
Why is that a governance problem rather than a purchasing one?
Because the escalation is triggered at build time by someone solving a technical problem who is not shown a price, while the person paying the bill is not shown the connector. Neither party made a bad decision and the cost still moved.
How does plan mismatch strand money on both sides?
Per user rates get assigned to people who build almost nothing, while people who have quietly accumulated six applications sit on per app. Both errors exist at once, they offset in a total, and only a per maker reconciliation surfaces them.
Why does Dataverse overage surprise people?
Because it bills separately from seats and is therefore not part of the seat conversation, so nobody forecasts it. It produced unplanned true up charges in most estates reviewed, arriving after the renewal rather than during it.
When is pay as you go the right answer?
For sporadic apps with irregular use, where a standing licence sits idle most of the time. The risk is the reverse case: metered billing on an app that quietly becomes routine, which needs reviewing rather than setting once.
Is unit price worth negotiating?
It is the smallest of the three levers. Sprawl and plan fit drive most overspend, so a discount applied to an unreconciled estate is a percentage off accumulated drift. Reconcile first, then benchmark.
What does the governance gate need to record?
Which connectors an app uses, which plan its maker holds, and what it stores. That is enough to catch all three findings before production, and it is light enough not to slow real work.
How many makers are typically misbanded?
Between 20 and 40 percent in the reviews we ran, on premium connector use alone. That is before any plan mismatch, which stranded licences separately and in both directions.
Does Microsoft SKU guidance help?
It exists but was rarely mapped to real use in the estates reviewed. The guidance describes what each plan permits; it does not tell you which of your makers are in the wrong one, and that mapping is the work.
The Microsoft EA Preparation Playbook: The Work That Wins the Renewal
Five workstreams in order: the license position, the usage file, the demand forecast, the benchmark and alternatives files, and the ask list drafted before Microsoft drafts theirs, with the executives aligned before the first meeting.
