Google Workspace migration guide
A good migration separates old-mail import from new-mail cutover.
Small-team migrations work best when you inventory every mailbox, test a pilot, cut over MX records in a planned window, and keep old provider access until validation is complete.
Google Workspace migration is not one task. It includes identity planning, mailbox inventory, old-mail import, DNS cutover, third-party sender checks, user training, and post-cutover monitoring. Small teams often underestimate migration because they only think about opening Gmail.
The key distinction: migrating old email and routing new email are different. Historical mailbox migration copies or imports existing messages. MX cutover changes where new inbound messages are delivered. You can complete one badly even if the other succeeds.
Migration sequence
Quick answer
For a small team, plan migration in this order:
List users, aliases, groups, old provider, mailbox sizes, and business-critical addresses.
Create Workspace users and confirm old provider access before starting migration.
Import one or two representative mailboxes and validate folders, dates, and search.
Change MX records only when users and tests are ready.
Check old mail, new mail, aliases, groups, mobile login, and third-party senders.
Google's data import documentation covers importing from IMAP-based providers and notes administrator requirements for the data import tool. Use the current Google documentation while selecting the migration path: Import email with the data import tool.
Migration inventory
Start with a worksheet. Do not begin migration from memory.
Migration inventory worksheet
| Item | Example | Why it matters |
|---|---|---|
| Old provider | Zoho, cPanel, Microsoft 365, IMAP host | Determines tool and credentials |
| Mailboxes | owner@, accounts@, staff mailboxes | Controls user mapping |
| Aliases | hello@, sales@, old addresses | Prevents lost public mail |
| Groups | support@, billing@ | Needs workflow planning |
| Mailbox size | Small, medium, large | Affects migration time |
| Critical mail | invoices, leads, support | Needs extra validation |
| DNS host | Cloudflare, registrar, hosting | Controls cutover |
Also ask operational questions:
Questions before migration
- Which mailboxes must be migrated?
- Which old addresses can be retired?
- Are there shared passwords?
- Are there forwarders at the old provider?
- Are users using desktop mail clients?
- Is calendar data required?
- Are contacts required?
- Which forms or systems send from the domain?
- Who can approve the cutover window?
Pilot and cutover plan
Run a pilot with a small number of mailboxes. Pick one normal mailbox and one messy mailbox with folders, attachments, older mail, and business-critical messages. Validate before scaling.
Check folder mapping
Old provider folders may map differently in Gmail. Confirm users can find important mail.
Schedule a low-risk window
Small businesses often cut over after office hours, but support or lead-heavy teams may need tighter monitoring.
Prepare MX records in advance
Know the exact DNS panel and old records before the go-live window.
Define who decides
A rollback plan is useless unless the decision owner and technical owner are known.
During cutover:
- Stop making unrelated DNS changes.
- Confirm users can sign in to Google Workspace.
- Confirm migration status for important mailboxes.
- Change MX records to Google Workspace.
- Test external inbound mail.
- Test outbound mail.
- Test aliases and groups.
- Monitor old provider for stragglers during the transition window.
If the source is Microsoft Exchange or Exchange Online, Google also documents migration paths such as Google Workspace Migration for Microsoft Exchange. Review the current source-specific guidance before selecting a tool: Migrate data from Exchange.
Post-cutover validation
The cutover is not done when the first test email arrives.
Post-cutover validation checklist
- Primary users receive external mail.
- Users can send to external domains.
- Aliases deliver to the correct destination.
- Groups accept external mail where expected.
- Old provider no longer receives new primary mail.
- Important historical mail exists in Gmail.
- Search works for recent and older messages.
- Mobile Gmail login works.
- Website form notifications arrive.
- Invoice, CRM, support, and marketing senders still work.
- SPF, DKIM, and DMARC are reviewed after cutover.
Keep the old provider accessible until the business owner signs off. Closing old access too early creates avoidable panic when a user remembers an old folder, export, or forwarded address a week later.
Common migration mistakes
Cutting over before users exist
New mail can bounce if the Google Workspace destination mailbox, alias, or group is missing.
No alias inventory
Old public addresses often generate real leads. Missing aliases can silently lose business mail.
Treating migration as DNS only
MX cutover routes new mail. It does not prove historical mail was imported correctly.
No owner sign-off
Technical completion is not the same as business acceptance. Get the owner to validate important mail.
FAQ
Can we migrate over a weekend?
Often yes, but plan based on team usage, mailbox size, source provider access, and business criticality. Some teams need monitoring during working hours too.
Will changing MX records migrate old emails?
No. MX records route new inbound mail. Old-mail migration requires a separate import or migration process.
Can we keep old mail at the old provider?
You can, but it should be an intentional decision with documented access, retention, and shutdown timing.
Do aliases need migration?
Aliases do not have their own mailbox content unless the old provider stored mail separately. They do need to be recreated or mapped so future mail arrives correctly.
What is the best rollback plan?
Keep the old provider accessible, document old DNS records, know who can change DNS, and define the business owner who decides whether rollback is needed.
