Start with people, not mailboxes
A charity's Google Workspace usually holds more than staff accounts. There are volunteer accounts created for a single event, role addresses such as a general enquiries inbox shared by whoever is on duty, trustees with accounts they use a few times a year, and accounts belonging to people who left long ago but whose Drive still owns important files. List every account and decide what each one becomes in Microsoft 365.
Typical outcomes: staff get a licensed user account; regular volunteers get a licensed account on a plan that suits their role; role addresses become shared mailboxes; occasional volunteers and trustees may be better served by guest access to a specific site or team; leavers' accounts are not migrated as users at all, but their files are given a new owner first. Check Microsoft's current licensing terms for shared mailboxes and for any nonprofit offers you rely on, because these are set by Microsoft and do change.
Do this with the people who manage volunteers, not only with IT. They know which accounts are in use, which are shared between several volunteers, and who needs access to what. Shared logins are worth ending at migration: multifactor authentication assumes one person per account, and so does any audit trail you might need later.
Look at the size of each mailbox and drive at this stage too. A handful of very large accounts often sets the length of the bulk passes, and knowing which they are lets you start them first.
Get the tenant ready before anything moves
Set up the Microsoft 365 tenant, add and verify your domain, and create the user accounts, shared mailboxes and groups from your list. Do not change MX records yet. Mail keeps flowing to Google until cutover; the Microsoft side simply exists and is ready to receive migrated content.
Decide on authentication early. Multifactor registration is the step that generates most first-morning calls, particularly from volunteers without a work phone. Settle which methods you will allow, write a one-page guide with screenshots, and let a pilot group register ahead of cutover so you find the problems on a quiet day.
Lower the time to live on your MX and related DNS records a few days before cutover, so the change takes effect quickly when you make it. Prepare the SPF, DKIM and DMARC changes and the autodiscover record in advance. On the day you want to be pasting values you have already checked, not working them out.
Decide how accounts will be created and maintained. For a small charity a spreadsheet and a script are fine; for a larger one, think about where account information will live afterwards, because the joiners and leavers process you set up now is the one you will be running for years.
Choosing the tools
Microsoft provides a native Google Workspace migration in the Exchange admin centre for Gmail, calendars and contacts, using a Google service account and migration batches. For Google Drive, Microsoft's Migration Manager in the SharePoint admin centre is an option. Both are reasonable for straightforward estates. A third-party tool such as AvePoint Fly is often easier to run when you want mail and files handled from one console with consistent mapping and reporting.
Fly connects to both Google Workspace and Microsoft 365, lets you map source accounts and drives to destination mailboxes, OneDrive accounts and SharePoint sites, and runs a full pass followed by incremental passes that pick up only what has changed. That pattern, a bulk copy early and small deltas later, is the whole reason a migration does not need to cost a week. Check which object types and options your version of Fly supports, and run its pre-scan to find oversized files, unsupported items and permission problems before the real passes start.
Whichever tools you use, the access you grant them is significant: domain-wide delegation on the Google side and admin consent on the Microsoft side. Record who approved it, keep it to the project's duration, and remove it when the project ends.
Map Drive to OneDrive and SharePoint deliberately
My Drive content goes to the owner's OneDrive. Shared drives go to SharePoint, usually one site per shared drive, though migration is a good moment to merge small shared drives and split sprawling ones. Agree the mapping with the teams that use each shared drive, and give every new site a named owner before content arrives.
Google Docs, Sheets and Slides are converted to Word, Excel and PowerPoint on the way. Ordinary documents convert well. Watch for spreadsheets that use Google-specific functions or Apps Script, documents with long comment threads, and anything connected to a Google Form. Forms do not convert; rebuild the ones still in use in Microsoft Forms and update the links on your website and in volunteer sign-up emails.
Sharing is where a charity's data protection exposure often sits. Files shared with anyone who has the link, or with the personal addresses of past volunteers, can be mapped across by migration tools if you let them. Decide before the first pass whether you want those permissions recreated at all. Often the better answer is to migrate without external sharing and let owners reshare what is still needed under your new sharing policy.
Shortcuts in Google Drive, which point at files stored elsewhere, do not behave like ordinary files in a migration. Check how your tool handles them, and expect some people to discover that a folder they relied on was really a collection of shortcuts to other people's files.
Pre-stage, then cut over
Bulk passes can take days for large mailboxes and drives, and they run while people carry on working in Google, so start them weeks before cutover rather than days. Throttling on both platforms sets the pace. Plan for it instead of expecting to beat it.
Pick a cutover window that suits the charity's rhythm. Avoid fundraising deadlines, major events and the days your volunteer rota is busiest. A Friday evening switch with deltas over the weekend gives a quiet buffer; a mid-week switch puts support staff in the office when people first sign in. Either works if it is chosen on purpose.
Between the MX change and full DNS propagation, some mail will still arrive in Gmail. The final delta, or the mail routing arrangement your migration approach sets up, picks it up. Send test messages from outside the organisation, to several users, and check where they land before you declare cutover complete.
- Pilot with a small group of staff and volunteers, end to end including their own cutover, and fix what they report.
- Run the first full pass of mail and Drive for everyone while they keep working in Google.
- Run incremental passes as the cutover date approaches, so the final delta is small.
- Announce the date, what will change and what people need to do on the first morning.
- At cutover, change the MX records, ask users to stop working in Google, and run the final mail and Drive deltas.
- On the first morning, have people available to help with sign-in, multifactor registration and phones.
The things that catch people out
Calendar items migrate, but recurring meetings created in Google Calendar keep their Google Meet links, and those stop working once Google is switched off. Ask organisers to recreate important recurring meetings in Teams during the first week, starting with anything trustees or external partners attend.
Phones and tablets need setting up again with Outlook, Teams and OneDrive. This is quick for each person and slow across an organisation, so put a short guide in front of people before cutover and expect the first morning's questions to be mostly about devices.
Other services that use Sign in with Google, or that send mail through Gmail, are easy to miss: the donations platform, the volunteer rota tool, the newsletter system, the website contact form. List them during discovery and move each one to Microsoft sign-in or a supported Microsoft 365 sending method before you switch Google off.
Google Groups used as shared addresses need a new home: a Microsoft 365 group, a distribution list or a shared mailbox, depending on whether people need a shared inbox to work from or simply a way to reach several people at once.
Keep Google for a while, then close it properly
Do not cancel Google Workspace on cutover day. Keep it available, with access limited, for a set period long enough to answer the questions that arrive a few weeks later about a file that did not appear or a message that went astray. Check your Google contract dates so the overlap is planned rather than accidental.
Be clear with people about what the overlap is for. If staff carry on editing files in Google Drive after cutover because it still works, those edits will not reach Microsoft 365 and someone will lose work. Remove edit access where you can, and state the read-only expectation in every message about the change.
Before you close it, decide what you must keep for retention, safeguarding or legal reasons that has not been migrated, and export it with Google Vault or the admin export tools. Then remove the migration tool's access, revoke the service account and delegation, and close the account. Write down what was exported, where it is stored and who can open it.
Who owns what
Charities often run this with a small IT team or a single partner, which makes named owners more important, not less. IT or the partner owns the tenant, the tools, DNS and the cutover. A named lead in each team owns the mapping of their shared drives and checks their content after migration. Whoever manages volunteers owns the volunteer account list and the guidance volunteers receive. A senior sponsor owns the cutover date and the decision to switch Google off.
The week you are trying not to lose usually goes on things nobody owned: the forgotten volunteer system that relied on Gmail, the shared drive nobody mapped, the trustee who cannot sign in on the morning of a board meeting. Naming an owner for each is much cheaper than finding them during the first week.
Give the sponsor a short go or no-go list for cutover: pilot signed off, final passes on schedule, DNS changes prepared, guides sent, help available on the first morning. If an item is not ready, moving the date by a week costs far less than a cutover that spills into the week anyway.