Migrating a Team to an AI Email Client Without Moving Mailboxes

Most guides that turn up for "how to migrate a team to a new email client" quietly assume you are moving mail providers — the old Rackspace-to-Google Workspace, Google-to-Microsoft-365, IMAP-to-anything kind of project. That is a real thing to plan, and it is a hard one: you are changing MX records, moving message stores, breaking the read/unread state, and telling every external sender to update the address book they never edit.

This is not that. A team adopting an AI email client — AI Emaily, Superhuman Mail, Fyxer, Shortwave, any of them — is doing something structurally simpler. The mail stays on Google or Microsoft. The addresses stay. The DNS stays. Only the client and the agent layer change. The rollout looks like a software deployment, not a data migration, and the plan you need is different.

This guide is written for the person doing that rollout for a team of five to fifty. It covers what actually moves (very little), the pre-rollout checklist, the phased plan, what breaks in practice, the rollback, and the comms that keep the switch from feeling like a switch. We build AI Emaily; the mechanics below are true of any native OAuth AI client, and we say where they aren't.

What actually moves — and what doesn't#

The short version, because it is what your team will actually ask on Monday morning: nothing about the mail moves. Their email address is unchanged. Their existing inbox and archive stay on Gmail or Microsoft 365. Their DNS records — MX, SPF, DKIM, DMARC — are untouched. Their sent history, contacts, calendars, filters on the server side, aliases and forwarding rules all keep working, because the mail is still hosted where it always was.

What changes is the app they open to read and write email, and the fact that an AI agent now runs alongside it. That is a much smaller change than a provider migration, but it is not zero — a client swap has its own set of things that break, and pretending otherwise is how a rollout loses trust in week two.

The pre-rollout checklist#

Do this before the first user connects. It is short — a client rollout does not need a project plan — but every item below has ended someone's Wednesday.

• Confirm you have admin consent authority. Google Workspace and Microsoft 365 both allow admins to pre-approve third-party OAuth apps at the tenant level, so users are not each prompted individually and IT does not get pinged fifty times.
• Decide the scope shape. AI email clients ask for read/modify scopes on mail (Gmail API's `gmail.modify`, Microsoft Graph's `Mail.ReadWrite` and `Mail.Send`). Read the vendor's scope list, match it against your least-privilege policy, and get the security sign-off in writing before the pilot connects.
• Pick the pilot cohort. Three to five people who send a lot of email, ideally from different roles (one exec, one sales, one support). The pilot's job is to break the client on your real mail, not to represent the whole company.
• Freeze the old client's local artifacts. If anyone uses a desktop client with local rules, snippets or PSTs, take a manual export before they connect the new one — those things live on the machine, not on the server, and switching apps leaves them behind.
• Draft the internal comms. One announcement, one FAQ, one channel for questions. The single biggest cause of a botched rollout is that half the team hears about it from the other half.
• Confirm the trial and licence math. AI Emaily is a 7-day free trial on Pro or Autopilot (card required, $0 if cancelled before day seven), then paid plans; other vendors package differently. Verify the current shape on each vendor's pricing page and match your pilot window to whatever trial window is actually offered.

The rollout in phases#

The point of phasing a client rollout is not that the technology is risky — it is that the change is behavioural. People are learning a new inbox metaphor, a new autonomy model (approve-before-send, autopilot, an audit trail), and a new way of drafting. You want the first cohort to hit the sharp edges before the whole company does.

1. 1

   Day 0 — Admin consent and scope approval

   IT enables the vendor's app in the Google Workspace admin console (Security → API controls → Domain-wide delegation and OAuth apps) or the Microsoft Entra admin centre (Enterprise applications → Consent and permissions). Grant tenant-wide consent for the exact scopes the vendor documents. Nothing user-facing has happened yet.

2. 2

   Days 1–7 — Pilot cohort connects

   Three to five users install the client, authorise their Gmail or Outlook account, and use it as their primary inbox for a working week. They keep the old client installed as a fallback. Collect notes in the one channel from step five of the checklist. This is the week where architectural surprises show up.

3. 3

   Day 8 — Pilot retro

   One 30-minute call. What worked, what broke, which agent action people did or did not trust, which shortcut people missed. Decide whether to proceed, delay a week for a fix, or roll back. The rollback is trivial (see below), so "delay a week" is a real option and not a face-saving one.

4. 4

   Days 9–15 — Wave one (roughly a third of the team)

   Extend to the next cohort using the pilot's notes as the FAQ. The wave's job is to prove that the pilot's experience generalises — not to catch new problems. If the wave surfaces something unexpected, hold before wave two.

5. 5

   Days 16–22 — Wave two (the rest of the team)

   Everyone else connects. At this point the pattern is well-worn and the shared FAQ answers most questions before they are asked.

6. 6

   Days 23–30 — Uninstall the old client

   This is the step teams skip and regret. Once the new client has been the primary for a full week for the last cohort, remove the old one from managed devices. Keeping both installed indefinitely is how you end up with two apps and two habits per person forever.

What actually breaks when you swap clients#

None of these are dealbreakers, but knowing which ones apply saves the "why did this change?" ticket. Verify each against your specific vendor and both providers before the pilot starts.

Below is where the rollout diagram lives in most team plans. The point of the picture is that the old client and the new one talk to the same server-side mailbox — that is why nothing has to move.

The rollback plan#

The rollback for a client swap is trivial precisely because nothing was moved. There is no reverse migration to run, no DNS to revert, no message store to copy back. This is the single biggest structural advantage of "connect the mailbox" over "move the mailbox", and it is why phasing the rollout so cautiously is affordable.

Concretely, an individual user can roll back in under five minutes: revoke the AI client's OAuth grant from Google (myaccount.google.com → Security → Third-party apps) or Microsoft (myaccount.microsoft.com → Privacy → Apps and services), remove the app from their machine, and reopen the old client. Their mail is unchanged, because the old client speaks to the same mailbox.

A tenant-wide rollback is barely harder. IT revokes the app's admin consent in the Google Workspace admin console or Microsoft Entra portal, which invalidates every user token in one action. The AI client stops being able to act on any mail in the tenant. The mailboxes themselves are untouched. Communicate the reason once, in the one channel, so nobody thinks their mail has disappeared.

The one thing worth preserving before you revoke is the audit trail. A good AI client keeps a per-user log of every action the agent took (drafts prepared, replies sent, labels applied, follow-ups scheduled). Export that log before the last user disconnects, so a future "did the agent send that thing on July 12?" question is answerable.

Doing it without downtime — the comms plan#

A client swap has no technical downtime because the mailbox is always reachable through the provider's UI. The downtime that actually costs you is behavioural: someone missing an email in the transition week because they were checking the wrong app. The comms plan exists to keep that number at zero.

• One announcement, one week before the pilot, from the person who signed off on the choice. It says which client, why, when each cohort connects, and where to ask questions.
• One FAQ, updated live, answering the six things you can predict people will ask (address unchanged? old client still works? what does the AI see? what is the scope? how do I roll back? what if I hate it?).
• One channel for questions. Not email. A single Slack/Teams channel where the pilot cohort answers each other and the rollout owner watches. This is the highest-leverage thing on the list.
• One shared handoff message. During the pilot week, cohort users tell external senders they can reach them the same way as always — because they can. Nothing about their address has changed and it is worth saying so, once.
• One retro after each wave, kept to 30 minutes. Publish the notes to the channel; do not let learnings live inside one manager's head.
• Zero "forwarding to a new address". If anyone is tempted to auto-forward to a new address as part of this rollout, stop the rollout — that is a provider migration, and it needs a different plan.

A note on which client we're describing#

This guide is provider-agnostic, but the sharpest version of the rollout above assumes a native OAuth AI client — one that authenticates directly against Google and Microsoft, reads mail through the Gmail API and Microsoft Graph, and layers an agent (with approve-before-send, autonomy modes and an audit trail) on top. That is the shape AI Emaily takes, and it is why the rollback is a five-minute OAuth revoke rather than a data-migration project. We build AI Emaily.

If you want the product side of that — how the agent behaves, what the autonomy modes actually do, what our security model looks like — the AI email assistant page walks through it, and the team-tier page covers the shared-inbox and delegation shape. Packaging is a 7-day free trial on Pro or Autopilot (card required, $0 if cancelled before day seven); check the current tiers at aiemaily.com/pricing before you plan the pilot. The homepage at aiemaily.com is the shortest way to see whether the client fits your team before you spend a working week on a pilot.