What Happens to Scheduled Emails When You Switch Clients

Scheduled sends are the one thing in an email-client switch that can quietly go wrong. Your mail stays on the server. Your folders stay on the server. Contacts and calendar stay on the server. What might not stay is the message you scheduled last Tuesday to go out on Friday at 09:00 — because in a handful of clients, that message is sitting in a local Outbox on the machine you are about to stop using, and nobody warns you.

The split is client-side versus server-side. Server-side schedulers (Gmail's Schedule send, Outlook on the web's Schedule send, Superhuman, Spark, Front, Missive) hold the queued message on the provider's own infrastructure and send it at the appointed time regardless of what you do with the client. Client-side schedulers (classic Outlook's Delay Delivery, Apple Mail's Send Later, Thunderbird's Send Later) hold the message in a local Outbox and rely on that specific client being open and online at the send time. Uninstall the client, sign out, or leave the machine asleep and the message goes with it.

This post covers how to tell which yours are, how to audit every pending send before you move, and the specific rescue paths when a client-side scheduler is about to strand a queued message.

What actually moves — and what doesn't#

Everything a mail server owns comes with you when you switch clients. The mail itself, folders, labels, filters, contacts that sync via CardDAV, calendars that sync via CalDAV — all of it re-renders in a new client as soon as you sign in. Scheduled sends are different because the mail server is not always the thing that owns them.

A scheduled email has to live somewhere between the moment you compose it and the moment it goes out. Some clients hand that job to the mail server; others handle it themselves. In both models the "Send at 09:00 Friday" instruction sits inside a queued draft, but who holds that draft — and who fires the timer — decides whether a client switch preserves the send.

The table below is the honest split as of August 2026. Verify against each vendor's own live page before relying on any single row; where a client offers both a client-side mode and a server-side mode, both are listed.

The pattern is the whole story#

The row-by-row detail matters, but the pattern matters more. Anything sent through a webmail or a hosted productivity client survives a client switch on the sending side, because the send lives on someone's server. Anything sent through a native desktop client that shows an Outbox — the classic old email-client model — does not. If you cannot see the pending send in the mailbox's own webmail interface, it is not on the server, and it is not going to survive.

There is one common source of confusion. Some third-party clients show a Scheduled folder in the sidebar even for accounts whose scheduler is entirely local. The folder looks like reassurance that the queue is safe on the server. It is not. It is the client's own view of its own local queue.

Pre-migration checklist: ten minutes that saves an apology email#

Do this before you sign into the new client. Every step is either much easier to do in the old client or impossible to do once it is gone.

• List every scheduled send that is pending in the old client. In Gmail on the web, open the Scheduled label. In Outlook on the web, open Drafts and sort by scheduled time. In classic Outlook, open the Outbox and sort by "Do not deliver before." In Apple Mail, open the Send Later mailbox in the sidebar (it only appears if you have at least one queued). In Thunderbird, open the Outbox under Local Folders. In every other client, look for a Scheduled or Later folder in the sidebar.
• For each pending send, screenshot the recipient, subject and send time. This is your recovery reference if the switch strands one, and it flags scheduled sends you meant to cancel and forgot about.
• Decide, per message, whether to let it fire from the old client or reschedule it in the new one. A message queued in Gmail's server-side Schedule send does not need to move. A message sitting in Apple Mail's Send Later does — or the old Mac has to stay powered on until it sends.
• Cancel any client-side scheduled sends you are about to strand. In classic Outlook, drag the message out of the Outbox back into Drafts. In Apple Mail, right-click the queued message in Send Later and edit or delete it. In Thunderbird, open the Outbox and remove the pending message.
• Recreate cancelled sends inside a server-side scheduler. If the new client's Send Later is server-side, use it. If it isn't, use the underlying provider's own scheduler (Gmail on the web, Outlook on the web) so the send is safe regardless of client state.

Steps: how to switch clients without dropping a scheduled send#

Order matters. Handle scheduled sends before you touch the account in the new client, because a signed-in second client can trigger sync behaviour that hides or reorders the Outbox before you have finished the audit.

1. 1

   Run the audit above in the old client

   Do not skip it. A silent scheduled-send loss is easier to prevent than to explain to a recipient who never got the message.

2. 2

   Sort pending sends into server-side and client-side buckets

   Use the table above as the rule. Server-side sends are safe to leave. Client-side sends must be rescheduled or the send is lost.

3. 3

   Rebuild every client-side scheduled send in a server-side scheduler

   If the new client's Send Later is server-side, use it. Otherwise use the provider's own webmail scheduler as an intermediate step, or leave the message as a draft with a calendar reminder and send it manually.

4. 4

   Confirm the reschedule landed on the server

   Open the account's webmail and look for the message in the Scheduled folder with the right send time. If you see it there, the client is out of the loop.

5. 5

   Sign in to the new client and let the initial sync finish

   The Scheduled system folder is one of the last to populate on some IMAP connectors. A "my scheduled sends disappeared" panic is often just an incomplete sync — wait for the client to say sync is done.

6. 6

   Test a real scheduled send from the new client

   Schedule a message to yourself for two minutes ahead, close the client, and see whether it arrives. That tells you which model the new client actually uses better than any documentation page does.

7. 7

   Keep the old client running until its Outbox is empty

   Do not uninstall, sign out or shut down the machine until every legacy client-side scheduled send has fired. This is the least glamorous step and the one most switch guides skip.

What breaks — and how to save it before you leave#

Row by row. This is a copy-out job list for the day before the switch.

The fork above is the whole story — everything after it depends on which side your pending send is on.

Rollback plan: when a send is missed or fires twice#

The good news about scheduled-send migration is that the rollback plan for the mail itself is trivial. Your mail is still on the server — sign back into the old client and it is all there. The bad news is that a client-side scheduled send that fired from the old machine while you were trying out the new one may already be gone, or worse, may have fired twice if you rebuilt it in the new client and forgot to cancel the old copy.

• Do not delete drafts of scheduled sends in either client during the trial. If you rescheduled from Apple Mail into Gmail's server-side Schedule send, keep both until the old copy is positively cancelled in Apple Mail's Send Later mailbox.
• If a scheduled send fires twice, the recipient sees two identical messages. Apologise once, resend nothing, and move on — no worse than a double-tap.
• If a scheduled send fails to fire, the old client's Outbox usually still contains it after the send time has passed. Reopen the old client, drag the message back into Drafts, and reschedule it inside the new client's server-side scheduler.

Doing it without downtime#

Run both clients on the same account for a week. Do the audit before you sign in to the new one, and keep the old client installed and signed in until every pending scheduled send has fired. Two clients on one mailbox is safe for mail itself — read and unread state, folder changes and label edits propagate through IMAP within a sync cycle.

It is safe for scheduled sends only in one direction. A server-side send scheduled by either client fires once, cleanly. Two client-side schedulers each holding their own copy of "send at 09:00" will each fire, and the recipient sees two identical messages. The safest overlap pattern is server-side scheduling in the new client and no new client-side scheduling from the outgoing one during the overlap week. Use the old client only to receive, read, and confirm-fired for the sends already queued. When its Outbox reads zero, the overlap ends. That is the whole cutover moment for scheduled sends, and it is almost always the last thing to complete in a client switch.

Where AI Emaily fits when scheduled sends matter#

The scheduled-send problem exists because some clients treat "send at 09:00" as a task for the machine to remember and others treat it as a task for the server to remember. AI Emaily's Send later is server-side: the queued message lives on our infrastructure and fires at the scheduled time regardless of whether your desktop app is open, your laptop is asleep, or you have moved to reading mail on your phone. Combined with approve-before-send Copilot mode, that means a message you scheduled last Tuesday behaves the same way whether you check it from macOS, Windows, iOS or the web the day it goes out. We build AI Emaily. The Send later docs page explains the mechanic and pricing lists the 7-day free trial of Pro or Autopilot (card required, $0 if you cancel before day 7).

Honest concession: Gmail's own web interface is where server-side Schedule send is most fully exposed for Gmail accounts specifically — the Scheduled label, per-message edit, and the exact-minute picker are all first-class in Gmail. If your entire scheduling workflow lives inside Gmail and you have no other reason to switch clients, staying on Gmail on the web is the cleanest way to keep those sends on the server. What a third-party client adds on top of that is server-side scheduling that behaves the same way across every provider you connect, not only Gmail.