You have decided on Google Workspace. The hard part is not the decision; it is the Tuesday morning when mail has to start arriving in a new place while years of old messages, folders and contacts are still sitting with your current host, and everyone in the office still needs to work.
This is a practical plan to migrate email to Google Workspace from cPanel hosting, another provider or a set of mailboxes nobody has documented. It is organised as a timeline: what to do before you touch DNS, the day of the switch, and the week after. Plan prices and plan choice are covered in our separate guide on what Workspace subscriptions cost in India, so they are left out here.
Before you migrate email to Google Workspace, take an inventory
Missing information causes more trouble in a migration than technical difficulty does. Make a simple spreadsheet with one row per address, and fill in:
- The address and the person who uses it.
- Whether it is a real mailbox, a forwarder or an alias of another address.
- Roughly how much mail it holds, from the current host’s control panel.
- How the person reads mail: webmail, phone, Outlook, Apple Mail.
- Whether they use IMAP or POP. This matters more than anything else on the list.
- Any password you will need from them to copy their mail.
Add one more section: every system that sends mail as your domain, such as the website, a billing tool or a newsletter service.
Why IMAP or POP decides your method
With IMAP, mail stays on the server, so a migration tool can copy everything from there. With POP, mail is often downloaded to one computer and deleted from the server. In that case the server is nearly empty and the real archive is in a local Outlook data file or another mail program on that person’s machine. Those people need a different route, covered below.
Week one: prepare Workspace without touching mail flow
- Sign up and verify the domain. Google asks you to add a TXT record to prove ownership. This changes nothing about where mail goes today.
- Create every user from your inventory, with temporary passwords you record securely.
- Recreate aliases and group addresses. Shared addresses such as info@ or accounts@ often belong as aliases or Google Groups rather than paid users. Our note on planning info@ and sales@ addresses helps with that choice.
- Lower the TTL on your MX records at your current DNS host, if the panel allows it. A shorter TTL means the switch spreads faster on the day.
- Check who controls DNS. Confirm you can log in to the panel where the domain’s records actually live, which is wherever the nameservers point.
Copying old mail: three routes
From another server over IMAP
Google’s data migration service, found in the Workspace admin console, can connect to an IMAP server and copy each user’s mail into their new mailbox. You give it the old server’s details and each mailbox’s login, and it works through them. Folders come across as Gmail labels. Run this first pass while the old server is still receiving mail, so the bulk of the history is already in place before the switch. For most small offices, this is the simplest way to move mailboxes to Workspace.
From Microsoft 365 or Exchange
The same migration service can pull mail from Microsoft-hosted mailboxes using admin access to the source. Larger or more complex moves can use Google’s other migration products; the Workspace admin help describes which tool suits which source.
From a POP user’s computer
If someone’s archive only exists in a local Outlook data file, Google’s migration tool for Microsoft Outlook can upload a PST file into the user’s Workspace mailbox. For other desktop programs, the usual method is to add both the old local folders and the new Workspace account to the same program over IMAP and drag folders across.
Switch day: changing where mail goes
Pick a quiet day and a time when few messages are expected. Then, in this order:
- Replace the MX records with the values shown in your Workspace setup. Remove the old provider’s MX entries entirely; leaving them alongside Google’s sends some mail to the old server.
- Update the SPF record so it authorises Google and any other service on your list. Keep it as one record.
- Generate and turn on DKIM in the admin console, publish the TXT record it gives you, then return and start authentication.
- Add or review DMARC, starting with a monitoring policy. The reasoning behind each record is in our explanation of the three DNS checks.
- Send test mail to each user from an outside account, and send out from each user to an outside account.
For a while, some senders’ servers will still have the old MX records cached and deliver to your old host. That is normal. It is why the old mailboxes must stay open.
The week after: catch the stragglers
- Run a final copy from the old server to pick up anything that arrived there after the switch.
- Move contacts and calendars. Mail migration from an IMAP host brings mail only. Export contacts as CSV or vCard files and import them into Google Contacts. Calendar entries can be exported as iCalendar files and imported into Google Calendar.
- Reconnect devices. Remove the old account from each phone and laptop, then add the Workspace one. Phones are covered in detail in our guide to getting company mail on Android and iPhone.
- Check the website’s mail. If the website is on cPanel hosting, make sure the server no longer thinks it handles your domain’s mail locally. Otherwise contact form messages addressed to you never leave the web server.
- Update every sender on your list so it either sends through an authorised route or is covered by your SPF and DKIM.
A test list for the first day
Do not rely on “it seems to be working”. Run these checks on the day of the switch and tick them off:
| Test | What a pass looks like |
|---|---|
| Outside account sends to each user | Arrives in the Workspace inbox, not the old server |
| Each user sends to an outside Gmail account | Arrives in the inbox; Show original reports SPF, DKIM and DMARC as passing |
| Mail to each alias and group address | Reaches the right people |
| Website contact form | The enquiry reaches the Workspace inbox |
| Website order or password reset email | Delivered and authenticated |
| Old labels and folders | Present for a sample of users, with recent and old messages |
| Phone access for each user | The new account syncs; the old account is removed |
Keep a note of anything that fails and recheck it the next day, once DNS caches have caught up. A failure that persists after that is a real fault, not propagation.
Common reasons a move to Workspace goes badly
- Cancelling the old hosting the same day. Late deliveries and any mail not yet copied are lost.
- Forgetting POP users. Their server mailbox looked small, the migration said “complete”, and their real archive stayed on an old laptop.
- Two SPF records after the old provider’s record was left in place.
- Migrating everyone into one admin mailbox instead of into each user’s own.
- Nobody told the staff. People keep checking the old webmail, or keep sending from a phone still using the old server.
How long to keep the old mailboxes
There is no fixed rule, but cancelling too early is the expensive mistake and keeping them a little longer costs very little. Keep the old service running until all of these are true:
- No new mail has arrived at the old server for some time.
- Every user has confirmed their old folders are present in Workspace.
- POP users’ local archives have been uploaded or saved somewhere backed up.
- Contacts and calendars have been exported and imported.
- Nothing, such as a scanner, a website plugin or an accounting tool, still logs in to the old server to send mail.
When you do close the old mailboxes, take one last export of each and store it with your other business records. If the old mail was on your web hosting, remove only the mailboxes, not the hosting account that still runs the website.
A short message to send your team
A brief note avoids most confusion. Tell people the switch date, that their address does not change, how to sign in to the new account, that old mail will appear as labels, and who to tell if something is missing. Ask them not to delete anything from the old account until you say so.
When to get a hand with it
A two-person office with IMAP mailboxes can do this in an afternoon with care. It gets harder with many users, POP archives, several sending services, or a domain whose DNS nobody can log in to. That combination is where an email setup service earns its keep, because the planning and the DNS are the parts that cause lost mail.
Keep the inventory spreadsheet after you finish. Add the date of the switch, the DNS records you changed and which old accounts were closed and when. It is the document you will want the next time someone joins, leaves or asks where an old message went.
Next in this series: Email Hosting vs Web Hosting Email: Which to Use
