Do You Have to Migrate to Use an AI Email Client?

No, you do not have to migrate. An AI email client connects to your existing Gmail, Microsoft 365 or IMAP account through an authorised connection — the same kind of OAuth link Slack or Zoom uses to read your calendar. Your mailbox stays where it is, your email address does not change, no MX record moves, no DNS work is required, and nothing waits on a folder-by-folder IMAP sync to finish.

Most of the anxiety around "switching" comes from confusing two very different things: replacing the client you read mail in, versus moving the mailbox that stores it. The first takes roughly ninety seconds. The second is a project. This guide is about the first one, and about how to tell instantly which category any product you evaluate actually falls into.

What actually moves — and what doesn't#

Modern AI email clients — AI Emaily, Superhuman, Shortwave, Notion Mail, Fyxer's overlay, and the rest — are clients, not mailbox hosts. They read and write your mail through your provider's official API or over IMAP. The messages themselves never change hands.

Compare that to a real mailbox migration, for example moving from Rackspace to Google Workspace, or from on-premise Exchange to Microsoft 365. That is what Microsoft's documentation calls a mailbox migration: every message, folder, calendar entry and contact is copied from one server to another, and the domain's MX records are repointed so future mail arrives at the new host. It can take hours or days, and it is very much a project.

Connecting an AI client is neither of those things. Nothing is copied, nothing is repointed, nothing is scheduled after hours.

The word to watch for on a vendor's site is "connect." If the docs say "connect your Gmail" or "sign in with Microsoft," you are looking at a client that will read your inbox in place. If they say "import your mail," "transfer your mailbox" or "point your MX records to us," you are looking at a hosted email service, and the migration story becomes real. Both categories exist; the pages that blur them are usually pages that want to sell you a full stack when a client is all you need.

Before you connect: a pre-flight checklist#

None of the checks below are hard. But skip them and you will spend the first hour of the trial diagnosing something that had a two-minute fix.

1. 1

   Confirm you can authorise apps on this account

   Google Workspace and Microsoft 365 workspaces can restrict which third-party apps their users are allowed to grant OAuth access to. If your admin has locked this down by publisher, the connection fails at the consent screen with a message that says exactly that. If you are the admin, this is a one-toggle fix; if you are not, forward the message to whoever is.

2. 2

   Check your two-factor status

   OAuth logins work fine with 2FA on — that is the whole point of the standard. What you do not need is an app password. Those are only for older IMAP-only clients that cannot speak OAuth. If a product asks for an app password on Gmail or Microsoft, it is not using the modern connection path.

3. 3

   Inventory your server-side rules and filters

   Anything you set up in Gmail's Filters page or Outlook's Rules pane keeps running server-side, no matter which client you open. That is usually what you want. Note which ones exist so you know what is still doing work in the background, and so you can tell whether a message got filed by the AI client or by an old rule you forgot about.

4. 4

   Note your aliases and Send-as addresses

   Aliases stored on the provider (Gmail's Send mail as, Microsoft's proxy addresses) are visible to any client that reads that account. Aliases stored inside your existing local client's config are not — those live and die with that client and must be re-added.

5. 5

   Screenshot your current signature

   Some AI clients import signatures on connect, some do not. A screenshot before you connect is thirty seconds of insurance against a Monday morning of trying to remember which font, which line break and which link colour you had.

Connecting your account, step by step#

The connection itself is the shortest part of this guide. Each of the three provider families follows the same pattern: sign in, review the requested permissions, authorise. There is no data-transfer step and no window to wait through.

1. 1

   Gmail (personal or Google Workspace)

   Click Add Gmail in the AI client. You are redirected to Google's own consent screen, which lists the exact permissions the client is asking for — typically reading, sending and modifying mail plus labels. Review them, click Allow, and you are returned to the client. A Google Workspace admin, if you have one, may need to have approved the client's publisher in advance. Google's own help page on connecting other clients covers the underlying mechanics.

2. 2

   Microsoft 365 or Outlook.com

   Same flow, different button. You go through Microsoft's consent screen, which lists the Graph API permissions the client wants (Mail.Read, Mail.Send, and so on). Corporate tenants may show an "admin consent required" notice — that is your IT team's cue, not an error you can fix from your seat. Personal Outlook.com accounts go through in a single click.

3. 3

   IMAP (Fastmail, iCloud, Proton via Bridge, Zoho, self-hosted)

   IMAP predates OAuth, so this path uses a username and password — or an app-specific password if your host requires one for third-party clients. iCloud and Fastmail require app passwords; Yahoo and AOL do too; Proton requires you to run its Bridge. The client stores the credential and connects over TLS on port 993 for IMAP and 465 or 587 for SMTP.

In all three cases, the first sync pulls down recent messages so the client has something to show you — but that is caching for a fast local view, not migration. Your mail still lives on your provider, and every action you take is written back to that provider so any other client you open sees the same inbox state.

What behaves differently once you're connected#

Because you now have two windows onto the same mailbox — the AI client and whatever you used before — a handful of features live in one but not the other. None of these are dealbreakers. They are just the surface area where "we are a client" meets "the provider still owns the account."

The consistent pattern here is that anything the provider stores server-side stays authoritative, and anything the old client stored locally stays with the old client. Signatures are the most-missed item in that split — nine times out of ten the "my new client does not feel right" complaint on day one turns out to be a missing signature block and a Send-as identity that has not been imported yet.

How to reverse the connection if you change your mind#

Because nothing moved, nothing has to move back. Rollback is one action: revoke the client's access from your provider's account settings.

1. 1

   Google account

   Go to myaccount.google.com/permissions, find the AI client in the list of third-party apps with access, and revoke it. The client's cached copy of your mail stops working within minutes, and your old client keeps opening the same inbox with no interruption.

2. 2

   Microsoft account

   Go to myaccount.microsoft.com and select Apps and services, or in a corporate tenant your admin removes it from the enterprise apps list. Same effect: the token is invalidated and the client can no longer read your mail.

3. 3

   IMAP account

   Delete the account from inside the AI client, or change the password on your provider. Either revokes the stored credential. If you use an app-specific password, revoke that specific one so you do not have to reset your main password.

How to try it in parallel, without downtime#

Because both sides are just views of the same mailbox, you can run your old client and the new AI client at the same time on the same account. Reading a message in one marks it read in the other. Archiving in one archives it in the other. Sending from one shows up in the sent folder of the other. This is by design, and it is the sanest way to trial an AI client — keep your existing workflow live for anything time-sensitive, and use the new one for the daily-driver work that will actually decide whether you keep it.

There is one exception worth naming. Different clients have different backend architectures for delivering push notifications on mobile, so during a parallel week you often get the same message pinging twice. Turn notifications off in one of the two clients until you have decided which is your daily driver — it is the single most annoying thing about running two email clients on one account, and it is fixed with one toggle.

Where AI Emaily fits#

AI Emaily connects the way this guide describes: OAuth for Gmail and Microsoft 365, standard IMAP for everything else. Your mailbox stays where it is, your email address does not change, and revoking access from your Google or Microsoft account is a one-click rollback with nothing left behind. Message bodies live in our own object storage, referenced back to your account, and are never used to train a model. We build AI Emaily, and we ship it on the web, on Windows, on iOS and iPadOS as a native app, and on macOS as a downloadable Electron app (Apple Silicon only, not distributed through the Mac App Store). If what you actually need is a native Swift Mac client with a fully local archive, Mimestream is a better fit on that specific dimension than we are — same connection story, different app architecture.