Your archive is where a credit union, bank, or mortgage company keeps what it is required to keep, and it is where people go when somebody asks for a loan file from four years ago. Microsoft starts switching off Exchange Web Services in October 2026. The Microsoft Graph replacement for archive mailbox access finishes arriving after that window opens. Here is what actually stops working, what Microsoft says it is building to replace it, and the three capabilities it has confirmed it will not add to Microsoft Graph at all.
Microsoft switches off a programming interface. It does that in two stages, and the second stage has no undo.
Exchange Web Services is the old programming interface that applications use to read and write mailbox data in Exchange Online. Backup products use it. Archiving and journaling products use it. Records management and legal hold tools use it. So do a great many small internal scripts that somebody wrote once and nobody has opened since.
Microsoft has published the timeline on its own documentation page, and it is short enough to quote in full:
“October 2026: EWS starts to be disabled globally for all organizations.”
“April 2027: EWS is fully disabled.”
The first date is a start, not a cutover. Disablement rolls out across tenants, and the specific timing for any one tenant appears in that tenant's own Message Center rather than on a public page. The second date is the floor. After April 2027 there is nothing to turn back on.
This applies to Exchange Online. Microsoft has stated that it is not making the same change to EWS in Exchange Server on-premises, so an institution running a hybrid Exchange server is dealing with a different question there.
Why Microsoft accelerated this. The same documentation page ties the urgency to a specific event: “The Midnight Blizzard security incident in January 2024 involved EWS and elevated the urgency of the EWS deprecation effort. The scope was also widened from third party applications to include all Microsoft applications.” That last clause is the part people miss. Microsoft is removing EWS from its own products too, including Outlook, Office, Teams, and Dynamics 365. This is not a third-party cleanup.
None of that is new. What is new, and what most institutions have not mapped, is where the retirement lands next.
Yes, and archive mailboxes were the piece Microsoft had not replaced yet.
When the mailbox import and export Microsoft Graph APIs reached general availability on May 7, 2026, the announcement was explicit about what was left out:
“The following mailbox types are not included in the initial GA release: Archive mailboxes”
So for most of 2026 the position was that primary and shared mailboxes had a supported Graph path and archive mailboxes did not. Microsoft has now addressed that. Message Center notice MC1469565, published September 9, 2026 and titled “Microsoft Purview | Data Lifecycle Management, Graph API Support for archive mailboxes”, sets out the rollout:
“General Availability (Worldwide): Beginning in late October 2026 and expected to complete by early November 2026”
“Applications and scripts that continue to use EWS for archive mailbox operations will stop functioning after EWS is disabled.”
The notice names the categories it expects to be affected: eDiscovery, compliance and records management workflows, data lifecycle management, backup and export tools, and custom applications.
Read those two rollouts against each other and the shape of the problem is clear. EWS begins to be disabled in October 2026. The Graph replacement for archive mailbox access begins general availability in late October 2026 and is expected to finish in early November 2026. Those windows overlap, and the replacement finishes after the retirement has already started.
The precise version, because the loose version is wrong. It is not accurate to say the replacement arrives after EWS is gone. Disablement starts in October and archive support starts reaching tenants in late October. What is accurate is narrower and still uncomfortable: the capability your retention tooling needs finishes shipping after the thing it replaces has begun to be switched off, on a date Microsoft itself describes as a target that might change, with a hard floor of April 2027.
There is a trap here for anyone who checks this themselves. The Microsoft Graph overview for the mailbox import and export APIs, last updated in July 2026, already states that “These APIs support access to data in users' primary, shared, and archive mailboxes on Exchange Online.” Read on its own, that page makes archive support look finished.
Microsoft Learn, Overview of the mailbox import and export APIs in Microsoft Graph. Page metadata read September 15, 2026 shows a last update of July 21, 2026.Documented is not the same as generally available in your tenant. Reference documentation is routinely updated as a capability moves through release, while the rollout that actually reaches a given tenant is tracked separately, which is what the Message Center window describes. The practical rule is the boring one: confirm against your own tenant rather than against a documentation page, and treat a documented capability as something to verify rather than something to assume.
A caveat that matters more than it looks, if your dependency is a backup product. That same Microsoft page carries an explicit limitation: “The mailbox import and export APIs in Microsoft Graph aren't designed for mailbox backup and restore.” Microsoft points backup and restore scenarios to Microsoft 365 Backup instead. So if the application you are worried about is a backup product reaching the archive through EWS, the import and export APIs are not automatically the place it lands. That is a question for the vendor, and it is a different question from whether the APIs exist.
Microsoft publishes a parity-gap roadmap. The archive rows on it are dated to the same quarter the retirement begins.
The deprecation page carries a table of the EWS capabilities that do not yet have a Microsoft Graph equivalent, with target dates. Two rows are about the archive, and both land in the fourth quarter of calendar year 2026.
Directly above that table Microsoft sets expectations in one sentence: “Estimated availability dates are targets and might change.”
| Capability | What Microsoft says it covers | Target |
|---|---|---|
| In-Place Archive (Generic CRUD) | Access and manage mailbox items in an existing In-Place Archive. This capability does not create archive mailboxes. | Q4 CY2026 |
| Import-Export (Archive) | Export and import mailbox items in archive mailboxes in a full-fidelity format. | Q4 CY2026 |
| Import-Export (Public Folder) | Export and import public folder items in a full-fidelity format. This capability does not include public folder create, read, update and delete operations. | Q4 CY2026 |
| Import-Export (Group) | Export and import items in Microsoft 365 Group mailboxes in a full-fidelity format. | Q4 CY2026 |
| Exchange Admin API | Manage selected Exchange recipient and mailbox settings, including folder permissions, through Exchange Admin APIs. | Q4 CY2026 |
| Sovereign Cloud availability | Make Exchange workload APIs required for EWS migration available in supported sovereign clouds. | Q4 CY2026 |
| User Configuration objects | Access and manage user configuration objects stored as folder-associated items in mailbox folders. | Q4 CY2026 |
| Non-draft MIME update and creation | Create or update non-draft messages by using MIME content. | Q4 CY2026 |
Read the first row carefully, because it contains a limit that matters for a migration plan. In-Place Archive generic access covers items in an existing archive. Microsoft states plainly that it does not create archive mailboxes. If a process in your environment provisions archives programmatically through EWS, that is a separate question from reading and writing the contents of one.
And then there is the sentence that governs everything not on the table. Microsoft puts it just above the roadmap:
“If an EWS capability isn't listed in this roadmap table, don't plan on a corresponding Microsoft Graph or Exchange Admin API capability being available before EWS is fully disabled.”
That is an unusually direct instruction from a vendor, and it is worth reading for exactly what it says. Microsoft is not promising that an unlisted capability never returns. It is telling you not to depend on one being available by the time EWS is fully disabled. For planning purposes the difference does not help you much: if a dependency is not on the roadmap, you cannot build an April 2027 plan around it arriving. The three capabilities in the next section are separate, and those Microsoft has ruled out directly.
Three capabilities. One of them is the legacy path into Discovery Mailboxes, which is a compliance surface rather than a mail feature.
Alongside the roadmap, Microsoft publishes a second and shorter table headed “Confirmed capabilities that won't be added”, with the instruction to “Plan migrations without a Graph equivalent for these capabilities.” Read that precisely: it says these capabilities are not coming to Microsoft Graph. It does not say the underlying work becomes impossible. For two of the three, Microsoft names where the work goes instead. What closes is the EWS route and the Graph route, which means tooling that took those routes has to be rebuilt against a different surface rather than repointed.
The Discovery Mailbox row is the one worth pausing on in a regulated environment. Legacy Discovery Mailboxes are where older search and hold workflows put their results. If a process in your environment still reaches into one through EWS, that process does not have a Graph equivalent coming, and rebuilding it on Purview eDiscovery is a different piece of work from swapping an interface.
The public folder distinction is worth reading twice as well. Import and export of public folder items is on the roadmap. Generic create, read, update and delete against public folders is not. An institution that still runs public folders for shared correspondence, and there are more of those than the industry likes to admit, should treat those as two separate answers.
A format detail that surprises people. Microsoft's own description of the export format in the import and export APIs is that it “is intentionally opaque and is designed to preserve item fidelity rather than to serve as a general-purpose interchangeable format.” If a plan assumes a Graph export produces a portable archive that some other system can read, that assumption is worth testing before it becomes a retention control.
That is the whole problem, and the first step is smaller than it sounds. We will pull the Exchange Web Services usage your tenant is already reporting, tell you which applications appear in it, and sort them by whether the operations they perform have a Graph equivalent available now, targeted later, or ruled out. Usage reporting shows which applications are calling EWS, so a complete answer for a vendor product still needs that vendor's written confirmation, and we give you the questions to send.
Request your free security assessmentBecause in a regulated institution the archive is not storage. It is the evidence.
At a software company, losing programmatic access to an archive mailbox is an inconvenience that gets fixed in the next sprint. At a credit union, bank, or mortgage company, the archive is where the correspondence sits that a retention schedule says has to be kept, produced, and searchable. The tooling that reaches it is doing compliance work, whether or not anyone has ever described it that way.
Three specific consequences are worth naming.
A records retention schedule is a commitment to produce, on request, for a defined period. If the mechanism that reaches the archive stops working in October and the replacement finishes shipping in November, the obligation still covers October. Nothing about Microsoft's rollout changes what you owe a regulator, an auditor, or opposing counsel during the gap.
This is a scenario worth testing rather than a rule, because how loudly a product fails depends entirely on that product. Consider an archiving job that can still authenticate and still run, but can no longer reach the archive. Depending on how it handles the error, it may write a smaller report, finish faster, and record a successful run. If your monitoring watches whether the job completed rather than what it collected, a run like that looks healthy. The question to put to your own tooling is specific: if the archive call fails, does this product raise an alert, and who receives it? That is answerable today, in a test, rather than in October.
Much of the archive tooling in a regulated institution belongs to a vendor, not to you. Your core provider, your archiving vendor, your backup product, your eDiscovery platform. Each of them has its own migration timeline and its own view of whether October matters. The useful question is not whether you have migrated. It is which of your vendors has, and what each of them says in writing.
The question examiners are already comfortable asking. Show us how you know your retention controls are working. That question does not require an examiner to have read a Microsoft deprecation notice. It only requires them to ask you to produce something, and for you to be able to.
Productivity is the first thing people feel when this breaks, because somebody cannot find a file. The security question follows, because a scramble to keep a legacy interface alive is how exceptions get written and never removed. The governance question arrives last and stays longest, because that is the one that turns up in a report.
Your tenant is already collecting the answer, in a report many administrators have never had a reason to open.
Microsoft ships first-party tooling for exactly this question, and the first one takes minutes rather than a project.
Microsoft 365 includes EWS Usage Reports in the admin center. They show which applications in your tenant are calling Exchange Web Services and how often, and they are already being gathered whether or not anyone has looked. Treat this as the starting inventory rather than the complete one. The reporting aggregates on a weekly cadence and can lag, so an application that runs monthly, quarterly, or only at year end may not appear in the window you happen to open. Check a window wide enough to contain your least frequent job, and pair the report with what you know about your own calendar.
Sort by operation as well as by mailbox type, because the May 2026 general availability was specific. It covered the mailbox import and export APIs, for primary and shared mailboxes. It did not establish a Graph equivalent for every operation an application might perform against a primary mailbox. So the question for each application is which operations it actually performs, against which mailbox type. An application importing or exporting primary mailbox items has had a supported path since May 2026. One that reaches an archive is on a later clock. One that reaches a legacy Discovery Mailbox is a rebuild, because Microsoft has ruled a Graph equivalent out and points that work to Purview eDiscovery. Those are different remediation problems and they should not sit in one line item.
For internal scripts and applications, Microsoft publishes an EWS Analyzer tool and an AI assisted migration tutorial that walk through analyzing and refactoring EWS code. The mapping between EWS operations and their Graph equivalents is published as well.
For anything you did not write, the answer has to come from the vendor. Three questions are enough: does your product use Exchange Web Services today, does it reach archive mailboxes or Discovery Mailboxes, and on what date will a version that does not need EWS be available to us. A vendor that cannot answer the third question in writing has told you something useful.
One sequencing note. Inventory first, migrate second. The temptation with a dated retirement is to start moving the application somebody already had concerns about. The applications that cause outages are the ones nobody remembered, and the usage report is what surfaces those.
Four things, in order. The first two are an afternoon of admin-centre work.
October 2026 is the start of a disablement process rather than an instant switch, and Microsoft documents that process, including a tenant-level control over whether EWS is enabled and an application allow list that names which applications may still call it. That is a runway, not a reprieve: it is administered per tenant, it is bounded by the April 2027 full disablement, and it keeps a dependency alive rather than removing it.
The mechanics of that allow list, including how to inventory applications for it, are the subject of our companion page on the EWS application allow list, and the deadline history is covered in the related article. Read them together with this one: this page tells you which archive dependencies exist and which have a replacement coming, and those tell you what to do about the ones that will not be ready. Confirm the current process against Microsoft's own documentation before you rely on it, because this is the part of the retirement Microsoft has revised most.
If your institution also still runs an on-premises Exchange server for hybrid management, that server has its own separate set of dates that are worth checking in the same pass.
And if the inventory step is where this stalls, which is where it usually stalls, that is the part we will just do for you.
ABT is a Tier 1 Microsoft Cloud Solution Provider, and we manage Microsoft 365 tenants for more than 750 financial institutions. The assessment covers the question this page is about, and the rest of the tenant while we are in there.
ABT also operates M365 Guardian, its managed security service for credit unions, banks, and mortgage companies. You can read what that covers on the M365 Guardian page.
Dates and capability descriptions on this page are quoted from Microsoft's own wording. Microsoft describes the roadmap dates as targets that might change, and this page repeats that qualification rather than presenting the targets as commitments. Tenant-specific rollout timing appears in each tenant's Message Center and is not reproduced here.
The allow list side of the same retirement. If your tenant still needs EWS after October, this is the mechanism that keeps it alive and the date that actually governs it.
Read the article
Where Microsoft points legacy Discovery Mailbox workflows. The licensing rule reverses by tier, which catches institutions out when they plan the move.
Read the article
The companion habit. An exception written to keep a legacy integration working persists until somebody removes it, and almost nobody does.
Read the articleTell us roughly how many mailboxes you run and which archiving or backup products touch them. Our engineers will pull the Exchange Web Services usage your tenant already reports, separate the applications with a supported Microsoft Graph path from the ones without one, and give you the vendor questions to send.
