From 1 October 2026, Microsoft starts disabling Exchange Web Services (EWS) in Exchange Online. Tenants that have not kept it enabled with an approved application list will have EWS blocked for every application, and on 1 April 2027 it is switched off permanently. Older backup tools, CRM email integrations and custom scripts stop working unless they move to Microsoft Graph.
EWS has been the plumbing behind Exchange integrations for nearly two decades, which is exactly why this retirement matters more than most. Microsoft announced in July 2018 that EWS would receive no new feature updates, then set the retirement date in 2023, giving three years' notice. The final disablement plan is now published, and it applies to Exchange Online and Microsoft 365 only. On-premises Exchange Server keeps EWS, so hybrid organisations only need to review workloads pointed at cloud mailboxes.
What exactly happens on 1 October 2026?
Every Exchange Online tenant has an organisation-level setting called EWSEnabled. Most tenants have never touched it, which leaves it at the default of null. From 1 October 2026, Microsoft changes every tenant still on the default to false as the rollout proceeds, and that blocks EWS requests from all applications in the tenant.
Businesses that genuinely need more time have a controlled bridge. An administrator can set EWSEnabled to true and configure an allow list of application IDs, known as EWSAllowedAppIDs, so that only the applications named on the list can keep calling EWS. During September 2026, Microsoft will pre-populate the allow list for tenants that have not created one, based on each tenant's own recorded usage. The bridge is short: on 1 April 2027, EWS is fully and permanently disabled for Exchange Online, with no exceptions and no further extensions.
A tenant that discovers a broken integration after the block can re-enable EWS temporarily, but Microsoft notes there will be a service interruption while that happens. That is exactly the kind of surprise a payroll run or client-billing system does not need in the first week of a new quarter.
Does this affect Outlook, Teams or on-premises Exchange?
Day-to-day users should notice nothing on 1 October. Microsoft has been removing EWS dependencies from its own products, including Outlook, Teams, Office and Dynamics 365, and it manages the transition for first-party applications itself. Nobody needs to patch Outlook to keep reading email, and Teams calendars keep working.
On-premises Exchange Server is out of scope entirely; Microsoft has confirmed there are no changes to EWS on Exchange Server. It is also a platform change handled with unusually long notice. The deprecation was signalled in 2018 and the retirement date announced in 2023, so software vendors have had years to build against the replacement API, and most mainstream products long since have.
What still uses EWS in a typical Australian business?
The awkward part of this retirement is that EWS is invisible until it breaks. It sits underneath software the business bought years ago and has not thought about since. Walking this checklist against the application register is a sensible first pass:
- Backup products, particularly older mailbox-level backup tools that read Exchange data directly
- CRM and practice-management systems that file email against client or matter records
- Document management systems, especially legal DMS platforms with email-filing features
- Meeting-room booking panels and resource-scheduling tools that read shared calendars
- Telephony and voicemail platforms that deliver voicemail-to-email or read calendar presence
- Mailbox migration and archiving tools kept around after a past project
- Custom scripts and in-house integrations built on the EWS Managed API, often written by a developer who has since moved on
The trap is that a product can look current while its connection method is not. Plenty of vendors shipped Microsoft Graph support years ago, but the copy installed on the server is still an old build talking EWS. The version number on the invoice says nothing about the API underneath.
How do you find EWS usage in your tenant?
Microsoft has made the audit reasonably painless. The Microsoft 365 admin centre includes a dedicated EWS Usage Report, found under Reports, then Usage, then Exchange. It lists every application ID that has called EWS in the tenant, which operations it used, how often, and when it was last active. That report is the single best starting point for the whole exercise.
Application IDs can then be matched to named products through Microsoft Entra ID app registrations and sign-in logs, which also shows who owns each integration and whether it is still in real use. Microsoft additionally sends targeted Message Centre notices about active Exchange Web Services applications to tenants where usage is detected. For in-house code, Microsoft publishes an EWS code analyser that flags the exact calls needing rework.
If the report comes back empty
A tenant with an empty usage report and no Message Centre notices about active EWS applications is probably clear. It is still worth checking scheduled tasks on ageing servers, because a script that runs quarterly may not appear inside a short reporting window.
What does moving to Microsoft Graph involve?
For purchased software, the work is mostly vendor management. Ask each vendor whether a Microsoft Graph-based version exists, then schedule the upgrade and test it against a pilot mailbox. Most mainstream products already support Graph; the real job is getting the installed version up to date before the deadline, and vendor support queues will only get longer as October approaches.
Custom integrations are the bigger job. Anything written against the EWS Managed API needs redevelopment, because Graph is a different API with a different permission model rather than a rename. Microsoft publishes direct mappings from EWS operations to Graph calls and reports near-complete parity for the vast majority of scenarios, which makes the rework predictable, but it still needs developer time and a proper test window.
The destination is better than what it replaces. An EWS application typically holds sweeping access to mailbox data, while Microsoft Graph grants granular permissions scoped to exactly what the application needs, backed by modern authentication. Security reviewers and cyber insurers increasingly expect that posture, so the migration doubles as a genuine hardening exercise.
Why August is the month to do this
For Australian businesses the calendar is unhelpful. The block lands on 1 October 2026, the day after the first quarter of the financial year closes. That makes September the natural month for testing, exactly when finance teams are consumed by quarter-end and BAS preparation, and when a broken CRM email feed or backup job would hurt most.
Running the audit in August leaves room to move. A realistic sequence takes four to six weeks: pull the usage report, put a name against every application ID, lodge upgrade requests with vendors, rebuild or retire custom scripts, then retest before the deadline rather than after it. Waiting until late September converts a routine piece of maintenance into an outage response.
Frontrow runs the EWS audit as a fixed piece of work: pulling the usage report, identifying every application still calling the API, coordinating vendor upgrades and configuring the allow-list bridge only where one is genuinely needed. Businesses that want this settled before October can call 1300 012 466 and have their tenant's usage report reviewed the same week.