How to Migrate a Shared Mailbox to a New Email Provider

A shared mailbox like support@ or billing@ is not a normal user mailbox on either Google Workspace or Microsoft 365 — and that difference is why moving one is harder than moving a person's inbox. Several people hold delegated access. Every reply in the history was sent by a different teammate. And the address is one your customers are sending to right now, so an hour of dropped mail is an hour of lost tickets.

This guide covers how to migrate a shared mailbox to a new provider without losing history, breaking delegates, or dropping the mail that arrives during the cutover. It applies to a support@, billing@ or careers@ mailbox moving between Google Workspace, Microsoft 365, Fastmail, Zoho or any IMAP host. It assumes you already know why you're moving — this is the plan for doing it cleanly.

Two things make it distinctive from a personal-mailbox migration. Delegated access does not travel with the mail — you rebuild it on the new provider by hand. And a thread that read as a five-way internal conversation on the old system will keep reading that way only if you preserve folder structure, message timestamps and the original sender addresses through the sync.

What actually moves — and what doesn't#

Shared mailboxes on the two big platforms are architecturally different, and that shapes what a migration can and cannot carry across. On Microsoft 365, a shared mailbox is a real Exchange mailbox with no licence attached, and delegated users see it via "open another user's folder" or as an additional account. On Google Workspace, there are two adjacent things people call a shared mailbox — a Google Group with collaborative inbox turned on, and a delegated Gmail account (a licensed user mailbox that specific people have been granted access to). Under migration they behave differently.

The clearest way to plan is to list every artefact attached to the current mailbox and mark what the migration tool actually carries — versus what someone will recreate by hand on the target.

Pre-migration checklist#

Most shared-mailbox migration failures trace back to something skipped in this list, not a bug in the migration tool. Work through it in order — several items block the ones after them, and the delegate inventory in particular is where teams routinely underestimate how much work the target side is going to be.

• List every delegate on the source mailbox and how they use it — read-only, send-as, send-on-behalf, folder access, filter ownership. This list becomes the re-provisioning checklist on the target.
• Inventory the mailbox size and message count so you know how long the initial sync will take. A support@ mailbox with five years of history is often 20–80 GB.
• Note every alias, group membership and forwarding rule that currently points at the address. Anything that terminates at [email protected] needs a corresponding target on the new provider.
• On the target provider, provision the shared mailbox with the exact primary address it has on the source. On Microsoft 365 this is a shared mailbox (no licence); on Google Workspace it's a delegated user or a collaborative-inbox group, depending on how your team wants to work.
• Confirm you have DNS control for the domain. MX, SPF, DKIM, DMARC and any alias CNAMEs may all need to change.
• Drop the MX and any relevant TXT record TTLs to under an hour, at least 72 hours before cutover, so the eventual re-point propagates fast.
• Announce a cutover window to every delegate. Ask them to avoid moving messages, resolving threads, or sending from delegated addresses during the final sync — a message moved on the source after the last delta pass is a message the target will not learn about.
• Pick the migration path up front: the target vendor's own tool (usually the smoothest for mail, contacts and calendar), plain IMAP (mail only, more portable), or an export/import via PST or MBOX (offline, slowest, most control).

The migration steps#

The exact click path differs between vendors and gets restyled on their own schedule, so the steps below are the sequence rather than the UI. Cross-reference Microsoft Learn and Google Workspace Admin Help for the current screens.

1. 1

   Lower the DNS TTL

   Three days before the sync, drop MX and SPF TXT record TTLs to under an hour. A short TTL is the only lever you have over how fast the eventual alias re-point propagates across the internet.

2. 2

   Provision the target shared mailbox

   Create it with the exact primary address the source has. On Microsoft 365 that's an unlicensed shared mailbox. On Google Workspace it's a licensed user account you'll grant delegated access to, or a Group with collaborative inbox turned on — pick one before you migrate, not after.

3. 3

   Authorize the migration tool on the source

   OAuth is now the only supported path on both Gmail and Exchange Online — Basic Auth has been off for years on Google and is deprecated on Microsoft. Grant the migration tool the read scope for the source mailbox only; nothing wider.

4. 4

   Run the initial full sync

   Point the migration at the source mailbox and let it copy everything. For a 30 GB support@ mailbox this typically takes 4 to 12 hours. Mail keeps arriving at the source address throughout — that's fine, and that's what the delta passes clean up.

5. 5

   Re-add every delegate on the target

   Using the inventory from the pre-migration checklist, grant each teammate the same access on the target — read, send-as, send-on-behalf, folder-scoped permissions if the target supports them. This is manual work and it's what most timelines underestimate.

6. 6

   Recreate rules, auto-replies and signatures

   Filters, vacation responders, canned templates and shared signatures do not migrate. Rebuild them on the target using the new provider's rule engine before cutover, so the first customer email through the new mailbox behaves the same way as the last one on the old.

7. 7

   Run delta syncs until cutover

   Every few hours, run a delta pass that catches new mail landing at the source. Keep going right up until the alias re-point. This is what makes the cutover feel invisible to customers.

8. 8

   Cut the alias or MX record

   For a domain-level move, re-point MX after a delta sync completes with zero items pending. For an alias-level move within the same domain, redirect support@ to the new mailbox address inside the current provider first, then flip when quiet. This is the moment new mail stops arriving at the old mailbox.

9. 9

   Verify with a live send

   Send a real email from a personal address to the shared address, and have a delegate reply from the mailbox. Both directions have to work; a mailbox that receives but can't send-as is a broken mailbox for a support team.

10. 10

    Keep the old provider live for 30 days

    Leave the source mailbox active but with mail routed to the new provider. If a delegate discovers something missing — a filter, an old thread, a rule — the source is still there to check.

What breaks during a shared-mailbox migration#

Most of the failure modes below are cutover-timing or permissions problems, not data-loss problems. They're also the reason a shared-mailbox migration takes more calendar time than a single-user move: fewer of these apply to a personal inbox, and fewer of them get discovered during a solo pilot.

Where a picture helps#

The reason a shared-mailbox cutover looks more complex than a personal-mailbox one is that mail, delegate access and outbound identity are three separate migrations that have to land together. The diagram below is the shape of that hand-off — mail syncs across, delegates are re-granted on the target, and the alias flips last.

Rollback plan#

A shared-mailbox migration is close to fully reversible right up until you re-point the alias or MX record — and for a while after, if you kept the source mailbox active. That's the rollback strategy in one sentence: don't cancel the source until you're certain.

• Before alias cutover: there is nothing to roll back. The source is still authoritative for delivery; the copy on the target is exactly that — a copy.
• Right after cutover: if delivery problems appear, re-point the alias (or MX) back to the old provider. Propagation takes the same TTL-bound time it did going forward, which is why the short TTL matters both ways.
• Set a rollback trigger in advance — for example, more than three missing-message reports in the first four hours — and name who has authority to call it. Waiting for the fifth complaint is how a two-hour incident becomes a two-day one.
• Keep the source mailbox active but with new mail forwarded to the target for at least 30 days. A shared mailbox often carries year-old threads that a customer replies to out of nowhere; the source is the safety net.
• Do not delete rules, delegates or filters on the source during the trailing window — you may need to inspect them to reproduce something that broke on the target.

Doing it without downtime#

"No downtime" for a shared mailbox really means no dropped customer mail during the hours DNS is propagating and delegates are switching over. You can get close to zero by giving the source and target a short overlap window where both can receive, rather than a hard flip.

One approach is dual delivery — forward every message that arrives at the source to the target address during the final sync window, and keep it going for a day after cutover. Both mailboxes see the same mail, and if the target has a problem the source is still catching everything. Deduplicate on the target after the fact using Message-ID.

Another approach is a routing subdomain. Create [email protected] on the target with its own routing, and send a handful of real test messages through it before touching the customer-facing address at all. Once the routing subdomain behaves, the cutover on the real alias is boring.

Cut the alias at your lowest-traffic hour of the week — for a support mailbox that is often Saturday evening in the mailbox's timezone. Keep a low-priority secondary MX pointed at the old provider for 24–48 hours as a safety net. Most resolvers pick up the new record within minutes; a few hold the cached lookup for the length of the old TTL, which is exactly why you shortened it days earlier.

Run one canary delegate through the entire sequence a day ahead of everyone else. Broken send-as, a missing filter or a stuck OAuth grant surfaces on one person's account, not the whole support team's.

Where AI Emaily fits once the mailbox has moved#

This migration is about where the mailbox lives, not what reads it — and the second half of the problem starts the moment the mail lands. Your delegates now have another account on another provider, and if half the team is still finishing their batch, they're working across both at the same time.

AI Emaily connects Gmail, Outlook, Exchange Online and plain IMAP through the same account model this migration already uses, and treats a shared mailbox as a first-class inbox with per-delegate views, assignment and audit trail — so the address doesn't care which platform it landed on. It won't move your mail for you; the steps above do that. But once support@ is live on the new provider, everyone reads it from one place instead of two logins. AI Emaily is a paid product on a 7-day trial (no permanent free tier); pricing is on the pricing page and the shared-inbox mechanics are in the docs. We build AI Emaily, and we're naming it because "what handles the mailbox now" is a real question this plan creates.