Reference

Google Workspace Migration Checklist

Nine phases and 49 items, in the order they actually need doing. Written to be worked through rather than read — including by people who are not going to hire anybody.

checklist

Use it as a list

Work down it. Items in a phase can run in parallel; the phases cannot.

fact_check

Phase one is the one to take seriously

Almost every migration that goes badly went badly because discovery was rushed.

history

It does not end at cutover

The last two phases are where most of the value is either realised or lost.

Discovery

Before anyone quotes anything

Count mailboxes and their actual sizes
Not how many staff you have — how many mailboxes exist, including ones belonging to people who left. The two numbers are rarely the same.
Measure the file footprint
File server, OneDrive, SharePoint, Drive, or a shared folder on someone's machine. This decides the edition more often than headcount does.
Hunt for PST and local archive files
Ask your staff directly; no admin report will show them. In an organisation that has used Outlook for years these are frequently the largest single volume of mail.
List every shared address
info@, sales@, accounts@, orders@ and the ones nobody has mentioned yet. How each is currently used decides whether it becomes a group or a licensed account, which changes the price.
Establish who controls the DNS
Not who set it up — who can log in today. The single most common cause of a delayed cutover is nobody having the registrar password.
Settle the retention requirement
How long mail must be kept and whether anyone may need to search it later. This decides the edition, so it belongs here rather than after licences are bought.
Inventory every system that sends as your domain
Accounting software, CRM, booking engine, marketing platform, helpdesk. Each will need authorising, and there is always one nobody remembers.

Decisions

Before anything is built

Choose the address format and commit to it
firstname@, firstname.lastname@ or initials. Changing it later means every business card, signature and supplier record in circulation is wrong.
Decide the organisational unit structure
By site, department or role — whichever reflects how policy actually needs to differ. It sets the ceiling on how granular your control can ever be.
Set the external sharing posture
Open, restricted to allowlisted domains, or off. All three are legitimate; never having chosen is not.
Name who will hold super-admin
More than one person, fewer than four, none of them using it for daily work.
Agree the device policy in writing
Whether personal phones may hold company mail, and what you may do to one that is lost. Settle it before configuring, not during an incident.
Write the leaver process
Suspend, delegate, transfer, remove, then delete. Decided in advance it is a five-minute procedure; decided on the day it is an argument.
Pick the cutover window
Every business has a quiet period. Choose it now so everything else can be scheduled backwards from it.

Build

Before any data moves

Verify the domain and add any secondary domains
Including alternative spellings and anything kept from a rebrand.
Create accounts to the agreed convention
In the right organisational unit from the start, so policy applies automatically rather than being retrofitted.
Build groups and role addresses
Mailing groups people write to, security groups that grant access. Keep the two purposes separate and name them consistently.
Design and create Shared Drives
Owned by the organisation, structured around how work is actually grouped, with access by group rather than by individual.
Apply the security baseline
Two-step verification enforcement configured with an enrolment window, admin roles separated, third-party app access restricted.
Publish SPF, DKIM and DMARC
DKIM in particular has to be generated in the Admin console and published deliberately — it is not on by default. Start DMARC at monitoring.
Do not switch MX yet
Everything above happens while your existing mail continues to run untouched.

Pilot

One to two weeks before the move

Choose five to ten people across different roles
Include at least one person who will complain loudly and specifically if something is wrong. They are the most valuable participant.
Move them properly, not experimentally
Real accounts, real data, real work for a full week. A pilot nobody depends on discovers nothing.
Collect what broke, in writing
Signatures, a missing shared folder, a filter someone relied on. These are the same items that will affect everyone else.
Fix the structure, not just the instance
If one person could not reach a Shared Drive, check whether the access model is wrong rather than granting them access and moving on.

Bulk sync

While the old system stays live

Copy the main body of data across
Mail, contacts, calendars and files. Nobody is disrupted and nothing depends on this finishing at a particular hour.
Migrate files into Shared Drives, not personal Drives
Landing organisational content in individual accounts quietly recreates the problem you are leaving.
Rebuild what cannot be copied
Distribution lists, aliases, shared mailboxes and any Microsoft 365 Groups. These are redesigned rather than migrated.
Spot-check calendars against the source
Recurring events and room bookings are the usual casualties, and a silently broken recurring meeting is not noticed until it fails to appear.

The week before

Five to seven days out

Lower the DNS time-to-live on the MX record
Often to a few minutes. This is what makes the switch propagate in minutes rather than a day, and it has to be done days ahead to take effect.
Tell everyone what is changing and when
Short, specific, role-relevant. A flawless technical migration is still judged a failure by people who were not warned.
Issue two-step verification backup codes
Lost phones during a migration week are a certainty, not a risk.
Confirm you still have DNS access
Log in and check. Discovering the password has changed on cutover night is a preventable kind of bad evening.
Run a final inventory pass
Any mailbox, shared address or sending system found now is cheaper than one found after decommissioning.

Cutover

The chosen quiet window

Run a final delta sync first
Everything that arrived since the bulk sync, so the two systems are level when the switch happens.
Change the MX records
Seconds to do, minutes to hours to propagate depending on how well the TTL reduction took.
Keep forwarding or dual delivery running
Some senders will resolve the old MX for a while. This is the single step that makes a cutover safe rather than a gamble.
Verify mail flow in both directions
Send and receive externally, not just internally. Internal mail working proves very little.
Run one more delta sync afterwards
Anything that landed on the old system during propagation gets pulled across.
Do not cancel the old service today
Keep it read-only. One more billing cycle removes an entire category of panic.

The week after

Hypercare

Be available, visibly
The questions arrive now — signatures, a missing share, a rule someone relied on. Short, intensive support here decides whether people think the project went well.
Apply signatures centrally
A natural moment to standardise a set that has drifted across the company.
Run short role-specific sessions
What changed for that person, where their files are, how Shared Drives differ from emailing attachments. Not a product tour.
Watch the DMARC reports
This is when the senders nobody remembered start appearing. Add them before tightening the policy.

Thirty to ninety days

Closing it out properly

Verify, then decommission
Spot-check mailboxes, shared folders and calendars against the source before cancelling anything. Decommissioning is the one step that cannot be undone.
Tighten DMARC to quarantine, then reject
Only once the reports are clean. A domain left at monitoring has reporting and no protection.
Right-size the licence count
The true number of active users is now visible, and it is usually lower than the number you migrated.
Confirm Shared Drives are actually being used
If people are still emailing attachments, you have paid for storage nobody is using and the training half did not land.
Hand over the documentation
Admin roles, group structure, DNS record map, the leaver runbook, and why each decision was made. Without it you have swapped one undocumented system for another.

If you read nothing else

The five items businesses discover too late

Every one of these appears somewhere in the list above. They are repeated here because in practice they are the ones that get skipped, and each of them is far cheaper to handle in week one than in week six.

1
PST files on individual machines
No admin console will reveal them, and they are often the largest volume of mail in the business. Finding them is a question you ask staff.
2
Who actually controls the DNS
The most common cause of a delayed cutover, and the easiest to check weeks in advance.
3
How many shared mailboxes exist
Free on Microsoft, not free on Google. This single count is the most frequent reason a migration quote moves after discovery.
4
The overlap billing period
You will pay for both platforms for a few weeks. It is a real line item and almost always missing from a comparison.
5
Every other system that sends as your domain
The invoicing tool, the booking engine, the courier integration. They fail silently once DMARC is enforced, and the failure is invisible to you.

Migration planning — common questions

help

How long does a Google Workspace migration take end to end?

expand_more

For a small team on a single source system, one to two weeks, and the limiting factor is usually finding a cutover window rather than moving data. Between twenty and a hundred users it is more often two to four weeks. Larger organisations with several source systems run in phases over four to eight weeks. What genuinely extends a timeline is not data volume but decisions: how open sharing should be, who holds admin, what happens to a leaver. Organisations that settle those in one sitting are live far sooner than ones that take a month over them.

help

Which phase do people skip, and what does it cost?

expand_more

Discovery and hypercare, in that order. Skipping discovery means the quote moves, because shared mailboxes and PST archives are found later rather than counted first. Skipping hypercare means the technical migration succeeds and the project is still judged a failure, because the week when everyone's questions arrive is the week nobody was available. Both are unglamorous and both are where the outcome is decided.

help

Can we do this ourselves?

expand_more

A small team with one source system, no compliance requirement and someone technically confident — genuinely yes, and this checklist is written to be usable that way. It becomes worth paying for when you have shared mailboxes to redesign, a SharePoint estate, a retention obligation, or simply nobody who can take a week out. We would rather you use the list and not call us than call us and not need to.

help

When should we tell staff?

expand_more

During the week before, not on the day, and not months ahead. Too early and the message is forgotten; on the day and the migration gets blamed for everything anyone dislikes about the new system. Keep it short and role-specific — what changes for that person, when, and who to ask. A flawless technical cutover is still experienced as a failure by people who arrive on Monday to an interface nobody warned them about.

help

What is the one thing you would not compromise on?

expand_more

Keeping the old system read-only for a period after cutover instead of cancelling it on the day. It costs one more billing cycle and it eliminates the entire category of problem where something was not copied and nobody notices for three weeks. Every migration that has genuinely gone wrong in our experience had decommissioning happen too early.

support_agent

Stuck on one of these?

Most of this list is work you can do yourself, and we would rather you used it than hired us for something you did not need. If a particular item is the one blocking you — usually the shared mailboxes or the PST hunt — a short conversation costs nothing. We are a Google Workspace partner and reseller based in Kerala, working with businesses across India.

Talk to our teamarrow_forward call+91 99467 89916