How long does a Microsoft 365 to Google Workspace migration take?

The copy itself depends on how many mailboxes you have and how much data each one holds, and for Exchange Online the data migration service works through up to 250 users at a time, so larger companies run it in batches. The parts with fixed waiting times are the ones to plan around: the MX record's current TTL governs how fast the cutover takes effect, new MX records can take up to 72 hours to be recognized, the Workspace DKIM key cannot be generated until 24 to 72 hours after Gmail is turned on, and DKIM can take up to 48 hours to start working once published.

Will we lose email while the MX record changes?

Not if the accounts exist first and the overlap is arranged. Create every Workspace account before touching DNS, lower the MX TTL a day ahead, and during the transition use dual delivery, where the old system keeps the MX record and forwards to Google, or split delivery, where Google holds the MX record and routes named recipients on. After the switch, a delta pass collects whatever arrived at the old system during the change.

What happens to our shared mailboxes?

Google has no identical equivalent, so each one gets a decision. A Google Group set up as a Collaborative Inbox suits a queue that a team works together, because members receive at one address and can assign conversations to each other. A delegated account suits an address with a long history that one person mostly answers, since other people open it from inside their own Gmail. Decide this before the migration runs, not after, because the answer changes where the history lands.

Migrate Microsoft 365 to Google Workspace: full checklist

The week after the move is where it shows

Say a 22-person distributor has been on Microsoft 365 since whoever set it up left the company. Deciding to move to Google Workspace takes an afternoon. The move itself usually goes fine, for about a week. Then the calls start: the accounting address nobody can open any more, and the delivery notes from the warehouse software that now land in spam, because nobody counted it as a sender.

None of this is hard work. It goes wrong because the steps get done in the wrong order. Mail gets copied before identity is settled, or the MX record gets switched before anyone lists who else sends mail as the domain. Below is the order we run on a migration for a small or mid-sized company, and what we check at each step.

Step 1: decide what moves, and what stays behind

Before any tool gets opened, we build four lists with the client on one page.

Mailboxes, split three ways: real people, shared addresses several people open, and addresses that only send (alerts, invoices, form notifications).
Calendars and rooms, including who books on behalf of whom.
Files, separated into personal OneDrive content and the SharePoint sites the team actually uses. There is always a site nobody has touched in three years.
Groups and aliases: distribution lists, the address that forwards to two people, the one that forwards to someone who left.

Then the shorter and more useful list: what does not move. Archived mail sitting under a retention policy, a mailbox tied to a line of business application nobody will touch this quarter, chat history. Google publishes a migration product matrix that says which of its tools handles which source and which type of data, and the answer differs for mail, for files and for an older on-premises Exchange server. We read it while planning.

Step 2: identity first, before DNS

Every Workspace account gets created before anything touches the domain's records. Google's own guidance on changing MX records puts this first: the hour mail starts arriving at Google, any address without an account behind it has nowhere to go.

Three details save the most trouble here.

Match the addresses exactly. The data migration service maps users between the two accounts by looking for similar addresses. Every address that does not match becomes a manual mapping, and eventually a mailbox somebody forgot.
Decide what each shared mailbox becomes. Google has two shapes for this and they behave differently. A Google Group set up as a Collaborative Inbox lets a team receive at one address and assign conversations to each other. A delegated account is one mailbox that other people open from inside their own Gmail, and on a work account it can carry a large number of delegates. Support and sales queues usually want the group. An address with years of history that one person mostly answers usually wants delegation.
Sort out administrative access early. Connecting the two tenants needs a super administrator on the Workspace side and a Global Administrator on the Microsoft 365 side. On small teams that second account is often held by whoever set things up years ago, and getting it back takes longer than the migration does.

Step 3: mail, the overlap, and the MX hour

Lower the TTL on the MX record at least a day ahead. Google recommends 3600, one hour, short enough that a mistake at the cutover costs an hour instead of a day. The old TTL governs how fast the change you make now takes effect, so the drop goes first.

Copy the data before the switch, not after. The data migration service copies Exchange Online mail and calendar into Workspace accounts, up to 250 users at a time, so a larger company runs it in batches. People keep working in Microsoft 365 while it runs.

During the overlap, two arrangements are worth telling apart. Dual delivery leaves the MX record pointing at the old system, which delivers to its own inboxes and then forwards everything on to Google. Split delivery points the MX record at Google, and Gmail routes named recipients on to the other system. Google recommends Gmail as the primary server, with the legacy server as primary only during a pilot or migration, and switching to Gmail alone once everyone is ready.

The cutover itself is one record. The Workspace value is a single host, and some registrars expect the priority and the destination in the same field:

example.com.   3600   IN   MX   1 smtp.google.com.

If the domain was set up on Workspace before 2023 it may still carry the older aspmx values, and Google's position is that records which are working do not need changing. Schedule the switch for an evening or a weekend, when a lost hour costs least. Google says new MX records can take up to 72 hours to be recognized and allows up to 48 hours for propagation, so nobody should judge it on the first ten minutes. Once it settles, run a delta pass to collect the mail that reached the old system during the change.

Step 4: authentication while both systems still send

This is the step that gets skipped, and the one that produces the spam complaints two weeks later. While both platforms send as the domain, both have to be authorized, and the moment one stops sending, it comes back out.

SPF is one record, one v=spf1 string, with both includes inside it:

example.com. 3600 IN TXT "v=spf1 include:_spf.google.com include:spf.protection.outlook.com ~all"

Google publishes its sending ranges behind _spf.google.com and Microsoft publishes its own behind spf.protection.outlook.com, because both send from addresses that change. Two includes plus a CRM plus an invoicing platform is where domains cross the limit: SPF evaluation stops at ten DNS lookups and returns permerror, which RFC 7208 requires, and a permerror is not a pass. Count them before the cutover.

DKIM needs work on the Google side, because it is not signing by default. The key is generated in the Admin console under the Gmail settings, published as a TXT record at the DNS provider, and then authentication is turned on. Two timing details matter. After Gmail is switched on for the organization, the key cannot be generated for 24 to 72 hours. Once the record is published, authentication can take up to 48 hours to start working. Put both in the calendar rather than discovering them on cutover morning. Leave the Microsoft DKIM records in place while Microsoft still sends: the two use different selectors and do not collide.

Leave DMARC at p=none while the list of senders is still moving, and read the reports. Tightening the policy in the same week as the cutover means the one system you forgot starts failing at exactly the moment nobody can tell which change caused it.

Two rule sets apply to whatever you end up with. Since February 2024, Google asks every sender, at any volume, for SPF or DKIM and valid forward and reverse DNS, and asks senders of more than 5,000 messages a day to Gmail accounts for SPF and DKIM together, a DMARC record, alignment with the From header, and a spam rate under 0.30% in Postmaster Tools. Microsoft publishes its own requirements for high volume senders to its consumer services, also drawn at 5,000 messages a day from the same From domain, with SPF, DKIM and DMARC at p=none or stronger, and says non compliant mail is routed to Junk first. Most companies this size sit far below those thresholds. The first tier still applies.

Step 5: calendar, delegations and rooms

Calendar data travels with mail in the same migration run. What does not travel is the wiring around it. Delegation rights, the assistant who books for two directors, room resources and their booking rules: these get rebuilt in Workspace, and rebuilding them deliberately beats recreating an arrangement that grew by accident over six years. We schedule that for the day after the mail cutover, with the people who actually use it.

Invitations sent from the old system before the switch can behave oddly afterwards, usually the long-running recurring meetings. For a standing client call, cancelling and reissuing from Workspace beats debugging it.

Step 6: files, with the shape decided first

The data migration service copies OneDrive content into users' My Drive, and SharePoint Online sites into Drive. Google Workspace Migrate covers heavier cases and other sources, the second reason to read the product matrix early.

The decision that matters is not which tool you use, it is whether a folder belongs to a person or to the company. Content that lands in an individual's My Drive leaves with that individual. Content that belongs to the business belongs in a shared drive. Deciding that before the copy costs one meeting. Deciding it afterwards costs a second migration. Permissions and links do not survive a copy unchanged either, and external shares deserve a review pass, because a migration is the one moment when everyone is willing to look.

Step 7: retire Microsoft 365 without breaking your sending

Do not cancel the licenses in the same week. Keep them long enough to prove that nothing still depends on them, then work backwards.

Find every system that sends as the domain: the accounting software, the CRM, the website contact form, the office printer, the alerting on a server somebody still runs.
Move each one onto Workspace or onto its own authenticated path, one at a time, and confirm each with a real message rather than a lookup tool.
Remove the Microsoft include from SPF only when nothing sends through Microsoft any more. The same goes for its DKIM records.
Read the DMARC aggregate reports for at least two weeks after the last sender moves. They are the only place where a forgotten sender announces itself before a customer does.
Export whatever has to be kept for legal or accounting reasons before the old tenant closes, and write down where it went.
Then, and only then, tighten the DMARC policy.

How Guanacos Tech helps

We run this as one project with a written order of operations, because the expensive failures here are sequencing failures rather than technical ones. That means the inventory first, identity next, a cutover scheduled for an hour your business can afford to lose, authentication held open while both platforms still send, and the reports watched afterwards until the domain is clean. If you are weighing the move, our Google Workspace migration services page has the scope we work to. Bring your mailbox count and the list of things that send mail on your behalf to a 30-minute call, and you will leave with the order, the risks and the week it should happen.

Migrating from Microsoft 365 to Google Workspace: the checklist we run, in order