Your architects have done their job. They have evaluated the options for embedding Microsoft 365 document editing inside your product, weighed SharePoint Embedded against a custom WOPI host and against a direct Microsoft Graph integration, and made a recommendation. Now the question lands on a different desk. The CFO and the procurement team do not need to know how container types work; they need to know what this will cost over three years, where the cost is fixed and where it scales, and whether the recommended option is genuinely the cheapest once everything is counted. This article sets out an honest, end-to-end model for SharePoint Embedded pricing and cost, and a structured way to think about SharePoint Embedded total cost of ownership rather than just the headline platform bill.
A word of warning before any numbers appear. Microsoft’s consumption rates change, and they vary by region and agreement. Every figure in this article is illustrative and labelled as such. The methodology is what matters — plug your own confirmed rates into it. Do not treat any unit price here as fact, and always confirm current Microsoft pricing before you build a business case.
How the SharePoint Embedded Consumption Model Actually Works
The first thing to understand about SharePoint Embedded pricing and cost is that it is a consumption, pay-as-you-go model, not a per-seat licence. You do not buy SharePoint Embedded the way you buy Microsoft 365 E3 seats. Instead, you register the platform against an Azure subscription, and Microsoft meters your usage and bills it through that subscription, alongside your other Azure spend. This is a fundamental difference from classic SharePoint Online licensing, and it changes how finance should categorise the cost: it is variable cloud infrastructure spend, not a fixed software subscription.
What is metered breaks down broadly into two things:
- Storage — the volume of data held in your containers. This is the most predictable component and tends to dominate as an estate matures.
- Content activity and transactions — the work the platform does on that content. Microsoft’s model distinguishes between content that is actively being worked on and content that is sitting at rest, and the billing treatment of those two states is not the same. Active, frequently accessed content attracts a different rate of charge than dormant, archival content.
The practical consequence is that two tenants storing the same number of gigabytes can generate very different bills if one is a busy collaboration workload and the other is a write-once compliance archive. Your usage profile, not just your storage total, drives the cost.
There is also a crucial distinction between billed usage and non-billed usage. SharePoint Embedded provides trial and sandbox container types intended for development and evaluation. These let you build and test without incurring the standard consumption charges, but they come with limits and are not for production data. The moment you move to standard (billed) container types and point real customer traffic at them, the meter is running. A common and avoidable mistake is to model the cost of a proof of concept — which ran on free trial containers — and assume production economics will look the same. They will not.
Finally, because billing flows through an Azure subscription, the cost is governed by the same Azure tooling everything else is: Cost Management, budgets, alerts, tags and reservations where applicable. That is genuinely helpful — finance teams who already understand Azure spend do not need a new mental model — but it also means SharePoint Embedded cost is only as visible as your Azure cost governance discipline allows.
Forecasting Consumption From a Usage Profile
A credible SharePoint Embedded total cost of ownership model starts with your own usage profile, not Microsoft’s rate card. The platform bill is an output of how your customers behave, so you forecast the behaviour first and apply rates second.
The inputs you need are straightforward to gather:
- Number of containers and how they map to customers. One per customer, one per workspace, or shared — this affects nothing in the storage rate but matters for how you attribute cost back to customers later.
- Average and peak data volume per container, and how that grows. Document workloads rarely shrink; assume net accumulation unless you have a retention policy that actively deletes.
- Active-to-inactive ratio. What proportion of your stored content is being edited or read in any given month versus sitting idle? A legal matter platform might have 5% active and 95% archived; a live collaboration tool might be the reverse.
- Transaction intensity. How many document opens, edits, saves and Graph operations per active user per month?
- Growth curve. Net new customers per quarter, and net new data per existing customer.
With those inputs you can build a simple monthly projection: storage cost = volume x rate, split by active and inactive bands, plus a transactional component, compounded across your growth curve over 36 months. The single most important output is not the total — it is the shape of the curve. SharePoint Embedded cost is dominated by accumulating storage, so it tends to start low and climb steadily. A model that shows a flat line is almost certainly wrong.
The Surrounding Costs Everyone Forgets
The platform consumption bill is the part everyone budgets for. The reason TCO models go wrong is the surrounding costs, which are real, recurring, and frequently larger than the platform bill itself in the early years. A complete SharePoint Embedded total cost of ownership picture must include all of the following.
Your Azure app hosting. SharePoint Embedded stores and edits the documents; it does not run your application. You still need to host your own app tier — the API that creates containers, handles authentication, brokers Graph calls and serves your UI. That is App Service or AKS, a database, networking, key management and so on. This cost exists in every option, but it is easy to forget that SharePoint Embedded does not remove it.
Microsoft Graph usage and throughput. Nearly every interaction with SharePoint Embedded goes through Microsoft Graph. Graph is not separately metered for most operations, but at scale you will hit throttling limits, and engineering around throttling — retry logic, backoff, batching, caching — is a real cost in build and in latency. It is the most common technical surprise we see.
Engineering build cost. Standing up production-grade SharePoint Embedded — Entra app registration, container type lifecycle, consent flows, the editing integration, security and observability — is a meaningful project. It is far less than building a WOPI host from scratch, but it is not free, and it requires people who know the platform.
Ongoing operations and support. Someone monitors the estate, manages container type changes, handles Microsoft’s platform updates, responds to incidents and supports customers. Budget for a fraction of an engineer’s time indefinitely, not a one-off.
Compliance and governance tooling. If you are regulated, you need eDiscovery, retention, audit, DLP and residency controls. SharePoint Embedded inherits a great deal of the Microsoft Purview compliance stack, which is a genuine cost saving versus building it yourself — but accessing some of those capabilities depends on your Microsoft 365 agreements, and configuring and operating them is still work.
Opportunity cost. Every engineer-month spent operating document infrastructure is a month not spent on your product’s differentiating features. This is the cost CFOs intuitively understand and architects routinely omit.
SharePoint Embedded vs Building and Running a Custom WOPI Host
The most important comparison is against the alternative many organisations default to: building a custom WOPI host, where you own all the storage and infrastructure yourself. As a WOPI consultancy UK team that has built and operated WOPI hosts, we will be blunt about the economics.
A custom WOPI host shifts cost from a metered platform bill to your own balance sheet. You are no longer paying Microsoft per gigabyte of content — you are paying for your own object storage, your own compute to scale the host, your own security hardening, your own high-availability and disaster recovery, and crucially your own engineering team to build and maintain a protocol implementation that must keep pace with Microsoft’s changes. The WOPI protocol itself is stable, but Office Online’s expectations, security requirements and certification do evolve.
The trade is therefore clear in shape, even if the numbers vary:
- SharePoint Embedded has low fixed cost and a variable bill that scales with content. You pay almost nothing to start and more as you grow.
- A custom WOPI host has high fixed cost — significant up-front build, plus a standing engineering and infrastructure commitment regardless of usage — and a lower marginal cost per gigabyte once built, because you control the storage tier.
This produces a crossover. Below a certain scale, SharePoint Embedded is dramatically cheaper because you avoid the fixed build and operations burden. Above some very large scale, with predictable workloads and an in-house team that already exists, owning the storage can become cheaper per unit — but only if you genuinely have the engineering capacity to run it well, and only if you correctly price the security, compliance and reliability work you are taking on. Most organisations badly underestimate that work, which is why the apparent saving of a custom host frequently fails to materialise.
SharePoint Embedded vs a Direct Microsoft Graph / OneDrive Integration
The third option is to skip a dedicated document store entirely and integrate directly against Microsoft Graph and the user’s own OneDrive or SharePoint. Here the platform consumption cost can appear to be zero, because the storage lives in your customers’ existing Microsoft 365 tenants and is covered by their licences, not billed to you.
That apparent saving is real but narrow, and it comes with constraints that often disqualify it:
- The documents live in the customer’s tenant, under the customer’s control and governance, not your application’s. You cannot guarantee retention, you cannot cleanly offboard, and your data model is hostage to their environment.
- It only works where every customer already has appropriate Microsoft 365 licensing. If your customers do not, the model collapses.
- You inherit none of the application-owned container model’s isolation and lifecycle control, which means more bespoke engineering to achieve governance you would get for free with SharePoint Embedded.
For a simple “let users edit their own files” feature, direct Graph is often the cheapest and most sensible choice. For a product that needs to own its documents — control residency, retention, isolation and offboarding — the engineering and governance cost of forcing direct Graph to behave like an owned store usually exceeds SharePoint Embedded’s consumption bill.
The Cost Levers an Architect Can Pull
A good architect can move the SharePoint Embedded bill substantially before a single rate is negotiated. The principal levers:
- Active vs inactive content management. Because dormant content is billed differently, a deliberate lifecycle policy that lets ageing content settle into the lower-cost state is one of the largest levers available.
- Retention and deletion policies. Storage is the dominant cost and it only accumulates. Defensible deletion and archival policies directly reduce the curve.
- Container strategy. Fewer, well-designed containers reduce management overhead and make consumption attribution cleaner, which in turn lets you bill customers accurately.
- Graph efficiency. Batching, caching and avoiding redundant calls reduce throttling risk and the engineering cost of working around it.
- Trial and sandbox discipline. Keeping non-production work on non-billed container types prevents accidental spend.
- Azure cost governance. Tags, budgets and alerts on the billing subscription turn surprises into early warnings.
A Worked TCO Model for Three Archetypes
Below are three illustrative three-year models. Every figure is for illustration only and clearly labelled — confirm current Microsoft pricing and your own staffing rates before relying on any of this. The figures use round numbers to show the methodology and the relative shape of the cost, not to predict your bill.
Archetype A: Small ISV (early-stage, modest data)
A young product with a few hundred customer workspaces and modest, slowly growing storage.
| Cost component (illustrative, 3-year) | Approx. share |
|---|---|
| SharePoint Embedded platform consumption | Low |
| Azure app hosting | Low–moderate |
| Engineering build (one-off) | Largest single item |
| Operations / support | Low |
| Compliance tooling | Minimal |
Verdict (illustrative): SharePoint Embedded is comfortably the cheapest option. The platform bill is small, and the fixed cost of a custom WOPI host would dwarf the entire three-year SharePoint Embedded TCO. Build cost dominates only because everything else is so low.
Archetype B: Mid-market SaaS (growing, active collaboration)
Thousands of workspaces, steadily growing storage, and a high active-to-inactive ratio because users collaborate daily.
| Cost component (illustrative, 3-year) | Approx. share |
|---|---|
| SharePoint Embedded platform consumption | Moderate–high, rising |
| Azure app hosting | Moderate |
| Engineering build (one-off) | Moderate |
| Operations / support | Moderate |
| Compliance tooling | Moderate |
Verdict (illustrative): SharePoint Embedded is still the better economic choice in most cases, but the platform consumption line is now material and rising, driven by the high active-content ratio. This is the archetype where the cost levers — particularly active/inactive lifecycle management and retention — earn their keep. A custom WOPI host starts to look defensible only if a strong in-house platform team already exists.
Archetype C: Large regulated enterprise (very large, archival-heavy)
Very large data volumes, much of it archival, with stringent compliance, residency and audit requirements.
| Cost component (illustrative, 3-year) | Approx. share |
|---|---|
| SharePoint Embedded platform consumption | High (storage-dominated) |
| Azure app hosting | Moderate |
| Engineering build (one-off) | Moderate |
| Operations / support | High |
| Compliance tooling | High |
Verdict (illustrative): This is the genuinely contested case. Inherited Purview compliance capabilities are a substantial saving versus building governance from scratch, and they often tip the balance towards SharePoint Embedded. But at very large, predictable, archival-heavy volumes, a well-run custom store with cheap cold storage can have a lower marginal cost per gigabyte. The honest answer depends on whether the organisation has the engineering maturity to operate that store to the same compliance standard — and most underestimate that. Model it carefully; do not assume.
Where SharePoint Embedded Is Cheaper, and Where It Is Not
To be honest about it: SharePoint Embedded is almost always cheaper for small and mid-sized products, because it eliminates the large fixed cost of building and operating document infrastructure and lets you pay only for what you use. It is frequently cheaper even at enterprise scale once the inherited compliance stack is properly valued. Where it can lose on pure unit economics is at very large, stable, archival-heavy volumes where a mature in-house team can run cheaper storage — and even then, only if that team’s true cost, including security and compliance, is counted honestly. A direct Graph integration can be cheaper still for the narrow case of editing customers’ own files, but rarely meets the needs of a product that must own its documents.
How McKenna Consultants Can Help
We are a UK software consultancy with deep experience across the full spectrum of Microsoft document integration — from building and operating custom WOPI hosts to designing and running SharePoint Embedded at scale. That dual background is exactly what a credible TCO comparison needs, because we have actually paid the bills on both sides.
We help finance and architecture teams build defensible SharePoint Embedded total cost of ownership models grounded in your real usage profile, validate them against confirmed current Microsoft pricing, identify the cost levers worth pulling, and decide honestly between SharePoint Embedded, a custom WOPI host and a direct Graph integration. As an experienced WOPI consultancy UK partner, we will tell you when SharePoint Embedded is not the cheapest answer for you, not just when it is.
If your architects have recommended SharePoint Embedded and your CFO needs the numbers to stand up, get in touch for a TCO modelling session. We will help you embed Microsoft 365 document editing in a way your finance team can sign off with confidence.
