Say a 40-person distributor has a Microsoft 365 to Google Workspace move booked for January. The runbook names Google Workspace Migrate, because that is the tool almost every older guide names for Exchange Online. That runbook no longer works, and the reason has two halves: one on Google's side, one on Microsoft's.
What Google's own pages say, and where they disagree
Checked on 28 October 2026, the Google Workspace Migrate help pages carry two separate notices. For mail: starting October 2026, Google Workspace Migrate for Exchange Online will no longer be available, and the page tells you to switch to the advanced data import tool. For files: starting 15 September 2026, Google Workspace Migrate for SharePoint Online and OneDrive will no longer receive updates and bug fixes.
Those are two different kinds of statement. The files connector is frozen, not switched off. The Exchange Online connector is the one with an end date on it.
There is a wrinkle worth knowing. The Google Workspace migration product matrix, a different page, has been wording the same retirement as the end of 2026, while the Workspace Migrate pages say October 2026. The two do not line up. When two pages from the same vendor disagree about a deadline, we plan for the earlier one. Nobody has ever been hurt by migrating a month early.
Why October 2026: Microsoft is switching off Exchange Web Services
Google's Exchange requirements page is explicit about how the old connector talks to a tenant. It tells you to enable Exchange Web Services and make sure the machine running the Google Workspace Migrate software can reach it. For Exchange Online it asks you to authorise the full_access_as_app scope, which grants access to every mailbox in the tenant through EWS, alongside EWS.AccessAsUser.All, and it names the endpoint the tool connects to:
outlook.office365.com/EWS/Exchange.asmxNow Microsoft's side. Microsoft's deprecation notice for Exchange Web Services in Exchange Online says phased disablement begins on 1 October 2026 and EWS is fully disabled by 1 April 2027. The scope is Microsoft 365 and Exchange Online only: on-premises Exchange is not affected, and neither are Outlook for Windows or Mac, Teams, or other Microsoft products.
Put the two pages side by side and Google's date stops looking arbitrary. A migration tool whose Exchange Online connector runs on EWS has exactly as much runway as EWS does. The replacement had to be built on something else, and it was: the data import tool authenticates with Microsoft Graph application permissions, not EWS.
One detail from Microsoft's Exchange team is worth checking in your own tenant now, because it bites before the final date. Microsoft is rolling out an EWSAllowedAppIDs setting, an allow list of application IDs permitted to use EWS. Tenants that have never set EWSEnabled behave as unrestricted today, and those are the tenants that get EWS disabled as part of the staged shutdown. A separate licence-based block for Kiosk and Frontline users moved to October 2026 as well, so a tenant can lose EWS for some of its people before it loses it for all of them.
Who this actually hits
Smaller than you would guess, and more urgent than you would guess.
- Anyone with a Microsoft 365 to Google Workspace move planned for late 2026 or 2027. If a proposal, a statement of work or an internal plan names Google Workspace Migrate for the mail side, that line is now wrong and needs replacing before the project starts, not during it.
- Anyone mid-project with Workspace Migrate servers already standing. Workspace Migrate is self-hosted on Windows servers. Those machines, and the connection you built against the tenant, are the part with a clock on it.
- Not on-premises Exchange sources. Microsoft's change covers Exchange Online. An Exchange 2007 to 2019 server on your own hardware keeps its EWS, and Google still lists Google Workspace Migration for Microsoft Exchange for those sources.
- Not a Workspace to Workspace move, and not Dropbox or Box. Those paths never went through EWS and are untouched by either notice.
Migrating the other direction, from Google into Microsoft 365, is untouched by this: Microsoft's tooling for that route has its own schedule.
What we check first on a client project
When a mail migration lands on our desk this quarter, these are the six answers we want before anybody touches a console.
- What the source really is: Exchange Online, an on-premises Exchange server, or a hosted mailbox that only speaks IMAP. The three take different tools.
- How many users, counted as mailboxes that need moving rather than licences bought. The tool you are allowed to use changes at 1,000.
- Whether a Google Workspace Migrate instance already exists, and what it has already copied. A half-finished copy is a decision, not a given.
- Whether the Microsoft tenant has
EWSEnabledor an app allow list configured, and whether any other integration in the business still depends on EWS. Migration is rarely the only thing using it. - Whether the users exist and are licensed on both sides. The data import tool does not create accounts, so a missing user is a silent skip, not an error you will enjoy finding later.
- Who holds a Microsoft Global Administrator or Privileged Role Administrator account, because somebody has to consent to the Azure application, and who holds Google super admin.
Which tool to use now
This is the table the old runbook needs. Tiers come from Google's migration product matrix and the data migration pages, checked 28 October 2026.
| Source | Size | Tool to use now |
|---|---|---|
| Exchange Online mail, calendar, contacts | 1 to 1,000 users | Data import, default method |
| Exchange Online | 1,001+ users | Advanced data import, Azure application required |
| OneDrive to My Drive | 1 to 1,000 users | Data import |
| SharePoint Online to shared drives | Up to 1,000 sites at a time | Data import |
| Microsoft Teams to Google Chat | Same tiers as Exchange Online | Data import |
| On-premises Exchange 2007 to 2019 | Up to 1,000 users | GWMME, unaffected by the EWS change |
The advanced method is not simply the big-company version. It uses your own dedicated API quota, it imports in batches of up to 5,000 users with up to 20 batches running at once, it can scan a batch before or after the import to produce planning and audit reports, and group mailboxes are supported only there. On a 300-person migration with messy shared mailboxes we will sometimes reach for it anyway.
Setting up the replacement: the Azure application
The data import tool is set up in the Google Admin console and runs in Google's cloud. No servers to stand up, which is the biggest practical difference from Workspace Migrate. What you do build is an application registration on the Microsoft side, either with a PowerShell script in Azure Cloud Shell or by hand in the Azure portal. Google recommends registering it as single tenant.
The application asks for Microsoft Graph application permissions. Google's setup script requests this set, and an administrator has to consent to them:
Mail.Read
MailboxFolder.Read.All
MailboxItem.Read.All
MailboxItem.Export.All
MailboxSettings.Read
Calendars.Read
Contacts.Read
Tasks.Read.All
Directory.Read.All
Group-Conversation.Read.All
User.Read.AllRead that list once as a security question rather than a checklist. It is tenant-wide read and export access to mail. We create the application for the migration window, record the application client ID and directory tenant ID from the Overview page, generate the client secret, and we put a date in the calendar to remove the whole registration once the last delta import has run. A migration credential that outlives the migration is just an unowned key to every mailbox in the company.
Before the real import, Google's Migration Planner can assess the Exchange Online data using a similar Graph application setup. On a project where nobody can tell you how large the mailboxes are, that assessment is the difference between a weekend cutover and a surprise.
What the import leaves behind
No migration carries everything. The honest work is telling people what they will lose before they lose it. For an Exchange Online import, mail comes across from all folders with folders becoming labels, calendars come with recurring events, Teams meeting links are kept as links rather than converted to Meet, and contacts and Microsoft To Do tasks come too. Shared mailboxes mapped to a group arrive as Collaborative Inboxes. Messages above 150 MB do not import, and some items such as shared folders and certain calendar settings are skipped.
On the files side, OneDrive content keeps its format and permissions are mapped, but previous versions, Personal Vault, Favorites, folder shortcuts and colours, expiration dates, and items owned by external users do not come across. From SharePoint Online, site collections become shared drives and libraries become folders, while lists, web pages and previous versions stay behind.
Then there is the part of a mail migration that has nothing to do with the migration tool. The moment the MX records point at Google, your domain is sending from a new place, and SPF, DKIM and DMARC alignment have to reflect that before the first invoice goes out. We have seen clean imports followed by a week of mail landing in spam, purely because the sending side was never re-authenticated. Check it before the cutover, not after the complaints.
If you are mid-migration right now
Three options, in the order we usually recommend them. Finish on the old tool if the remaining work is small and fits comfortably before the date, since a connector that still works today still works today. Switch to the data import tool for the users you have not moved yet, and keep the old instance only for reference. Or pause, re-scope and restart on the new tool, which is the right call more often than people expect when the project is early.
What we would not do is run a staged cutover across the date boundary and assume the connector will still be there for the final delta. A phased disablement is not a single switch you can watch for, and a tenant that has never set EWSEnabled is in the group that gets disabled.
How Guanacos Tech helps
We run Microsoft 365 to Google Workspace migrations as a done-for-you service, using Google's and Microsoft's own tools rather than anything of our own: the assessment, the Azure application and its removal afterwards, the batches, the MX cutover, and the authentication work on the other side so mail keeps landing. If a plan on your desk still names Google Workspace Migrate for Exchange Online, it needs an hour of attention this month. Our Google Workspace migration services page sets out how the engagement runs, and a 30-minute call is enough to tell you which tool your migration now belongs on and what the date means for your timeline.
Sources
- Google Workspace Migrate help (retirement notices for Exchange Online, SharePoint Online and OneDrive)
- Google Workspace migration product matrix
- Exchange requirements, Google Workspace Migrate (EWS scopes and endpoint)
- Set up an Azure application for Exchange Online, Google Workspace data migration
- Deprecation of Exchange Web Services in Exchange Online, Microsoft Learn
- Retirement of Exchange Web Services in Exchange Online, Microsoft Exchange Team Blog