Will we lose mail during the MX change?

Not if you lower the MX TTL to 300 seconds two days ahead and leave the old mailboxes running for a week. During the window some senders still reach the old host because their resolver cached the previous record, so both systems keep receiving, and a second delta run of the data migration service brings anything left behind into Workspace.

Can the data migration service move a personal Hotmail or Outlook.com mailbox?

No. The Exchange Online source is for a Microsoft 365 tenant, and personal accounts are consumer accounts. Since Microsoft started retiring basic authentication for personal Outlook, Hotmail and Live accounts on 16 September 2024, IMAP tools that sign in with a username and password no longer connect either, so those mailboxes are copied with a desktop client that supports modern authentication.

What does not survive the migration?

Outlook rules, signatures, category definitions and assignments, contact folder structure, rich text in calendar event descriptions, calendar colors and time zone settings, and messages larger than 25 MB including attachments. Shared calendars import only for their owner, and recurring tasks arrive as one-time tasks.

Migrate Hotmail or Microsoft 365 to Google Workspace

The question always arrives in the same shape. "If we change the MX record and something goes wrong, do we lose the mail?" It is a fair question, and the honest answer is that mail does get lost in migrations, for two reasons: somebody moves DNS before the mailboxes are copied, or nobody wrote down what the old system was sending on the company's behalf. Both are avoidable with an hour of preparation.

This is the order we use when we move a small company from Hotmail, Outlook.com or Microsoft 365 to Google Workspace. It works the same for five mailboxes and for eighty. Most of it is done with tools that come with Workspace, and where those tools stop, we say so.

What moves, and what you will rebuild by hand

Google's data migration service, in the Admin console, copies email from another Google Workspace account, a Microsoft Exchange Online account, an IMAP account, or a single personal Gmail account. From Exchange Online it carries folders and subfolders and the importance flag on each message. From an IMAP server it carries folders and subfolders. From a Google account it carries labels, sublabels and stars.

The list of what does not come across is the useful one, because every item on it is a small surprise on the Monday after the cutover:

Messages over 25 MB, counting attachments, are skipped. So are attachment types Gmail refuses, such as executables.
Rules. Neither server-side nor client-side Outlook rules migrate. You re-create them as Gmail filters.
Signatures. Re-created per user, which is a good moment to standardize them.
Categories. Category definitions and the assignments on individual messages do not import.
Contact folders. The contacts themselves migrate, all of them, into one pile. The folder structure does not. Labels are the replacement.
Calendar details. Rich text in event descriptions, calendar colors and time zone settings do not import. A shared calendar imports only for the person who owns it, not for everyone it was shared with.
Task specifics. A recurring task arrives as a single one-time task, a due time becomes an all-day task, and task attachments are not supported.

None of that is a reason to avoid the migration. It is a reason to hand each user a short list before the switch, so that the first day on Gmail is about getting work done rather than hunting for a signature block.

Before you touch DNS: the inventory

Open a spreadsheet and fill four columns before anything else.

Mailboxes and addresses. Every user mailbox, every alias, every distribution list, every shared mailbox, every forwarder. In Workspace these become users, aliases and groups, and they all have to exist before the MX record changes. Mail addressed to something Google has never heard of is rejected at the door.
Everything that sends as your domain. The invoicing system, the CRM, the online store, the website contact form, the office scanner that emails PDFs, the monitoring alerts. This column is the one people forget, and it is the one that causes the "our invoices go to spam now" call two weeks later.
Current DNS. Capture what is published today, before you edit anything.
Who controls the registrar. Find the person with the login now, not at 8 a.m. on cutover day.

dig +short MX example.com
dig +short TXT example.com
dig +short TXT _dmarc.example.com
dig +short CNAME autodiscover.example.com

Keep that output. It is your rollback plan, and it is the raw material for the SPF record you will publish later. If column two has more than three or four systems in it, read how to stay under the SPF 10-lookup limit before you write a single record, because a migration is exactly when domains blow past it.

Running the data migration service

In the Admin console the path is Data migration, then choose the source. For a Microsoft 365 tenant, pick the Exchange Online source and connect it with OAuth, which is now the standard method and removes the old certificate step. One migration run handles up to 1,000 Google Workspace users, up to 1,000 Exchange Online users, up to 100 IMAP accounts, or a single personal Google account.

Two habits matter more than the settings:

Start the copy days before the cutover. The old system keeps receiving mail the whole time. Copying a mailbox does not move it, so there is no risk in starting early, and it means the slow part is finished before anyone is waiting.

Run a second pass after the cutover. Everything that landed in the old mailbox between the first copy and the DNS change is still sitting there. A delta run picks it up. Then read the migration report properly: "completed" on the summary screen is not the same as a per-folder count that matches the source. Compare the counts on the two or three biggest mailboxes before you tell anyone the old system can be switched off.

Personal Hotmail, Outlook.com and Live accounts are a different job

A personal @hotmail.com or @outlook.com mailbox is a consumer Microsoft account, not an Exchange Online tenant, so the Exchange path in the Admin console does not apply to it. IMAP is the only route, and Microsoft narrowed it: on 16 September 2024 it began retiring basic authentication for personal Outlook, Hotmail and Live accounts, so any migration tool that signs in to IMAP with a plain username and password no longer connects.

What still works is a desktop mail client that signs in with modern authentication, holding both accounts at once, with the folders copied across inside the client. It is slower and it is per-mailbox, so budget for it honestly rather than discovering it on the day. Then set forwarding on the personal account for a month or two while contacts learn the new address.

If a business domain is currently pointed at a personal account, treat the cleanup as part of the project. It is the single change that does the most for how the company's mail is judged by receiving servers.

The MX cutover, in order

48 hours before. Lower the TTL on the MX records to 300 seconds. Left at an hour or more, resolvers that cached the old value keep delivering to the old host long after you have moved on.
The day before. Confirm every user, alias and group exists in Workspace and that each user has signed in once.
Coexistence, if you need it. If the move happens in waves, configure dual delivery or split delivery in the Admin console routing settings first, so mail for people who have not moved yet still reaches them.
The cutover. Delete the old MX records, then publish Google's. New domains can use the single-record form. Older domains may still carry the five-record set, which is fine, but never keep the old provider's records alongside Google's.

; Google Workspace, single MX record form
example.com.    300    IN    MX    1 smtp.google.com.

Within the hour. Send a test message in each direction, from an outside address in and from a Workspace mailbox out.
For the next week. Leave the old mailboxes running and check them daily. Anything that arrives there came from a resolver with a stale cache, and it needs collecting.

Before you tell the team it is done, check what the domain is actually answering now. A quick outside look at the MX, SPF, DKIM and DMARC records catches the two classic cutover mistakes, a leftover record from the old provider and an SPF that never got updated.

Authenticate the same day, not next month

A migration is a reputation event. Your domain starts sending from new infrastructure, and receiving servers notice. Publish all three records on cutover day.

SPF. One record for the domain, listing Google plus every system from column two of your inventory, and nothing that no longer sends.

example.com.        3600 IN TXT "v=spf1 include:_spf.google.com ~all"
_dmarc.example.com. 3600 IN TXT "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

DKIM. In the Admin console, under Apps, Google Workspace, Gmail, open Authenticate email, generate a new record, and choose the 2048-bit key if your DNS host accepts a TXT value that long. The default selector prefix is google. Publish the TXT record at your DNS host, then come back and start authentication. The console can keep showing the "update the DNS records" notice for up to 48 hours after the record is live, so do not regenerate the key in a panic.

DMARC. Start at p=none with a reporting address, read two weeks of reports, then tighten. Moving straight to enforcement right after a migration is how invoices and CRM mail disappear. The sequence is in our guide on moving DMARC from p=none to p=reject.

Leave the old provider's SPF include in place until you have confirmed nothing sends through it any more, and clean up leftover autodiscover records only once the last Outlook client is gone.

How long it takes

The mailbox copy is the long part, and it runs unattended. The parts that need a person are the inventory, the cutover hour and the authentication, and those are measured in hours, not weeks. For a company of five to twenty people the whole project usually fits inside a week, with the DNS change itself taking minutes. Workspace licences are billed by Google per user; the migration work is separate, and how we scope and price it is written down.

How Guanacos Tech helps

We are an independent consultancy with Google-certified engineers, working in English and Spanish across North America and Latin America. We run the inventory, do the migration, sit on the cutover, and publish SPF, DKIM and DMARC the same day so the domain lands authenticated rather than fixed later. If you want a second opinion before you touch DNS, start with the free email troubleshooter or read what a Workspace engagement covers, and book a call at calendar.app.google.

Migrating from Hotmail, Outlook or Microsoft 365 to Google Workspace without losing a single message