Do we lose mail while the MX record changes?

Not if you prepare the window. Lower the MX TTL to 300 seconds at least two days before the cutover, because a shorter TTL only starts applying after the previous value expires. Then leave the cPanel mailboxes running for about two weeks after the switch, so anything delivered to the old host during the cached DNS window still exists, and a delta run of the data migration service brings it into Workspace.

Do contacts, calendars, filters and forwarders come across from cPanel?

No. An IMAP migration through the data migration service moves email and label data only, so calendar events, contacts, Drive files and Sites are not included. Filters, autoresponders, forwarders, aliases, mailing lists and the catch-all are configuration rather than messages, and they are rebuilt by hand in Gmail settings and the Admin console. That is why the inventory comes before anything else.

Can we keep the old hosting mailboxes as a backup MX?

Keep the mailboxes, but do not keep the old MX record. Leaving the hosting server in DNS as a lower priority backup means mail keeps arriving in a system nobody monitors and nobody authenticates. Delete the hosting MX at the cutover, leave the mailboxes themselves in place so nothing delivered during the cached DNS window is lost, run a final delta migration, and cancel the hosting mail account after that.

Migrate cPanel email to Google Workspace

Say a 14-person import business in San Salvador. Its mail has lived on shared hosting since 2016: eleven cPanel mailboxes, a webmail nobody enjoys, a 2 GB quota per account that accounting hit two years ago, and invoices that started landing in clients' spam folders this quarter. They want Google Workspace. Before anything else, they want to hear that nobody is going to lose eight years of email.

That is the real objection, and it is a reasonable one. The migration itself is routine work. The fear is not, because mail does get lost in these projects, almost always for one of two reasons: DNS moved before the mailboxes were copied, or nobody wrote down what the old host was sending on the company's behalf.

This is the order we work in when the starting point is cPanel or any other shared hosting mail, what the Google tooling actually copies, and where things quietly break.

Shared hosting mail is two systems, and only one of them migrates

The mailboxes are one system. The configuration around them is another: forwarders, autoresponders, filters, aliases, mailing lists, the catch-all address. Google's data migration service reaches the first over IMAP and cannot see the second at all. When the source is an IMAP server, the service moves email and label data only. Calendar events, contacts, Drive files and Sites are not part of an IMAP migration. Everything in cPanel that is configuration rather than a message gets rebuilt by hand in the Admin console, which is fine as long as somebody wrote it down first.

Three limits are worth knowing before you promise anything. The IMAP path in the data migration service supports up to 100 source users. Messages larger than 25 MB including attachments are not migrated. Shared and public IMAP folders are not supported. For a small company the first two rarely bite, but the 25 MB ceiling does, on exactly the mailbox you would expect, the one that receives scanned contracts.

The inventory, before anything is created

We open a sheet and fill it from the control panel itself, not from memory:

Every mailbox, its current size and its quota. The size tells you how long the copy will run. The quota tells you which accounts have been silently rejecting mail.
Every alias, forwarder and mailing list, with its destination.
Every filter and autoresponder, including the ones a user set from webmail years ago and then left the company.
The catch-all setting. On shared hosting it is often switched on, which means mistyped addresses have been landing somewhere for years.
Every application that sends as the domain: the invoicing or DTE provider, the online store, the CRM, the website contact form, the scanner in the corridor.
The current MX, SPF, DKIM and DMARC records, with their TTL values.
Who actually controls the registrar and the DNS zone. This is the item that delays cutovers.

The application list is the one people skip, and it is the one that produces the "everything works except the invoices" phone call a week later.

Create users the way you will pay for them

Each real person gets a user. Shared addresses such as info@ or ventas@ become groups, not accounts with a password three people know. Aliases stay aliases on the user who reads them. A company arriving from shared hosting usually has far more addresses than people, and the difference between modeling that correctly and creating one licensed user per address is most of the first year of licence cost.

Verify the domain with the TXT record Workspace gives you, create the users, and stop there. MX stays where it is.

Copy the mail while the old system is still live

The data migration service connects to the hosting server over IMAP and copies into the new mailboxes while mail keeps flowing normally to cPanel. Nothing is disrupted, so there is no reason to rush this stage. You need the mail server hostname, the IMAP over TLS port, and either each mailbox password or an administrative credential your host allows for migrations.

Source server:  mail.example.com
Port:           993 (IMAP over TLS)
Per mailbox:    address + password from the hosting control panel

Run the full copy days ahead of the cutover. Then run the service again afterwards against the same source. That second pass is a delta: it picks up everything that arrived at the old host in between, and it is the mechanism that makes the whole project safe. A source mailbox carrying more than 6,000 labels or folders also needs a delta pass to finish.

One check before you start. An account cannot receive more mail than its Workspace storage allows. If a 40 GB cPanel mailbox is heading into a plan with less storage than that, the import stops partway, and the fix is a plan change rather than a retry.

Lower the TTL two days early, not on the morning

This step decides whether your cutover window is measured in minutes or in a day. A record's TTL tells resolvers how many seconds to cache it, and a shorter TTL only starts applying once the previous value has expired. If the MX record has been sitting at 86400, lowering it this afternoon does not help this afternoon: resolvers that already cached the old record can hold it for another 24 hours before they start honoring the new, shorter value. Lower it at least two days ahead. Google recommends 3600 as a working value, and a shorter one such as 300 when you want to be able to reverse a change quickly, which is exactly the situation on cutover day.

; typical shared hosting default
example.com.   86400   IN   MX   0 mail.example.com.

; two days before the cutover: same target, shorter TTL
example.com.   300     IN   MX   0 mail.example.com.

The cutover, in order

Confirm the bulk migration has finished and that users can see their old mail in Gmail.
Replace the MX record with the Google Workspace value and delete the hosting MX. Do not leave the old one behind as a lower priority backup, because that is how mail keeps arriving somewhere nobody is watching.
Send a test message from an outside address and confirm it lands in Gmail.
Leave the cPanel mailboxes in place, still receiving whatever reaches them.
Run the delta migration the next day, and once more about a week later.
Raise the MX TTL back to 3600 when you are confident.

example.com.   300   IN   MX   1 smtp.google.com.

Google Workspace uses a single MX value, smtp.google.com. Registrars disagree about how it should be typed: some require a trailing period, and some expect the priority and the destination together in one field as 1 smtp.google.com. Domains that started on Workspace before 2023 may still carry the older set of aspmx records, and those are still supported, so there is no need to change them as part of this project. New MX records can take up to 72 hours to be recognized everywhere, although with a 300 second TTL already in place most senders follow within minutes.

The days after the switch are the double delivery window: some senders still resolve the cached old record and deliver to cPanel. That is expected, and it is harmless as long as the old mailboxes still exist. Deleting them on cutover day is the single most common way to genuinely lose mail in this migration. Two weeks is a reasonable holding period, with the hosting account cancelled only after the final delta run.

The senders that keep using the old server

After the MX change, mail.example.com usually still resolves and still accepts SMTP. Every application configured with that hostname and an old mailbox password keeps working, in the sense that it keeps sending. Those messages now leave through a server the domain no longer authorizes, and the copies land in a mailbox nobody opens. Work down the application list from your inventory and repoint each one: the store, the CRM, the contact form, the scanner, the invoicing platform. In El Salvador the DTE provider belongs on that list too, and we wrote up why electronic invoices land in spam separately.

Authenticate the same day

A domain leaving shared hosting is also leaving a shared sending reputation, which is usually one of the reasons for the move in the first place. Publish the new authentication on cutover day rather than next month:

example.com.         300  IN  TXT  "v=spf1 include:_spf.google.com ~all"
google._domainkey    300  IN  TXT  "v=DKIM1; k=rsa; p=MIIBIjANBg..."
_dmarc               300  IN  TXT  "v=DMARC1; p=none; rua=mailto:dmarc@example.com"

SPF is one record per domain. The hosting SPF record is replaced, not stacked next to the new one, because two SPF TXT records is a permanent failure. DKIM is generated in the Admin console under Gmail, Authenticate email: choose a 2048 bit key if your DNS provider supports it, keep the default google selector prefix, publish the TXT record, then return to the console and start authentication. A 2048 bit key does not fit in a single 255 character DNS string, so it goes in as several quoted strings inside the same TXT record, something some registrar interfaces handle for you and some do not. DMARC starts at p=none with a reporting address, and enforcement comes after you have read a couple of weeks of reports, which is the subject of moving DMARC from p=none to p=reject.

Leave the old host's DKIM selector and SPF include in DNS until you have confirmed that nothing sends through that server any more, then remove them.

What usually goes wrong

The old mailboxes were deleted on cutover day, so anything delivered during the cached DNS window is gone for good.
The catch-all was never recreated, and addresses that used to be quietly accepted now bounce.
Filters and forwarders were assumed to migrate. They do not, and they are rebuilt in Gmail settings and in the Admin console.
Someone expected contacts and calendars to arrive with an IMAP migration. Those are exported and imported separately.
The TTL was lowered on the morning of the change, so the old record stayed cached for the rest of the day.

How Guanacos Tech helps

We are an independent consultancy with Google-certified engineers, working in English and Spanish across North America and Latin America. We run the inventory, do the IMAP copy, sit on the cutover hour, rebuild the forwarders and filters, and publish SPF, DKIM and DMARC the same day, so the domain arrives authenticated instead of being repaired later. If you want to see where your domain stands before touching DNS, the email troubleshooter is free, a Workspace engagement sets out the scope, how we work covers scoping, and you can book a call at calendar.app.google.

Moving email from cPanel or shared hosting to Google Workspace without losing a message