Microsoft is switching EWS off. Find what still reaches your archive.

Microsoft started the deprecation of Exchange Web Services in Exchange Online on October 1, then worked through the steps it had published. Here is the record, and the stage the retirement has reached.

Exchange Web Services is the older 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.

On this page, archive mailbox means Microsoft's Exchange Online archive: the In-Place Archive attached to a mailbox, including any auxiliary archives that auto-expanding archiving creates. An institution's records estate can be wider than that, so treat an affected application as a reason to check the records it handles.

On October 1, Microsoft's Exchange Team put the start in one line:

Microsoft has updated that post through October as each step landed in its worldwide (multi-tenant) cloud. Read the record as a sequence, because where your tenant stands depends on how it was configured before each step.

Government cloud tenants follow their own schedule. Microsoft says the behavior change starts in the worldwide cloud and that tenants in other clouds get timelines specific to them through Message Center.

Microsoft's guidance for organizations whose EWS applications have stopped working names the stage in one sentence: “We are now in the first stage of EWS disablement, where customers are still able to re-enable EWS.”

The same retirement page on Microsoft Learn still frames the whole program in two dates: “October 2026: EWS starts to be disabled globally for all organizations” and “April 2027: EWS is fully disabled.” It also explains why Microsoft is doing this: “The Midnight Blizzard security incident in January 2024 involved EWS and elevated the urgency of the EWS deprecation effort.” The page now opens with a pointer for anyone whose EWS applications have stopped working.

Because the jobs that touch an archive tend to run on a calendar, and the list Microsoft writes comes from a 60-day window.

Microsoft is direct about the limits of the lists it writes. Its October notice says “Infrequently used applications may not be identified.” An earlier notice adds that its lists “may omit applications that run infrequently and may include applications that no longer require EWS access.”

Now picture the archive side of a credit union, bank, or mortgage company. A quarterly retention export. A month-end journaling reconciliation. A year-end sweep that confirms legal holds. An eDiscovery search that runs only when counsel asks for one. A job on a cycle longer than 60 days can run entirely outside the window Microsoft reads. If its application ID made no other EWS call inside that window, nothing puts it on the list.

Microsoft's notice on archive mailboxes names the kinds of software it expects to be affected: eDiscovery solutions, compliance and records management workflows, data lifecycle management solutions, backup and export tools, and custom applications that access archive mailboxes. Its consequence is one sentence:

The usage report counts successful calls

The EWS usage report in the Microsoft 365 admin center shows, in Microsoft's description, “the successful-call volume for each SOAP action.” For each application it lists the application ID, the SOAP action, the call volume and the last activity date, and it filters to the last 7, 30 or 90 days. Microsoft also notes that “Usage data is collected and aggregated weekly, not daily. It can take up to 10 days for usage to show in the report.”

That shapes how a blocked application looks. Because the report counts successful calls, an application whose calls are being refused shows up as a call volume that falls and a last activity date that stops advancing. So read the report twice: once for the applications that are still calling, and once for the ones that went quiet.

The hybrid case: on-premises mailboxes with archives in Exchange Online

One archive arrangement has its own instruction from Microsoft. If your institution keeps mailboxes on an on-premises Exchange server and their archives in Exchange Online, the Exchange Team wrote on September 30 that “the scenario where on-premises mailboxes have archive mailboxes in Exchange Online is not fully supported yet,” and added: “We expect this to be enabled in following months.”

Until then, Microsoft's instruction for that scenario is to keep EWS working: keep EWS permissions on the Exchange SE servers for now, set the tenant's EWSEnabled to True, and add the dedicated Exchange hybrid application to the allow list. Hybrid organizations that host no mailboxes on-premises, and on-premises mailboxes that do not use online archiving, are outside this case.

Five checks, in order. With allow lists in force and switch-offs under way, they find a break that has already happened and the dependencies still waiting on a schedule. The first two take minutes in PowerShell and the admin center.

1. Read your two settings and write them down

Run the two commands above and save the output with the date. That gives you your current row of the table and a dated record of what the tenant allowed and when. Your change records add the history: who wrote the list, and when.

2. Compare the usage report with the allow list

Export the EWS usage report for the last 90 days. An application that appears in the report and on the allow list keeps EWS access while EWSEnabled is True. An application that appears in the report and is missing from the list has no EWS access wherever the list is in force, and none at all once Microsoft switches EWS off in a tenant that never set it. Then look for applications whose last activity date stopped moving. Investigate each one against its expected run schedule and the report's reporting delay, then check the job's own logs.

A 90-day report is a list of what called recently, so build the job calendar beside it: the scheduled jobs inside each archiving, backup, retention and eDiscovery product, your application inventory, and a confirmation from each workflow owner. Keep three lists apart: dependencies the report shows, dependencies you found another way, and open items still waiting on an owner or a vendor.

3. Check what each archive job collected

For each archive, retention, backup and eDiscovery job, compare what the last run collected with what a normal run collects: item counts, export sizes, mailboxes processed. A job that authenticates, runs and records success while reaching less of the archive looks healthy on a status dashboard. Whether a given product fails loudly or quietly depends on that product, which makes this a test to run on each one.

4. Separate an allow list block from a sign-in failure

Microsoft's field guide names the mistake it sees most often in this step: “Treating an OAuth, permission, consent, or credential failure as proof that EWSAllowedAppIDs blocked the request.” Rule those causes out first. The same guide gives a controlled before-and-after test for proving the allow list behaves as expected for one application, run in a test tenant where you can, with at least 24 hours after each change.

5. Put four questions to each vendor in writing

For anything you did not write, the answer has to come from the vendor. Four questions cover it. Does your product use Exchange Web Services today? Does it reach archive mailboxes or Discovery Mailboxes? What is your supported replacement for EWS, and on what date is it available to us? And if that replacement uses Microsoft Graph, does it handle the archive redirects Microsoft documents?

The last question earns its place. Microsoft documents that an auto-expanding archive can spread across a main archive and auxiliary archive mailboxes, that Graph can answer a request with an HTTP 308 redirect or an ErrorArchiveFolderMovedPermanently error pointing to where the content lives, and that “Well-known folder names aren't supported for archive mailboxes,” so archive folders are referenced by folder ID.

A supported replacement path for every archive dependency you keep: a Microsoft Graph route where one exists, the Microsoft service Microsoft names where it points the work elsewhere, and a rebuild for the three capabilities it has ruled out.

The Graph replacement for archive mailbox access is the step still open. Message Center notice MC1469565 set its rollout window, and that window has now arrived:

The public Microsoft Learn roadmap still lists the archive capabilities with a Q4 CY2026 target, and sets expectations in one sentence: “Estimated availability dates are targets and might change.”

Read the first row carefully, because it carries a limit that matters for a migration plan. In-Place Archive generic access covers items in an existing archive, and Microsoft states that the capability doesn't create archive mailboxes. A process that provisions archives programmatically through EWS is a separate question from one that reads and writes the contents of an archive.

The Microsoft Graph documentation already reads as finished: its overview states that “These APIs support access to data in users' primary, shared, and archive mailboxes on Exchange Online.” General availability reaching your tenant is tracked separately, through MC1469565 and the roadmap rows above, so confirm it in your own tenant before a migration depends on it.

Auto-expanding archives also have a higher ceiling. Microsoft scheduled the worldwide rollout that raises the limit for eligible licenses from 1.5 TB to 3 TB per mailbox for mid-October to late October 2026, and a later notice schedules the government clouds from mid-November to early December 2026. That notice lists the eligible licenses, among them Microsoft 365 E5 and the Microsoft 365 Purview Suite, and states that mailboxes without an eligible license stay at 1.5 TB. Any Graph-based tool that reads an expanded archive has to follow the redirects described above.

Alongside the roadmap, Microsoft publishes a shorter table headed “Confirmed capabilities that won't be added”, with the instruction to “Plan migrations without a Graph equivalent for these capabilities.” For two of the three, Microsoft names where the work goes instead. What closes is the EWS route and the Graph route, so tooling that took those routes is rebuilt against a different surface.

The Discovery Mailbox row is the one to pause on in a regulated environment. Legacy Discovery Mailboxes are where older search and hold workflows put their results. A process that still reaches into one through EWS has no Graph equivalent coming, and rebuilding it on Purview eDiscovery is a different piece of work from swapping an interface.

And one sentence governs everything absent from the table. Microsoft puts it just above the roadmap:

Because in a regulated institution the archive holds records a retention schedule says you must produce.

At a credit union, bank, or mortgage company, the archive holds the correspondence 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 consequences follow.

Your retention obligation runs straight through the gap

A records retention schedule is a commitment to produce, on request, for a defined period. If a retention job loses EWS access this autumn and its Graph version arrives months later, the obligation still covers the months in between. Microsoft's rollout leaves what you owe a regulator, an auditor, or opposing counsel exactly where it was. An affected application is a reason to test what it collected and to check the records it covers.

Some failures can be quiet

Consider an archiving job that can still authenticate and still run, but has lost its path into 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 records only whether the job completed, 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?

The code that breaks often belongs to a vendor

Much of the archive tooling in a regulated institution belongs to a vendor: your core provider, your archiving vendor, your backup product, your eDiscovery platform. Each of them has its own migration timeline. The useful question is which of your vendors has moved, and what each of them says in writing.

Productivity is the first thing people feel when this breaks, because somebody cannot find a file. Security follows, because a scramble to keep a legacy interface alive is how exceptions get written and never removed. Governance arrives last and stays longest, because that is the one that turns up in a report.