Google Workspace Email Migration — Practical Guide for SA Businesses

Google Workspace email migration is the process of copying your existing email history, contacts, and calendar data from your current mail system — whether that is a cPanel web host, Microsoft 365, or another provider — into Google Workspace before switching mail routing to Google. If you are working through the broader decisions around professional digital infrastructure, our guide to website builders for South African businesses covers what that setup looks like end to end.

The migration itself costs nothing beyond your Workspace licence — Google provides native tools in the Admin console that handle most South African scenarios without third-party software. What causes lost mail and re-dos is not the tooling but the sequence: most operators update their MX records first, then realise their historical mail never transferred. This guide maps the right tool to your source system and walks through the steps for the most common local setup.

For businesses still comparing platforms, a business email migration South Africa decision ultimately comes down to source system and team size — covered in our Google Workspace vs Microsoft 365 comparison for SA businesses.

What Google Workspace Email Migration Actually Involves

A Google Workspace email migration is a two-phase operation: a data transfer phase that copies your existing messages, contacts, and calendar entries into Workspace, and a cutover phase that updates your MX records so new mail routes to Google's servers. Most operators conflate the two or execute them in the wrong order.

The data transfer phase runs in the background while your old system stays fully operational. Your team continues sending and receiving on the old platform — nothing breaks, no one needs to log in differently. Only once the import is complete do you update the MX records. After the switch, a follow-up delta import captures any messages that arrived on the old server during the transfer window.

What a migration does not require:

• Taking your old mail server offline during the import
• Reconfiguring email clients before the cutover
• Third-party paid software for businesses with fewer than 100 users

Which Tool Should You Use?

The right migration tool depends on your source system, not your company size — Google publishes a native tool for each scenario.

The data import tool lives in the Google Admin console under Account > Data migration and requires no software download. GWMME (Google Workspace Migration for Microsoft Exchange) is a free Windows application that must be installed on a physical or virtual Windows machine — if your business runs entirely on macOS or Linux, you will need to provision a Windows environment before you can run the Exchange migration path. This is a real constraint that is not obvious until you are mid-process.

Step by Step: Moving from cPanel Hosting

The majority of South African small businesses start on shared cPanel hosting — Afrihost, xneelo, HOSTAFRICA, or similar — with email running on the host's built-in mail server. For this setup, an email migration to Google Workspace uses the data import tool directly, without additional software, because cPanel mail servers speak IMAP natively.

Before you begin, confirm two things: you have super administrator access to your new Workspace account, and the domain's DNS is not locked at your registrar.

1. Sign up for Google Workspace and verify your domain. Google requires a TXT record added to your DNS zone to confirm domain ownership. In cPanel, this is done under Zone Editor. Verification typically completes within the hour, though DNS changes can take longer depending on your registrar's TTL settings.
2. Create all user accounts in Google Admin. Every person you plan to migrate needs an active Workspace licence with Gmail enabled before the import runs. An import directed at a non-existent account fails silently — check your user list matches your intended account roster before starting.
3. Enable IMAP on the source mail server. In cPanel, IMAP is usually enabled by default, but verify it. Google's import tool also requires that All Mail, Spam, and Trash labels are accessible over IMAP — some cPanel configurations suppress Trash from IMAP view. Check this before uploading your user list.
4. Open the data import tool. In Google Admin, go to Account > Data migration. Select "Email" as the data type, then "Other IMAP server" as the source. Enter your cPanel IMAP hostname (typically mail.yourdomain.co.za), port 993, and SSL.
5. Map users via CSV. For more than a handful of accounts, upload a CSV file that lists source email addresses and their corresponding Workspace destination addresses. The CSV must be under 128 MB. You can migrate up to 100 IMAP users per batch — if you have more, run batches sequentially; the tool does not duplicate messages already transferred.
6. Start the import and monitor progress. The import runs in the background. Check the migration status panel for errors — failed accounts usually mean an incorrect password or a locked IMAP folder. Fix the cause and re-run; already-migrated messages are not duplicated.
7. Run a delta import. Once the main import completes, trigger a delta import to pull in any messages that arrived on the old server during the transfer window. This closes the gap before you update MX records.

The full import for a five-user business typically completes overnight. A 20-user import run across a weekend is a practical timeline. Once you are satisfied with the import, proceed to the MX record cutover.

If this migration is happening alongside a hosting change, the sequencing challenge is similar — our guide to moving your website without downtime covers the DNS discipline for that context.

Switching from Microsoft 365

For Exchange Online (Microsoft 365) migrations, the same web-based data import tool that handles cPanel/IMAP moves also works — no Windows machine required for this path. The tool supports up to 1,000 users per batch from Exchange Online, with a CSV mapping file under 10 MB.

1. Open the data import tool in Google Admin (Account > Data migration — paths may vary by Workspace edition or recent UI updates). Select Email as the data type and Microsoft Exchange Online as the source.
2. Authenticate with your Microsoft 365 admin credentials to authorise the connection between tenants.
3. Upload a CSV mapping file listing source Microsoft 365 addresses and target Workspace accounts. The file must be under 10 MB; the tool supports up to 1,000 users per batch.
4. Configure the import scope — mail, calendar, contacts — and set date ranges if you only want to bring across a specific period rather than the full archive.
5. Start the import and monitor progress. Run a delta import once the main transfer completes to capture any messages that arrived during the window.

One practical consideration: Exchange migrations include your entire Outlook folder structure, not just the inbox. Map your target Workspace labels to match before running so imported mail lands in a logical hierarchy rather than a flat dump.

MX Records, DNS Propagation and the Cutover

Switching your MX records is the moment new incoming mail starts routing to Google's servers — this step should happen after the data import is complete, not before.

In cPanel's Zone Editor, delete any existing MX records and add Google's five MX entries:

After saving the MX records, go to Email Routing in cPanel, select your domain, and set it to Remote Mail Exchanger. Without this step, cPanel may continue trying to handle incoming mail locally — causing delivery failures even after your MX records are pointing to Google.

DNS propagation takes anywhere from a few minutes to 48 hours depending on your registrar's TTL settings. During that window, some messages may still arrive at the old cPanel mail account. Keep that account active and check it for at least 24 hours post-cutover. Any messages that land there can be captured in a final delta import run.

While you are in the DNS zone editor, add your SPF record, generate and publish your DKIM key (in Google Admin under Apps > Google Workspace > Gmail > Authenticate email), and configure a DMARC policy. An email domain authentication checklist covers the exact record values and order — without these records, outbound mail from your new Workspace accounts is likely to be filtered or rejected by recipients from day one.

POPIA and Cross-Border Data Transfer

A google workspace email migration moves personal information — client correspondence, supplier contacts, employee communications — to Google's servers located outside South Africa. POPIA section 72 governs cross-border transfers of personal information and requires either an adequate level of protection in the recipient country or contractual safeguards.

Google Workspace addresses this through a Data Processing Addendum (DPA) that forms part of the Workspace agreement. Google publishes a Data Processing Addendum as part of the standard Workspace agreement — confirm with a POPIA-qualified adviser that it satisfies your specific s72 obligations before migrating.

Practical steps for SA businesses completing a migration:

• Review and accept Google's DPA as part of the Workspace account setup (it is incorporated into the standard terms).
• Update your internal privacy notice or employee information sheet to reflect that email is now processed by Google as a third-party operator.
• If your business handles special personal information (health data, financial records, children's data) at scale, take specific POPIA advice before migration rather than relying on the standard DPA alone.

Businesses setting up professional business email addresses for the first time face the same cross-border transfer question — the DPA applies from the moment the first Workspace account is activated.

Why South African Businesses Choose Growth Pulse Media

Growth Pulse Media's founder built and scaled a large South African ecommerce business before founding the agency — which means the infrastructure questions (email, DNS, domain, hosting) are not abstract. They have been worked through at business scale, with real consequences when the sequence goes wrong.

Our web design service regularly includes email migration as part of the brief. Not because it is technically complex, but because doing it in the wrong order — MX records before the data import — creates weeks of support issues and frustrated staff. We handle the cPanel-to-Workspace path, the Exchange Online migration, and the SPF/DKIM/DMARC configuration in sequence, with a senior operator on every engagement.

We keep a limited client load to ensure senior attention on every brief. You deal with the person who built the process, not a junior account manager working from a checklist.

Who This Guide Is Not For

Frequently Asked Questions

How long does a Google Workspace email migration take?

For a small business with five to ten users on a cPanel host, the data import typically completes overnight. A 20-user migration run over a weekend is a reasonable timeline. Larger Microsoft 365 migrations with 100-plus users can span days to several weeks depending on mailbox volume and the rate at which the tool processes data. DNS propagation after the MX record cutover adds up to 48 hours of variable mail routing — plan the cutover for a Friday evening so propagation resolves over the weekend.

Will my team lose any emails during the migration?

Not if you follow the correct sequence. Run the full data import before updating MX records, keep the old mail server live for at least 24 hours after cutover, and run a delta import at the end to capture anything that landed on the old server during the transfer window. The data import tool does not duplicate messages already transferred on a re-run, so there is no risk from running it twice.

Can I migrate email to Google Workspace without third-party software?

Yes, for cPanel or IMAP and Workspace-to-Workspace moves. Google's data import tool in the Admin console handles both at no extra cost. Microsoft 365 and Exchange migrations use GWMME, which is free but requires a Windows machine. Third-party tools like CloudM or BitTitan are only necessary for complex multi-system migrations or large enterprise estates that exceed what the native tools handle cleanly.

What happens to email aliases and shared mailboxes during migration?

Aliases and shared mailboxes are not automatically detected or replicated by the migration tool — you need to create them in Google Workspace before or immediately after the data import. Set up your email aliases and shared mailboxes in Google Admin, then verify they receive mail correctly within 24 hours of MX record cutover. A test message to each shared address immediately after cutover is a reliable sanity check.

Do I need to set up SPF, DKIM, and DMARC after migration?

Yes — these are separate from the MX record change and must be added to your DNS zone manually. The MX records route incoming mail; SPF, DKIM, and DMARC authenticate outbound mail so it is not filtered as spam. Generate your DKIM key in Google Admin under Apps > Google Workspace > Gmail > Authenticate email, then publish it in your DNS zone alongside your SPF and DMARC records. Do this on the same day as cutover, not days later.

Dirk van Greuning Founder, Growth Pulse Media

Founder of Growth Pulse Media and a specialist in South African search dominance. Dirk translates his experience in scaling South African businesses into high-velocity digital strategies for B2B and retail leaders. He writes about SEO, lead generation, and paid media from an operator's perspective — prioritising pipeline value over impressions.

Connect on LinkedIn