Every time Microsoft ships an API with “Exchange” and “admin” in the name, my inbox fills with the same question: do we rewrite everything now? Short answer for the new Exchange Admin API, detailed in a new Practical365 explainer: almost certainly not.
Here’s the thing the headline energy misses. This is not a general-purpose Exchange Online administration API. It is a migration lifeboat for a specific, shrinking population, developers who built admin-adjacent integrations on Exchange Web Services and have spent years watching EWS get quietly deprecated out from under them. That’s who Microsoft built this for. If you are not that person, you can mostly keep scrolling.
The scope is deliberately narrow, and the narrowness is the feature, not a bug someone forgot to fix. It gives EWS developers a supported, REST-based path to move the administrative functions their apps depended on. It does not become your new front door for mailbox and calendar operations, that’s Microsoft Graph, and it stays Graph. It does not replace Exchange Online PowerShell for tenant-wide configuration, transport rules, mailbox provisioning, retention, or the thousand other things you actually do all day. Anyone telling you to refactor your EXO PowerShell runbooks against this thing has misread the announcement.
So what actually made the cut? The API covers the administrative operations EWS apps needed that Graph never cleanly replaced, folder-level and delegate-level work. Think mailbox folder permissions, delegate management, admin-scoped impersonation, automatic replies, and inbox rules managed on a user’s behalf. What it deliberately leaves alone is the tenant surface: mailbox and distribution-group provisioning, transport and mail-flow rules, retention and compliance policy, connectors, organization config, all of that stays in Exchange Online PowerShell. Ongoing mailbox content, messages, events, contacts, stays in Graph. Read the coverage list in the Practical365 writeup line by line before you commit, because ‘migrate your EWS admin app’ quietly implies that some functions may still have no supported home. If your integration does something exotic, confirm it’s covered before you spend a sprint on it.
Let me save you the architecture meeting. Three questions decide where your code belongs:
- Managing tenant configuration or running admin tasks across many mailboxes? Exchange Online PowerShell (the
ExchangeOnlineManagementmodule). This is not changing. REST has not caught up to the surface area of those cmdlets, and it won’t soon. - Reading or writing mailbox content, messages, calendar, contacts, mailbox settings, from an app? Microsoft Graph. That has been the answer for a while and this announcement doesn’t move it an inch.
- An EWS developer whose integration performs administrative functions Graph never covered, with no supported landing spot? Now we’re talking. This API exists for you specifically.
That last bucket is real and it has been genuinely painful. The gap between “EWS is deprecated” and “here is the supported replacement for everything EWS did” has been wide and poorly signposted for years. Vendors shipping migration tooling, archiving connectors, and compliance workflows have lived in that gap, holding their breath with each deprecation notice. A supported REST surface closes part of it. That’s worth acknowledging without pretending it’s a revolution.
On the edges the announcement doesn’t fully settle: authentication will likely follow the modern Entra pattern, app registration, token-based, application permissions, but don’t harden that assumption into a design until the docs confirm the exact permission model. Throttling will exist because throttling always exists; don’t architect a bulk migration around limits nobody has published yet. And check whether any specific licensing is called out before you assume your existing entitlements cover it, the announcement I’ve seen doesn’t flag a new requirement, but ‘doesn’t mention one’ is not the same as ‘there isn’t one.’
The honest risk here isn’t that this API is bad. It’s that its name invites scope creep. Someone on your team will see ‘Exchange Admin API,’ assume it supersedes PowerShell, and start building tenant automation against a surface that was never meant to carry it. That decision bites in about six months, when the function you need isn’t there and you’re retrofitting Graph and EXO PowerShell back in anyway.
Treat it as what it is: a targeted bridge off a deprecated platform, not a new platform. If you run EWS admin code, get it on the backlog and read the coverage list carefully. If you don’t, the right amount of effort to spend on this is roughly zero.