SharePoint Embedded Integration

SaaS vendors come to us for two things: migrating an existing WOPI host onto SharePoint Embedded, and implementing SharePoint Embedded from scratch in a new product. Both are Microsoft Graph engineering projects with a good deal of architecture and customer-migration work wrapped around them, and both are what we do.

McKenna Consultants have spent more than a decade implementing Microsoft document integrations for SaaS platforms in legal, auditing, work and workflow management, contract management, document management, education, and compliance. We have worked on over 20 WOPI implementations, and we deliver SharePoint Embedded implementations and WOPI-to-SharePoint-Embedded migrations for SaaS vendors today. Because we are equally fluent in both, we treat a migration as an architectural transition to be assessed on its merits — not as advocacy for either platform.

New to the platform? Our guide to what SharePoint Embedded is covers containers, container types, billing and compliance. To talk about delivery, get in touch with our SharePoint Embedded specialists.

Migrating From WOPI to SharePoint Embedded

If you already run a custom WOPI host, SharePoint Embedded offers a way to retire bespoke document infrastructure, inherit Microsoft 365 compliance rather than re-establishing it, and pick up Copilot integration without building it. It is also a substantial project. A realistic migration of a non-trivial WOPI host inside a live SaaS product is a multi-month engagement, and the first thing we do is establish whether it is the right one for you.

When Migration Makes Sense

• Operational burden reduction. Discovery uptime, certificate management, proof key rotation and Office release tracking are standing costs that are rarely a strategic differentiator. SharePoint Embedded removes that surface area entirely.
• Co-authoring without further investment. Real-time co-authoring, sensitivity labels, retention policies and Microsoft Purview integration are substantial engineering projects on a custom WOPI host. SharePoint Embedded provides them as platform capabilities.
• Microsoft 365 Copilot. If your product strategy includes Copilot capabilities or custom agents, SharePoint Embedded is the most direct route to making your documents Copilot-grounded.
• Customer demand. Enterprise buyers increasingly ask whether a product is built on SharePoint Embedded. Where go-to-market depends on Microsoft alignment, the platform position itself carries commercial value.
• Simpler compliance conversations. A SharePoint Embedded application answers storage-layer security questions by reference to Microsoft's certifications and information protection model, which can materially shorten procurement in regulated sectors.

When Staying on WOPI Is the Right Call

Not every WOPI host should migrate, and we will say so. WOPI remains a fully supported integration model and Cloud Storage Partner Program membership remains open — what has changed is the recommended path for new entrants, not the support position for either model. Migration is usually the wrong call when:

• You depend on CSPP Plus features in production. Backstage integration and chunked file transfer have no direct SharePoint Embedded equivalents. Migrating would be a feature regression unless your product strategy can absorb it.
• Data residency falls outside Microsoft's footprint. SharePoint Embedded containers are provisioned into a specific Azure region, so most residency requirements are satisfiable — but customer-controlled data centres, or jurisdictions Microsoft does not serve, rule it out.
• The cost outweighs the benefit. A stable WOPI host serving a small customer base with low operational burden may simply not be worth moving.

Our strong recommendation is that this decision is made deliberately, with a documented rationale, before any code is written.

What Changes Architecturally

Most WOPI concepts map cleanly onto SharePoint Embedded equivalents — the file store becomes containers, CheckFileInfo becomes Graph drive item properties, GetFile and PutFile become Graph content endpoints. Three areas need real attention:

• Lock management disappears. The lock state machine your team has maintained for years does not exist on the SharePoint Embedded side; Microsoft handles it inside the platform. This is a genuine simplification.
• The identity model shifts to Entra ID. WOPI integrations commonly translate a host identity model through HostAuthenticationId. SharePoint Embedded uses Entra ID directly, so applications with their own identity systems must federate first. This is often the single largest sub-project.
• CSPP-specific features may have no equivalent. If you use backstage integration, the migration involves a product decision about that user journey, not just an engineering one.

Our practical playbook for migrating from a custom WOPI host works through the full concept-by-concept mapping.

How We Run a Migration

A migration breaks into five workstreams, run in parallel where the dependencies allow: identity and authentication; container type registration and customer onboarding; data migration; application layer changes; and decommissioning of the legacy host.

Rollout is phased, with an explicit go/no-go gate at each boundary — an internal pilot to prove the end-to-end flow and harden the migration tool, a friendly customer pilot with two or three tolerant customers to produce a proven runbook, a controlled rollout in defined cohorts, and finally full cutover and decommissioning. End to end, expect six months minimum for a small estate and twelve months as a realistic figure for a substantial one.

Our Migration Engagement Model

We deliver migrations as packaged engagements in four stages, each with a defined output:

• Strategy and architecture. Decision framework analysis, architectural mapping, migration planning, customer communication strategy. Output: a documented migration plan with workstreams, dependencies and timeline.
• Implementation. The five workstreams above. Output: a working SharePoint Embedded application running alongside your existing WOPI infrastructure, ready for pilot migration.
• Pilot and rollout. Migration tool refinement, pilot customer migration, controlled rollout across the estate. Output: customers migrated, with the WOPI infrastructure scoped for retirement.
• Decommissioning. Retirement of the WOPI endpoints, CSPP exit where applicable, source storage archive. Output: a clean SharePoint Embedded operational state.

Implementing SharePoint Embedded in a New SaaS Product

For products being built now, SharePoint Embedded is usually the shorter path to embedded Microsoft 365 document editing: no partner programme to join, no WOPI host to build and operate, and no requirement that your end users hold Microsoft 365 subscriptions of their own. You can engage us at any point from initial architecture through to a production integration shipped to your customers, and most engagements blend several of the models below.

Container Type and Architecture Design

The most consequential decision in any SharePoint Embedded implementation is how container types are designed and how containers map onto your tenancy, document and permission models. We define the container topology for your multi-tenancy, register your container types with Microsoft, plan the Microsoft Entra ID application and admin consent flow that follows from that design, and structure Azure billing to fit your subscription pricing. Get this stage right and the rest is straightforward; get it wrong and remediation later is expensive.

Full End-to-End Implementation

A complete implementation service: container type registration, Microsoft Graph integration, the document creation and editing experience inside your product, the permission model, the operational tooling, and production deployment. Choose this if you want us to own the SharePoint Embedded workstream while your team focuses on the rest of the roadmap.

Container and Microsoft Graph API Microservice

We build a multi-tenant SharePoint Embedded microservice handling container lifecycle, permissions, file operations and the Office editing handoff, and your team integrates it into your existing architecture and interface. This is a popular option for established platforms that want to keep their core application surface and team structure unchanged while delegating the SharePoint Embedded specifics.

Consultancy and Co-Sourcing

If your own engineers are doing the implementation, we can act as technical advisor — helping initiate the project, validating your container type design, reviewing code, and staying on call for the parts of SharePoint Embedded that are easy to get wrong. We co-source alongside in-house teams so your engineers keep the knowledge when the engagement ends, and all of the code and intellectual property is yours.

Technical Approach

Our typical solution is a multi-tenant SharePoint Embedded service that owns the container type registration, manages your relationship with each customer's Microsoft 365 tenant, and exposes a clean internal API to the rest of your platform. We implement the Graph operations end to end — container lifecycle, permission management, file create and update, search, version history, recycle-bin behaviour, and the handoff to Office for the web — and wrap them in the operational tooling production SaaS needs: telemetry, idempotent retries, tenant-level health checks, and graceful degradation when Microsoft 365 is having a bad day.

There is no protocol to learn the way WOPI required, but the platform has its own constraints. Container types must be designed up front, owning-tenant and consuming-tenant relationships must be configured correctly, and your Azure billing posture has to match the commercial model you offer customers. We have extensive experience navigating those constraints inside production SaaS products, and we use it to keep implementations on the supported path — through rollout, and through the procurement and security reviews your customers will run on them.

Where appropriate we extend the same architecture to expose your container content to Microsoft 365 Copilot. This is increasingly a baseline expectation: customers who have adopted Copilot expect the SaaS products in their stack to participate in it over their own data.

Our team uses AI coding tools throughout our development workflow, so SharePoint Embedded implementations are delivered faster without compromising on compliance or quality.