How do I run a zero-downtime Google Workspace to Microsoft 365 cutover?

This is the most common question we get, and the good news is that a true zero-downtime cutover is very achievable at 140 users. The key idea is that you migrate the mail *before* you touch DNS, not after. Here is the sequence we recommend:

1. Pre-flight audit (1–2 days before). Inventory every mailbox, its size, and its folder count. You are looking for outliers: the person with a 90 GB mailbox or 400 nested labels will dominate your timeline. Also confirm every target account exists in Microsoft 365 and is licensed — an unlicensed target mailbox is the single most common cause of a failed batch.

2. Pre-seed the bulk (starts 3–5 days before cutover). Run a full migration pass while both systems are live and users are still working normally in Gmail. This copies the overwhelming majority of historical mail. Users notice nothing because they are not using the destination yet. For 140 mailboxes of average size, expect this pass to take 2–4 days depending on how aggressively Google throttles you.

3. Lower your MX TTL (24–48 hours before). Set the TTL on your MX records to 300 seconds. This is the step people forget, and it is the difference between a 5-minute propagation and a 4-hour one. Do it early — the old TTL has to expire before the new short one is respected.

4. Cut the MX record (the cutover moment). Point MX at Microsoft 365. New inbound mail now arrives in the destination. This is the only genuinely time-sensitive step and it takes about 60 seconds of actual work.

5. Run the delta sync (immediately after). This second pass copies only what changed since the pre-seed — typically the last few days of mail. Because the bulk is already transferred, a delta pass usually finishes in under an hour even for large tenants. This is what closes the gap you are worried about.

To answer your specific question directly: mail sent during the propagation window is *not* lost. It is delivered to whichever server the sender's DNS resolution pointed to at that moment. If it lands in Google, the delta sync picks it up and moves it to Microsoft 365. Nothing falls on the floor, which is exactly why the delta pass is non-negotiable.

Labels do survive, but you should understand the model difference because it surprises people.

Gmail labels are many-to-many: one message can carry three labels and there is still only one copy of that message. Outlook folders are one-to-many: a message lives in exactly one folder. So a label hierarchy maps cleanly to a folder hierarchy, but a message with three labels cannot exist in three folders as a single object.

Our migration handles this by placing the message in the folder matching its primary label and preserving the remaining labels as categories on the message. Users keep the ability to filter by them, and you avoid the alternative approach some tools take — writing three physical copies, which inflates the mailbox and looks like duplication to the user.

Nesting depth is preserved as-is. The one thing to warn users about: Gmail's `[Imap]/All Mail` is a virtual view, not a real folder, and it gets excluded. If you migrate it you copy every message a second time. Any competent tool excludes it by default, but it is worth confirming in your pre-flight report.