How to Migrate to Google Workspace｜The Sequence for Switching Without Email Downtime

You want to migrate company email and file sharing to Google Workspace—and the biggest concern here is “won’t email go down during the migration?” The short answer: proceed in the right order and you can switch over without stopping email. This article explains the big picture of a Google Workspace migration, the sequence for switching without downtime, and the pitfalls people commonly hit.

The big picture of the migration

A migration proceeds roughly in the following flow. For a small or mid-sized organization (up to about 100 people), including preparation, two weeks to a month is a reasonable guide.

1. Assess the current state and design accounts — Confirm the email environment in use (Microsoft 365, a legacy mail server, etc.), the number of users, shared addresses, and whether you can access the DNS management console for your domain, then design the list of accounts and groups.
2. Contract Google Workspace and verify domain ownership — Add a TXT record to DNS from the admin console to verify domain ownership. At this point the email routing doesn’t change at all.
3. Create accounts and initial setup — Create users, groups (shared addresses like info@ are handled by groups), and organizational units, and set security policies such as two-step verification.
4. Pre-migrate data — Use a migration tool to copy past email, contacts, calendars, and files to the new environment. The old environment keeps running.
5. Cut over the MX record — Point email delivery at Google. This is the only “moment of the switch.”
6. Migrate the delta and verify — Migrate the delta of email that arrived at the old environment just before the switch, and verify sending, receiving, and authentication settings.

The switch order that keeps email running

Most accidents where email “disappears” are caused by changing the delivery destination before the receiving side is ready. Keep the following three points and email won’t be lost even at the moment of the switch.

• Cut over MX last — Change the MX record only after all users’ accounts are created, login is confirmed, and past data is migrated. Reverse the order and email addressed to accounts with no receiver bounces back as errors.
• Shorten the TTL in advance — Lowering the DNS record’s TTL (cache lifetime) to 3600 seconds or less a few days before the MX change shortens the time for the switch to propagate worldwide, and makes rollback faster if there’s a problem.
• Understand the dual period during the switch — Because DNS propagation has a time lag, email still arrives at the old server for a while after the switch. Keep the old environment for at least one to two weeks without canceling, confirm and migrate the delta that arrives, then close it. It’s standard to do the switch on a Friday night through the weekend when incoming volume is low.

Setting up SPF/DKIM/DMARC

What you must set up together with MX is sender domain authentication. Neglect it and you’ll hit the “mail we send lands in the recipient’s spam folder” problem after migration. Ever since Gmail and Yahoo made SPF/DKIM/DMARC a requirement for bulk senders (roughly 5,000+ messages a day), “not configuring it” is effectively no longer an option for companies sending any real volume. Even for small sending volumes, setting up DMARC is recommended as an anti-spoofing measure.

• SPF — Set a TXT record (include:_spf.google.com) that authorizes Google as a sending server for your domain. If you also send from an old server or delivery service, consolidate those into a single record (as a rule, a domain should have one SPF record).
• DKIM — Generate a signing key in the admin console, register the public key in DNS, and enable it. This is a very commonly missed item.
• DMARC — Declare how SPF/DKIM verification results should be handled. It’s safest to first receive reports in monitoring mode (p=none), confirm that all legitimate email passes authentication, and then tighten it in stages.

Migrating data from your existing environment

The tool you use differs by source. Migrating from Microsoft 365 can move email, contacts, and calendars with Google’s data migration service or migration tools. Move OneDrive/SharePoint files to Google Drive (shared drives), deciding the mapping of permissions in advance. Migrating from a legacy mail server (IMAP-capable) can ingest over IMAP via the data migration service. If you run POP and data exists only in a local mail client, per-device migration work is required, so identify the affected people early. In every case, before doing everyone at once, it’s safer to confirm the time required and the pitfalls with a pilot migration of a few people.

The approach to account design and permissions

• Shared addresses via groups — Make info@ and sales@ Google Groups, which don’t consume paid licenses, and send and receive from the assignees’ accounts.
• Split policies by organizational unit — Splitting organizational units by department or job type lets you control app enablement and sharing settings per unit.
• Files go in shared drives — Putting company files in someone’s personal My Drive leaves them orphaned when that person leaves. Prepare shared drives per department and project from the start.
• Security defaults from the beginning — Mandating two-step verification, the default setting for external sharing, and the account-suspension procedure for departures are easier to settle at the same time as the migration.

Pitfalls people commonly hit

• Can’t access the DNS console — Cases where a web-production company manages the domain and can’t change it same-day are very common; it’s the first thing to confirm.
• Forgetting to move aliases and forwarding settings — Alias addresses and auto-forwards that exist only in the old environment slip through if you don’t list them out.
• Sending from MFPs and business systems — If a scanner’s email sending or a sales-management system’s automated email still routes through the old server, it will stop arriving after migration. You need to switch to SMTP relay settings.
• POP settings when using a mail client alongside — If you keep using Outlook and the like after migration, receiving via POP tends to create dual management with smartphones. We recommend unifying on IMAP or browser use.

Summary｜The moment of the switch is just MX—preparation is 90%

The success of a Google Workspace migration is decided not on the day you cut over MX, but in the preparation: account design, pre-migration of data, and sender domain authentication. Keep the principle of “complete the receiver before changing the delivery destination” and you can switch over without stopping email. As a development company that also runs its own operations on Google Workspace, SHANNON provides adoption and migration support from account design to DNS cutover and post-migration security settings. Feel free to reach out even at the early stage of just checking the current state of your domain and DNS.