The Microsoft Graph mailbox import and export APIs have officially gone generally available. After their public preview, they're now sanctioned for production use — and they're a meaningful piece of the puzzle for anyone still leaning on Exchange Web Services (EWS) to move, back up, or integrate Exchange Online mailbox data.
If you've been waiting for the Graph-native answer to "how do we replace our EWS migration tooling before deprecation bites," this is the announcement to read. Just don't assume it's a complete answer yet.
What the APIs actually do
The new APIs let you walk a mailbox structure through Graph and move data in and out at full fidelity. Practically, that means a few things working together: discovering the mailbox hierarchy and enumerating folders, subfolders, and items; reading all item types in the IPM subtree, including messages, contacts, and calendar entries; creating, updating, and deleting folders; and using extended properties (single- and multi-value) on folders and items for the kind of custom metadata that standard Graph schemas don't cover.
There's also a granular permission model, so apps and users can be scoped tightly to read, export, or import — not all three by default. For anyone who's ever had to justify the blast radius of a service account during a security review, that matters.
A deliberately opaque export format
One detail worth flagging: the exported item format is intentionally opaque. Microsoft is explicit that it's designed to preserve item fidelity, not to act as a general-purpose interchangeable format. The supported pattern is round-trip — export an item, preserve the returned stream, and import it back into an Exchange Online mailbox.
If your migration design assumed you'd crack the format open and re-shape items along the way, you'll need a different tool for that part of the job. Think of these APIs as the modern equivalent of a high-fidelity copy operation, not an ETL pipeline.
What's in scope at GA — and what isn't
The initial GA covers primary mailboxes and shared mailboxes. That's it. Three significant categories are explicitly not in this release: archive mailboxes, public folders, and group mailboxes.
For organisations planning EWS migrations, that gap is the headline. Microsoft acknowledges these mailbox types matter to many customers and partners, says work is ongoing, and promises more updates soon — but there's no committed timeline in the announcement. If your migration plan depends on any of the three, you'll need either a phased approach, a fallback, or a hybrid using EWS for the residue while the clock ticks down.
Throttling and production realities
The import and export APIs use the same standard Outlook resource limits that apply elsewhere in Microsoft Graph. For large-scale moves, that means the usual planning around concurrency, backoff, and batching applies. Microsoft links to the Outlook service limits documentation directly in the announcement, and it's required reading before you size a migration runbook around these APIs.
If you tested the APIs in preview, the API model remains largely unchanged at GA, so moving from preview code to production should be a straightforward step for primary and shared mailbox scenarios.
Where this fits in the EWS exit plan
The strategic context here is the planned deprecation of EWS — which Microsoft cites directly as the reason these APIs exist. Closing the high-fidelity import/export gap for primary and shared mailboxes is real progress. Closing it fully — archives, public folders, groups — is what most enterprise migration plans actually need.
For now, the practical read is: start prototyping against the GA endpoints if your scope fits, get throttling and permissions right in a low-stakes tenant, and keep watching for updates on the unsupported mailbox types. The APIs being GA changes the conversation from "if" to "when and how."
This kind of behind-the-scenes platform shift rarely gets a keynote slot, but it's exactly the sort of thing that quietly shapes a year of migration projects across Europe — the consultants and architects in the ECS community will recognise the pattern. If you're scoping an EWS exit, this is one to put on the agenda alongside the rest of the Graph migration work already on your plate.