Articles · Migration

2026-12-16 12 min EN / FR

Leaving Google Workspace or Microsoft 365

Email, calendar, contacts and shared documents form the backbone of a company. Moving them is one of the most visible migrations you can do, since everyone notices if it goes wrong. It is also one of the most predictable, as long as you plan for the details that cause most incidents: DNS, authentication records, shared resources and people's habits.

Step 1: Be clear on why, and where to

Common reasons: cost, data location or sovereignty requirements, wanting independence from a single large vendor, or a need for a different mix of services.

Common destinations:

  • Another suite (a European provider, or the other big suite)
  • Dedicated email hosting combined with separate tools for files and calendars
  • Self-hosted components

Be honest about the last option. Running your own mail server is demanding: deliverability, spam filtering, security updates, and availability are your responsibility, and mistakes are visible to your customers. For most small companies, a reputable managed provider under an account in your name is the safer choice, even when the goal is independence. Independence means being able to leave, not necessarily running everything yourself.

Step 2: Inventory everything the suite does for you

People think "email", but the suite usually also holds:

  • Mailboxes, and their size and age
  • Aliases and group addresses (contact@, sales@, support@)
  • Shared mailboxes and delegated access
  • Mailing lists
  • Calendars, shared calendars and meeting room resources
  • Contacts and shared address books
  • Files: personal drives, shared drives, and sharing links
  • Collaborative documents, which may lose formatting or features when exported
  • Video meetings and recurring meeting links
  • Single sign-on: other services where people log in with their company account
  • Mobile device management policies
  • Admin roles and security settings
  • Third-party apps and add-ons connected to the accounts
  • Retention and archiving rules, especially if you have legal obligations

The unexpected items, like single sign-on and links in old invitations, are the ones that cause problems.

Step 3: Check dependencies on the account

A company login is often used as the identity for other tools. Before migration, list every service where people sign in with the suite's account, or whose password reset emails go to a company address. If email moves and these are not updated, people can lock themselves out of important tools.

Step 4: Prepare the technical groundwork

  • Verify domain ownership and registrar access. See the account ownership audit. You will need to edit DNS.
  • Lower the DNS TTL on MX and related records at least two days ahead. See migrating DNS without breaking email.
  • Create the new accounts at the destination in your company's name, with at least two administrators.
  • Prepare the new authentication records (SPF, DKIM, DMARC) for the new provider. These must be correct at switch time, or outgoing mail may be rejected or sent to spam.
  • Plan for every other sender using your domain: the website, CRM, invoicing tool, newsletters, helpdesk. Each must be included in the new SPF and, if relevant, set up with its own DKIM.

Step 5: Migrate the data

Most providers offer migration tools that copy mailboxes through the old system's interface. The basics:

  • Pilot with two or three volunteers, ideally including someone with a messy mailbox.
  • Copy mail ahead of the switch, while people keep working on the old system. A first pass copies the bulk, and a second pass picks up recent messages.
  • Migrate calendars and contacts, and check recurring events, time zones and invitations that include external attendees.
  • Migrate files, and be aware of what changes: sharing links will break, permissions need rebuilding, and collaborative documents may need conversion. Tell people that old links in emails and wikis will stop working, and plan to update the important ones.
  • Shared resources: recreate group addresses, delegations and shared mailboxes before the switch.

Mailbox size matters. Very large mailboxes take much longer, and some tools throttle transfers. Start early, and consider archiving very old mail rather than moving it live.

Planning a suite migration?

We handle DNS auth records, mailbox sync and the cutover week.

Ask about a Workspace move Migration

Step 6: Cut over

Choose a quiet moment, ideally early in the week so that issues are noticed while support is available, and not before a holiday.

  • Final sync of the old mailboxes.
  • Change the MX records to the new provider, and update SPF, DKIM and DMARC.
  • For a short period, mail may arrive in either place. Keep the old mailboxes active and run another sync to catch stragglers.
  • Reconfigure devices: the new provider's setup, new passwords, and two-factor authentication.
  • Test sending and receiving with external addresses at several providers, and read headers to confirm authentication passes.
  • Check each system that sends mail on behalf of your domain.

Step 7: Support the people

Technical success can still feel like failure if users are lost. Prepare:

  • A short guide with screenshots for setup on computer and phone
  • A clear date and time of the change, and what they must do
  • Support availability on the days of and after the switch
  • A reminder about what changes: interface, shortcuts, sharing, meeting links
  • A list of known differences so they are not surprised

Habits matter more than features. Expect questions for the first two weeks.

Step 8: After the move

  • Keep the old accounts read-only for several weeks in case something was missed
  • Check for bounced mail and spam reports, and review authentication reports
  • Update links and references to old shared files
  • Update other services that used the old login
  • Take a final full archive export of the old suite, including data you chose not to migrate, and store it securely
  • Cancel the old subscription only when you are sure, mindful of renewal and notice dates
  • Document the new setup: accounts, admins, DNS records and recovery details

Common pitfalls

  • Email authentication left unconfigured, so mail is rejected or filtered
  • Forgotten third-party senders that no longer pass SPF
  • Broken sharing links to documents, discovered by clients
  • Calendar chaos: recurring meetings duplicated or lost, meeting links that no longer work
  • Single sign-on dependencies forgotten
  • Aliases and group addresses missed, so mail to sales@ disappears
  • Migrating on a Friday
  • Cancelling the old suite right away and discovering a gap
  • No second administrator at the new provider

Checklist

  • Reason and destination decided, accounts in our name, two admins
  • Inventory of mailboxes, aliases, shared resources, files and logins done
  • Dependent services identified
  • TTL lowered, SPF/DKIM/DMARC prepared for all senders
  • Pilot completed with a few users
  • Mail copied in advance, and a final sync planned
  • User guide and support ready
  • Cutover tested in both directions with header checks
  • Old accounts kept read-only for several weeks
  • Final archive saved, documentation written

Related

From inventory to a quiet cutover

Send what you know about mailboxes, aliases and SSO. We will propose an order of operations.

Start a conversation Infrastructure