Migrate Business Email from Google Workspace or Microsoft 365

Moving business email to a new provider is mostly a scheduling problem. The mailboxes, the DNS change and the sender authentication all have to line up, and the old system has to stay alive until nothing more arrives there.

This guide is for Singapore SMEs that already run email on Google Workspace or Microsoft 365 and are considering a switch, for example to Unlimited Email Hosting. It covers the cutover itself. For choosing between providers, see Business Email on Your Own Domain: A Singapore Team Guide.

Quick answer

Confirm that a migration is the right move

Switching costs time, so check that the reason is solid. Common triggers are per-user costs that grow with headcount, a need for many mailboxes with modest storage each, or consolidating several domains in one place.

If the driver is only a price difference, work out the full cost of the migration effort before committing. Staff time for testing and device changes often matters more than the monthly fee.

Build a migration inventory first

Most migration surprises come from things nobody listed. Before you create anything, record the following in a shared sheet.

• Mailboxes and aliases. Every person, plus role addresses such as sales@ or accounts@, and any aliases that point to them.
• Shared mailboxes and groups. Distribution lists and shared inboxes often live in the admin console, not in a user's account.
• Forwarding rules. Note rules that send mail to personal addresses or other systems.
• Services that send as your domain. Invoicing tools, website forms, newsletters and CRM platforms all need to stay in your SPF record.
• Devices and clients. Phones, Outlook profiles and scanners will each need new settings after cutover.
• Calendars, contacts and files. A mail-only sync copies messages. Decide separately how you will move or export everything else.

Choose how the existing mail will be copied

You have three practical routes. They can be combined, and the right mix depends on mailbox size and how much downtime you can tolerate.

Check the source platform settings

On Microsoft 365, Microsoft states that IMAP4 is enabled by default when a mailbox is created. An admin may still have switched it off for individual mailboxes, so check each one in the Exchange admin center.

On Google Workspace, a full export is a super administrator task. The Data Export tool requires 2-Step Verification on that admin account, cannot be cancelled from the Admin console once started, and deletes data from Google's temporary bucket 60 days after the export begins. Download promptly.

Sign-in is the usual blocker, so check it before the first copy. Microsoft states that Basic authentication is disabled in all Exchange Online tenants, so IMAP needs OAuth 2.0 and a tool that supports it. Depending on the tool, an admin may need to register or approve the app, grant tenant consent and give it access to specific mailboxes, as described in Microsoft's OAuth guide for IMAP.

Do not assume Google Workspace accepts a regular account password either. Google says third-party apps must use OAuth, and that IMAP no longer works with legacy passwords (basic authentication). Check that your sync tool supports OAuth and that your organisation's app access controls allow it.

Before production, copy and run a differential sync on one mailbox. Compare folder counts, attachments and recent messages, and fix any gaps while only one user is affected.

Plan the cutover in order

The MX records tell the internet where to deliver your mail. Changing them is the moment of cutover, so everything else should be ready before it.

1. Create the new mailboxes first. Switching MX records before the mailboxes exist causes bounces.
2. Run the first sync days ahead. This copies the bulk of the history while everyone keeps working normally. Validate one mailbox first.
3. Prepare sender authentication. Add the new sender to SPF, publish and enable DKIM, then send test messages from the new mailboxes and confirm SPF, DKIM and DMARC alignment pass.
4. Lower the MX record TTL in advance. If your DNS host allows it, a shorter TTL helps the change spread sooner. Do this at least a day before the switch.
5. Pick a quiet window. Early on a weekend suits most offices.
6. Change the MX records. This changes the inbound route only; it does not move or authorise outbound mail. Do it wherever your DNS is hosted, which may be your registrar rather than your email provider.
7. Run a final sync, then repeat it. This catches mail that arrived at the old system during the change. Keep syncing until no new mail appears there.

Allow for overlap. Google's guidance on pointing MX records to Gmail notes that the rest of the internet can take time to learn about the change, up to 48 hours in its example, and that you may keep receiving mail at the old provider meanwhile. The same behaviour applies when you move away. Keep the old mailboxes active and watch them during that period.

Microsoft 365 domains need extra care

Microsoft documents that a domain set as authoritative delivers to recipients listed in the tenant and rejects unknown ones. While old mailboxes still exist, colleagues still on Microsoft 365 may therefore deliver to them internally instead of using your new MX records. Ask your admin to plan this step rather than discovering it after cutover.

Fix sender authentication before sending from the new platform

A new provider means new sending servers. If SPF and DKIM still describe the old platform, legitimate mail can land in spam or fail DMARC checks. Complete these steps before normal sending starts from the new environment.

• Add the new provider to SPF and keep the old platform and every other service you listed in the inventory.
• Publish the new provider's DKIM key, enable signing and confirm that messages are signed.
• Send test messages to external mailboxes and check the headers for SPF and DKIM pass and DMARC alignment.
• Remove the old platform from SPF only after the old environment has stopped sending and nothing still sends through it.
• Watch DMARC reports for unexpected failures during the first weeks.

The full record syntax is in SPF, DKIM and DMARC Setup Guide for Singapore SMEs.

Common mistakes to avoid

Check these in the first two weeks

Treat the migration as complete only when these checks pass, not when the first sync finishes.

• Repeat the differential sync until it finds nothing new, review the sync logs, and spot-check key emails and attachments.
• Send and receive test messages internally and with Gmail and Outlook.com accounts, including attachments.
• Check the old system for late arrivals and re-sync if needed.
• Review bounce messages and spam complaints from key customers.
• Confirm that forms, invoices and newsletters still send and pass authentication.
• Collect a short list of device problems from staff and fix them in one batch.

Frequently asked questions