Microsoft has drawn a line in the sand: August 28, 2026. That’s the date when its Graph Toolkit — a collection of prebuilt web components and authentication providers that thousands of organizations use to embed Microsoft 365 data into custom apps — reaches full retirement. Starting September 1, 2025, the toolkit enters a deprecation period. After the 2026 deadline, no more updates, security patches, or compatibility guarantees will flow from Redmond. The components won’t suddenly blink off, but the risk of breakage, especially around authentication and permissions, will grow with each passing month.
If your organization runs SharePoint Framework web parts, Teams tabs, or any custom application that imports anything from @microsoft/mgt-*, you have a finite window to make some hard decisions.
What Microsoft Graph Toolkit Actually Does
Microsoft Graph Toolkit (MGT) arrived as a developer shortcut. Instead of wrestling with authentication flows and Graph API calls, coders dropped ready-made web components — like Login, People, Agenda, or the identity-sensitive People Picker — onto a page, wired up a provider, and got a polished Microsoft 365 look with minimal code. The package also shipped React-wrapped versions and SPFx integration paths, making it a staple in corporate intranets, line-of-business apps, and even a few customer-facing portals.
Under the hood, the toolkit bundled concerns that, in a well-engineered application, should live in separate layers: identity token acquisition, raw Graph queries, data transformation, and UI rendering. That convenience came with a hidden price: when the toolkit falls out of support, all those intertwined concerns become a single point of failure.
What Retirement Really Means
Retirement is not an automatic shutdown switch. Existing bundled code may continue to execute for a time, especially if the underlying Graph APIs and authentication protocols remain unchanged. Microsoft’s own documentation on the toolkit clearly states the end date, but it does not promise any code-breaking event.
That’s precisely what makes this retirement dangerous. A web part that appears to work today could silently fail tomorrow when an authentication library changes, a browser tightens security, or a Graph API response shifts format. Because the component is unsupported, you’re on your own to diagnose and fix it — likely under pressure while a business process grinds to a halt.
There’s also a policy dimension. Many organizations require that all production dependencies be covered by an active support contract. An unsupported toolkit can violate internal governance rules, even if nothing visibly breaks.
Who Is Affected — and How Deeply
If you answer “yes” to any of these, the retirement applies to you:
- You deploy SharePoint Framework (SPFx) solutions that reference
@microsoft/mgt-components,@microsoft/mgt-react, or any MGT package. - You host Teams tabs or personal apps built with the toolkit.
- You’ve built custom web apps (React, Angular, Vue, or vanilla JS) that import MGT components.
- You’ve upgraded to MGT v4 and adopted
@microsoft/mgt-spfx-utils. That package only replaced the earlier SPFx integration helper — it did not remove the underlying MGT dependency.
Even organizations that have been diligent about updating packages may miss shadow dependencies. A common trap: an internal component library with a generic name that wraps MGT functionality. Several SPFx solutions reference the wrapper, not the toolkit directly, making a package-lock scan unreliable.
The same risk applies to runtime registrations. MGT v4 introduced explicit component registration, meaning a developer could call registerMgtComponents() far from any obvious import statement. Code that looks clean at a glance can still pull in the toolkit at runtime.
Your Three Choices for Every Web Part
There is no one-size-fits-all answer. Treat each MGT-dependent artifact — SPFx web part, Teams extension, custom app — as a separate decision. The goal is not to rewrite everything overnight but to assign a clear, accountable disposition to every instance.
1. Rebuild (the default for anything important)
This is the required path for any web part that:
- Selects or validates user identities (e.g., People Picker, Login)
- Performs write operations against Microsoft 365 data
- Exposes sensitive information (profile details, financial data, HR records)
- Sits in a business-critical workflow
If any one of those conditions applies, you rebuild now, prioritizing based on business impact. The rebuild should separate concerns: authentication, data access, and UI. Use the Microsoft Graph SDK for API calls, a service layer you control for data handling, and Fluent UI Web Components for the visual layer — though be warned, Fluent UI does not offer drop-in replacements for complex MGT controls like Person Card or People Picker.
2. Freeze (only under strict guardrails)
A limited, temporary freeze can be justified for an internal, read-only component that:
- Is narrowly deployed
- Handles no sensitive data
- Has a named technical owner and business sponsor
- Is already slated for retirement or replacement within a defined window
- Has a documented exception approved by security and architecture teams
Even here, the freeze must be airtight. Lock the exact MGT package versions (no semver ranges), preserve the source and build toolchain, and restrict the Graph permissions to the absolute minimum needed. Document the authentication path and maintain repeatable tests for sign-in, token expiration, and permission errors. Assign a fixed end date — and stick to it. After that date, the part gets rebuilt or removed.
A freeze is an exception, not a migration strategy. It does not apply to any component that obtains tokens, writes data, picks users, or feeds into an approval chain.
3. Remove
If a web part is abandoned, duplicate, ownerless, or no longer tied to a valid business need, the best move is to delete it outright. Carrying unsupported code into the future only adds noise to your inventory and brittleness to your platform.
How to Inventory Your MGT Footprint
Before you can decide, you need a complete picture. Start with a code-level scan that covers:
- All
package.jsonandpackage-lock.jsonfiles for MGT imports (@microsoft/mgt-components,@microsoft/mgt-react,@microsoft/mgt-spfx,@microsoft/mgt-spfx-utils, etc.) - Any custom wrappers or shared libraries that abstract the toolkit behind internal component names
- Runtime registration calls (e.g.,
registerMgtComponents()orProviders.globalProvider = …) - Teams manifests that reference MGT solutions
- SPFx solutions deployed across site collections (a SharePoint admin can pull these via PnP PowerShell)
Don’t stop at the code. For each instance, document:
- The business purpose and owner
- The Graph permissions it requests (delegated and application)
- The deployment scope (intranet, extranet, specific teams)
- The data classification of information it displays or processes
This inventory will surface your migration priorities. Identity workflows come first; read-only directory tiles might wait.
Rebuilding the Hard Stuff: People Picker and Person Card
The trickiest migrations center on components that involve identity selection and profile display. People Picker, for example, is not just a search box — it queries Graph for matching users, disambiguates results, handles edge cases like no results or expired tokens, and feeds a validated user object to the next step in the workflow. It must also support keyboard navigation and screen readers.
Person Card presents a similar design challenge. Rebuilding it means deciding which profile fields to fetch, how to present them, what to show when data is missing, and whether any actions (message, call, view org chart) belong in the new control.
Microsoft’s guidance points developers toward the Graph SDK for data retrieval and Fluent UI for building the interface. But neither solution provides the ready-made Graph-aware behavior that the toolkit offered. Expect to spend real product-design time on these replacements, not just a package swap.
The rebuild approach: create a dedicated service that fetches, transforms, and caches Graph data, then feed typed results into Fluent UI components. This decoupling means you can later swap the UI library without rewriting authentication and data logic.
Testing: Don’t Settle for a Happy Page Load
A new component that renders correctly with a fully authenticated, omnipotent user is not done. Thorough testing must include:
- Authentication failures, expired tokens, and users with no applicable permissions
- Graph API errors (throttling, 404s, schema mismatches)
- Empty result sets and incomplete user records
- Keyboard-only operation and screen-reader announcements
- Loading states and error recovery
- Regression: the replacement must not duplicate data submissions, misroute an approval, or silently select the wrong identity
Once the replacement passes muster, remove all MGT imports, registrations, and dependencies. Verify via a production bundle scan that the toolkit is absent. Then revoke any Graph permissions that are no longer needed. An older component’s broad permissions are not an excuse to carry them forward.
What Happens If You Do Nothing
The most likely outcome is not a sudden outage on August 29, 2026, but a slow, expensive crisis. An authentication library update will break sign-in. A browser security change will kill the component’s ability to store tokens. A minor Graph API revision will leave a Person Card showing nothing but error placeholders. When it breaks, there will be no support ticket to file and no quick fix from Microsoft. The team that built the original solution may be long gone.
Meanwhile, the clock is already ticking. The deprecation period starts September 1, 2025 — less than a year from now. That’s the moment Microsoft begins steering developer attention, documentation, and internal testing away from the toolkit. If you haven’t started by then, every month you wait increases the risk that something changes underneath you before you’re ready.
The Bigger Picture
This retirement fits a pattern. Microsoft has been systematically retiring older extensibility models — classic Teams meeting controls, Project Online’s legacy features, client-side integration paths — to drive adoption of Graph SDKs, Fluent UI, and the modern Microsoft 365 platform. The message is consistent: hand-coded dependencies that bundle too many concerns will eventually be unsupported.
For IT and development teams already stretched thin, that means the work of lifecycle management never ends. The best defense is clear ownership. Every web part, Teams tab, and custom integration needs a named business owner and technical maintainer. When Microsoft announces a retirement, you don’t start from a panic — you consult your inventory, rank by risk, and execute a plan.
Start with identity components. Define your freeze criteria. Schedule the first migrations now. And make sure that when August 28, 2026, arrives, your Graph-powered experiences are running on components you understand and control.