Email App Sunset: A 30-Day Migration Checklist

An email app shutdown notice almost always gives you a deadline that isn't the one that matters. The date printed at the top is usually when the service stops working entirely — but the date you actually have to hit is buried further down: when exports stop working, when forwarding gets disabled, or when the provider starts bouncing incoming mail. This email app shutdown 30 day migration checklist works backward from that real deadline instead of the headline one.

It's written to be generic, because sunset notices vary and the mechanics don't. Notion Mail gave its users until 22 September 2026 to move off the app entirely — a real, dated example of exactly the clock this checklist is built to beat. Whether your own notice gives you 30 days or 90, the sequence is the same: confirm what moves on its own, export everything else, run two inboxes in parallel, then cut over.

What actually moves and what doesn't#

Every migration takes longer than planned for the same reason: not everything that feels like part of your inbox actually lives inside it. Some of it belongs to your mail provider — Gmail, Outlook, Fastmail — and survives any client swap untouched. Some of it lives only inside the app that's shutting down, and has to be rebuilt by hand in whatever you move to.

• Moves automatically: your email address, MX records, contacts, and calendar — if these live with a mail provider like Gmail or Microsoft 365 rather than the shutting-down app itself
• Moves with an export: message bodies, attachments, sent mail, drafts, and usually folder structure
• Only moves if you rebuild it: filing rules, filters, canned responses, custom signatures, keyboard shortcuts, saved searches
• Doesn't move at all: read and unread state on old mail, snooze schedules, AI-generated labels or summaries, and any third-party app connected through the old client's login

There's a bigger question underneath all four of those: is it your email client shutting down, or your email address? If a mailbox app like Notion Mail closes, you lose the app but keep the underlying Gmail or Outlook account — you just point a different client at it, and your address doesn't change. If it's a hosted email address itself going away — a free ISP account, a startup's own email hosting, an alias tied to a service that's shutting down — you lose the address, and forwarding for six months or more isn't optional.

Pre-migration checklist#

Do this before touching a single setting in the new client. Ten minutes here saves entire days later, because most migration failures are decisions made in week three that should have been made in week one.

• Find the real deadline. Read the shutdown notice past the headline date — look for when exports stop working or forwarding is disabled, and treat that as day zero
• Request a full export now, before you've decided on a replacement. Mail, contacts, and calendar as separate files if the app allows it
• Pick the new client or provider before deleting anything in the old one. Migrating twice because the first choice didn't fit is the most common way a 30-day window becomes a 10-day scramble
• List every service that emails your old address: two-factor codes, calendar invites, billing receipts, newsletters. Each one needs updating or forwarding
• Draft the message telling your team, clients, or frequent senders about the new address, even if you don't send it until week three
• Turn on forwarding on day one if the app supports it, even before the new client is fully set up

The 30-day plan, week by week#

1. 1

   Week 1 — Export everything and pick the destination

   Request your full mail, contacts, and calendar export the day you read the shutdown notice, before you've chosen where you're going. Compare two or three replacement clients against what you actually do all day, not against a feature list. Confirm the new client can import the export format your old app produces — .mbox and .eml are the safest common ground, and a proprietary export format is a hidden blocker some people don't discover until week three.

2. 2

   Week 2 — Set up the new client and start forwarding

   Connect the new client to your existing address if it survives the shutdown, or finish setting up the new address if it doesn't. Turn on mail forwarding from the old app so nothing sent to it during the overlap gets lost. Import the week-one export and spot-check a handful of old threads for attachments and formatting before you rely on it for anything important.

3. 3

   Week 3 — Run both inboxes in parallel and notify contacts

   Check both inboxes daily rather than cutting over all at once — this is the parallel-running week, and it's where most of the manual effort in a migration actually lives. Send the update you drafted in week one to your team and frequent contacts with your new address. Rebuild the handful of filters and rules you actually use; don't try to recreate every setting from the old app, most of them won't matter in six months.

4. 4

   Week 4 — Final cutover and verification

   Confirm nothing has arrived in the old inbox for at least three consecutive days before calling the cutover done. Update any remaining service that still sends to the old address — two-factor codes, billing, and calendar invites are the ones people forget. Archive the export somewhere outside the old app, keep read-only access if the provider offers it, and only then schedule the old account for deletion.

What breaks — and how to fix it#

Some breakage is unavoidable in any migration. This is what to expect and how to handle each one, roughly in the order people notice it.

Rollback plan#

A migration isn't done when mail starts arriving in the new inbox — it's done when you're confident going back isn't necessary. Keep the old account active and read-only, if the app allows it, for at least a week past your finish date rather than deleting it the moment the new client works. If something in the new setup breaks mid-migration — a filter fires wrong, an important thread doesn't import — you want the old inbox intact to check against, not a deleted account and a support ticket.

Doing it without downtime (parallel running)#

Downtime in a migration is rarely the mail server being down — it's a person checking one inbox while important mail sits unread in the other. Two approaches handle this, and most migrations need both. Forwarding moves new mail from the old address to the new one automatically, so you only ever have to check one inbox even while the old address is technically still live. Dual-client access, where the provider allows it, connects the new client directly to the old mailbox alongside the new one, so you can search and reply from both places during the overlap instead of only receiving.

For a team, downtime is a communication problem more than a technical one. The update message you drafted in week one should tell people three things: the new address, the date the old one stops being checked, and what to do if they've already sent something to the old address that needs a reply. Send it once at the start of parallel running and again three days before final cutover — a single announcement gets missed by whoever was on vacation that week.

Cutting the parallel-running weeks down#

Everything above is manual by design — a migration is exactly the moment you want full control over what's happening to your mail, not automation you can't see happening. But the parallel-running weeks are also where most of the actual time in this checklist goes: checking two inboxes, refiling by hand, rebuilding filters one at a time before you trust them.

That's the part AI Emaily is built to shorten, not replace. Point it at the old and new mailbox during the overlap window and its rules engine and Context Brain start filing familiar senders from day one, instead of after you've rebuilt every filter yourself. Copilot mode drafts replies for your approval, so nothing sits unanswered mid-migration, and every action it takes is undoable and logged in an audit trail. We build AI Emaily, and it runs on a 7-day free trial if you want to see whether the overlap weeks get shorter.