Microsoft is retiring Exchange Web Services (EWS) in Exchange Online. From 1 October 2026 Microsoft starts switching EWS off tenant by tenant, and on 1 April 2027 it is switched off permanently. CloudM Migrate uses EWS for some Microsoft 365 workloads today, so this affects any migration running in that window.
We are moving those workloads to Microsoft Graph. Until that work is generally available, you can keep your migrations running by adding your CloudM Migrate app registration to Microsoft's EWS allow list. This article covers what is affected, what we are doing, and the steps to take.
If your migration finishes before October 2026, you do not need to do anything. If it runs during or after October 2026 and includes mail, calendars, contacts, tasks or notes on Microsoft 365, follow the steps in Keeping EWS working in the meantime below.
What EWS retirement affects
The change applies to Exchange Online only. On-premises Exchange servers and hosted Exchange servers are not affected, and connections to them carry on as they are.
For Microsoft 365, this is what CloudM Migrate uses today:
| Workload | Connects through | Affected |
|---|---|---|
| Exchange Web Services | Yes | |
| Calendars | Exchange Web Services | Yes |
| Contacts | Exchange Web Services | Yes |
| Tasks | Exchange Web Services | Yes |
| Notes | Exchange Web Services | Yes |
| OneDrive and SharePoint | Microsoft Graph and SharePoint APIs | No |
| Microsoft Teams | Microsoft Graph | No |
| Microsoft 365 Groups and Planner | Microsoft Graph | No |
| User, group and directory discovery | Microsoft Graph and Exchange Online PowerShell | No |
This applies whether Microsoft 365 is your source or your destination. A Google Workspace to Microsoft 365 migration writes mail into Exchange Online over EWS, so it is affected in the same way as a migration out of Microsoft 365.
Microsoft's timeline
| Date | What happens |
|---|---|
| 1 October 2026 | Microsoft begins setting EWSEnabled to False in tenants where it has not been configured, rolling out progressively. Once that reaches your tenant, EWS is blocked for every application unless you have set an allow list. |
| 1 April 2027 | EWS is fully disabled in Exchange Online. The allow list stops working and no configuration will keep EWS available. |
Microsoft's own summary is in Deprecation of Exchange Web Services in Exchange Online.
What CloudM is doing
We are moving CloudM Migrate's Microsoft 365 mail, calendar, contacts, tasks and notes connectors from Exchange Web Services to Microsoft Graph, ahead of Microsoft's April 2027 shutdown.
Graph support for these workloads is in development and is not in general release yet. Check the release notes for the version that introduces it. Everything below is what to do in the meantime.
Keeping EWS working in the meantime
Microsoft lets you name the applications that are still allowed to use EWS. Adding your CloudM Migrate app registration to that list keeps migrations running until April 2027.
Before you start, you need:
- An account with the Exchange Administrator or Global Administrator role in the Microsoft 365 tenant.
- The Exchange Online PowerShell module installed.
- The client ID of the app registration CloudM Migrate uses for the connection.
Step 1: find your app registration's client ID
The app registration lives in your own tenant. It is the one created when you set up the Microsoft 365 connection, either with the Create Azure AD application button or with CloudM's PowerShell script.
To find its client ID, either:
- In CloudM Migrate, open your Microsoft 365 connection settings and copy the value in Application permissions client id.
- Or in the Microsoft Entra admin centre, go to App registrations and open the application. The automated setup names it CloudM Migrate; the limited scopes script names it with a
CloudM-prefix. Copy the Application (client) ID.
If you migrate Microsoft Teams you will also have a second, delegated application. That one uses Microsoft Graph only, so it does not need to be on the EWS allow list.
Step 2: check what is already on the allow list
Connect to Exchange Online PowerShell and read the current settings:
Connect-ExchangeOnline
Get-OrganizationConfig -RetrieveEwsOperationAccessPolicy | Format-List EwsEnabled,EwsAllowedAppIDsNote the -RetrieveEwsOperationAccessPolicy switch. Without it, EwsAllowedAppIDs comes back empty even when a list is set.
Write down any app IDs already in the list. You need them in the next step.
Step 3: add CloudM Migrate to the allow list
Setting EwsAllowedAppIDs replaces the entire list. There is no option to add or remove a single entry. Always include every app ID that still needs EWS, including the ones you noted in step 2, or you will cut off another application.
If nothing else needs EWS, run this with your own client ID in place of the example:
Set-OrganizationConfig -EwsEnabled $true -EwsAllowedAppIDs "00000000-0000-0000-0000-000000000000"If other applications need EWS too, list them all, separated by commas:
Set-OrganizationConfig -EwsEnabled $true -EwsAllowedAppIDs "existing-app-id,cloudm-migrate-app-id"Set both parameters together. Once enforcement reaches your tenant, EwsEnabled set to $true with no allow list blocks every application rather than allowing them.
Step 4: confirm it worked
- Run the
Get-OrganizationConfigcommand from step 2 again and check thatEwsEnabledisTrueand your client ID appears inEwsAllowedAppIDs. - In CloudM Migrate, run a connection test on the Microsoft 365 connection.
Changes to organisation settings take a while to apply across the service. If a connection test fails straight after you make the change, wait and try again before troubleshooting anything else.
Step 5: repeat on the other tenant if needed
The allow list is per tenant. For a Microsoft 365 to Microsoft 365 migration, do this in the source tenant and the destination tenant.
Troubleshooting
Mailbox operations fail with an access denied or 403 error
Cause: EWS has been blocked at the tenant level, either because Microsoft's rollout reached your tenant or because an administrator set EwsEnabled to False.
Resolution: Follow the steps above. Check EwsEnabled is True and that the CloudM Migrate client ID is in EwsAllowedAppIDs.
The allow list is set, but one user's mailbox still fails
Cause: EWS has been disabled on that individual mailbox.
Resolution: Check and re-enable it for that user:
Get-CASMailbox user@contoso.com | Format-List EwsEnabled
Set-CASMailbox user@contoso.com -EwsEnabled $trueThe per-mailbox setting only has an effect while the organisation-level EwsEnabled is not False.
Another application stopped working after setting the allow list
Cause: EwsAllowedAppIDs was overwritten rather than added to.
Resolution: Run Set-OrganizationConfig again with the full comma-separated list of every app ID that needs EWS.
EwsAllowedAppIDs comes back empty
Cause: Either the -RetrieveEwsOperationAccessPolicy switch was left off the Get-OrganizationConfig command, or Microsoft's rollout of the setting has not reached your tenant yet.
Resolution: Re-run the command with the switch. If it is still empty and you cannot set a value, the rollout has not reached you. Check again in a few days.
Frequently asked questions
Does this affect on-premises or hosted Exchange migrations?
No. Microsoft is retiring EWS in Exchange Online only. Migrations from an Exchange server you or a hosting provider runs are unaffected, and the connection setup for them does not change.
Does it affect migrations that do not touch Microsoft 365?
No. A Google Workspace to Google Workspace migration, or any migration between two non-Microsoft platforms, uses no EWS at all.
My migration only covers OneDrive and SharePoint. Do I need to do this?
No. Those workloads already run on Microsoft Graph and the SharePoint APIs.
What happens on 1 April 2027?
The allow list stops working and EWS is gone. Any migration involving Microsoft 365 mail, calendars, contacts, tasks or notes after that date needs a version of CloudM Migrate running those workloads on Microsoft Graph.
Should I set this up even if my migration is short?
If any part of it runs on or after 1 October 2026, or you are not certain of the dates, set it up. It is a single command, it takes effect immediately for your tenant, and you can undo it by setting EwsAllowedAppIDs to $null.
Can I restrict the application to specific mailboxes instead?
Yes, and it is worth doing separately from this. See Azure AD Application - Limited Scopes - PowerShell Method. Limiting scopes does not remove the need for the EWS allow list.