Migrating to Google Workspace: email, contacts, calendars and files

Start with an inventory, not with DNS

The failures we get called about are almost never the import itself. They are the thing nobody wrote down: a forwarder that fed the accounts team, a shared calendar the reception desk lived by, a website contact form that quietly sent mail through the old server. Spend an hour on the list below before you buy a single licence.

Which Google tool moves your data

Google has narrowed this down considerably. In practice almost everything now runs through the data import tool in the Admin console, and GWMMO survives for the specific case of Outlook data sitting on someone's PC.

If you are leaving a legacy G Suite subscription rather than another mail host, read what happened to G Suite first, because the account may simply need an edition change rather than a full migration.

The migration sequence

1. Choose the edition and create the account. Pick the plan from the inventory, not from the brochure: mailbox sizes tell you whether Business Starter's pooled storage is enough or whether you need Standard. Google offers a 14-day trial for up to 10 users if you want to test an import before committing.
2. Verify the domain. Add the TXT record Google gives you at the domain root. It is usually active in about 10 minutes and Google's confirmation is normally quick, up to an hour. Verification does not touch mail flow, so this step is safe to do weeks in advance.
3. Build the accounts to match the inventory. Create users, then groups for the shared addresses and aliases for the spellings people already use. Do this before importing, because the import needs a destination mailbox to write into.
4. Pilot with two mailboxes. Take one heavy user and one ordinary one. Run the import, then check folder structure, dates, attachments, unread state and anything filed in nested folders. You learn more from two real mailboxes than from any amount of planning.
5. Run the first historical import while old mail is still live. This is the whole trick. The data import tool reads the old mailboxes over IMAP or the Microsoft connector while those mailboxes carry on receiving. Nothing about this step is visible to users, and it can run for days on a large mailbox set.
6. Prepare the DNS change before you make it. Log in to the panel that actually controls the zone, find the existing MX records, and lower the TTL a day ahead if the panel allows it. Have the new record values written down so the change itself takes a minute.
7. Cut over the MX record. Replace every old MX record with the single Google record. Do it at the quietest hour you have, which for most Nepali offices is late evening or a Saturday.
8. Leave the old mailboxes running. Do not delete accounts or cancel the old hosting on cutover day. During propagation some senders will still deliver to the old server, and you want that mail to land somewhere retrievable.
9. Run a delta import after cutover. Once MX has settled, run the import again for the same users. The data import tool brings across what arrived on the old server during the overlap without duplicating what it already copied.
10. Reconfigure devices and clients. Phones, Outlook profiles and any application that sends as your domain get their new settings now. Budget real time for this: it is the step that generates the support calls.

Downtime: what genuinely happens at cutover

Here is the accurate description. When you change the MX record, mail servers around the world pick up the new value at different times depending on their cached copy of your DNS. For a few hours, and occasionally longer, some senders deliver to Google and some still deliver to the old server. Neither message is lost. They just land in two different places.

That is why the overlap matters. Keeping the old mailboxes alive means nothing bounces, and the delta import sweeps the stragglers into Google afterwards. The realistic user experience is not an outage but a short period where a few messages arrive in old webmail and have to be collected there or wait for the delta import. Tell staff that in advance and cutover day is uneventful.

If you cannot accept even that, the alternative is dual delivery, where mail is deliberately delivered to both systems during the transition. It is more moving parts and more room for error, so we use it only where the business case demands it. Our note on split and dual delivery explains when it is worth the complexity.

Notes for each source you might be leaving

cPanel or Plesk webmail

The commonest starting point in Nepal, because email came bundled with the hosting. Check three things. First, that IMAP is reachable from outside, with the correct hostname and port. Second, mailbox sizes: hosting mailboxes that have never been cleared are often enormous, and messages above 25 MB will be skipped by the import. Third, folder naming, because IMAP folder prefixes vary by server and odd prefixes turn into odd labels in Gmail. Also remember that the hosting account keeps the website even after mail moves, so the MX change is the only DNS record that should be touched.

Zoho Mail

Zoho migrates cleanly over IMAP once IMAP access is enabled for each mailbox in Zoho's own settings. If accounts use two-factor authentication, they will need application-specific passwords for the import to authenticate. Zoho groups and shared inboxes do not carry across as objects, so rebuild them as Google Groups.

Microsoft 365 and Exchange Online

The data import tool has a Microsoft source, so this does not need a third-party product for mail. The part that catches people out is licence timing: keep the Microsoft licences active until the import and the delta import are both finished, because a deactivated mailbox cannot be read. Shared mailboxes, distribution lists and Teams content are separate items on your inventory, and Teams and OneDrive have their own source types in the tool.

Free Gmail and old G Suite accounts

A business running on personal Gmail addresses is really several single-user migrations. The data import tool has a single-user Gmail source for exactly this. The bigger job is usually not the mail but the ownership question: work files sitting in a founder's or an employee's personal Drive need to be moved into the company account, ideally into Shared Drives, before that person's personal account stops being convenient to reach. An old G Suite subscription, by contrast, migrates as a Google Workspace source.

Contacts, calendars and files

Mail gets the attention, but the other three data types have their own paths. Contacts export from most systems as a CSV or vCard file and import into Google Contacts per user. Calendars export as ICS files and import into each user's calendar, after which shared calendars are recreated and shared again in Workspace, because sharing permissions do not travel with an export.

Files are the decision that most affects your timetable. Small teams can copy documents into Drive and Shared Drives manually in an afternoon. OneDrive, SharePoint Online, Teams and Dropbox can be imported with the data import tool. For a genuinely large file estate, Google's published guidance is to work with a Google partner rather than improvise, and it is sensible advice: a Drive migration measured in terabytes is a project with its own plan, not a step in the email cutover. Whatever the size, set up your Shared Drive structure before importing, or you will end up sorting thousands of files afterwards.

Post-migration checks

Do these on the day, not a week later, while the old system is still available to compare against.

1. Two-way mail test. Send from each migrated account to an outside address and reply back. Check a Gmail address, a Microsoft address and one address at a customer's own domain.
2. Read the headers. Open a received message, view the original, and confirm SPF and DKIM show as passing. If they do not, fix authentication now rather than after complaints start. Our guide on mail going to spam covers the usual causes.
3. Folder and date spot checks. Pick the oldest message, the newest, one with a large attachment and one in a deeply nested folder. Confirm each arrived with the right date and label.
4. Aliases and groups. Mail every shared address from outside the company and confirm it reaches the right people. This is the step most often skipped.
5. Applications that send mail. Submit your own website contact form, run a test invoice from the billing system, and check anything scheduled such as nightly reports.
6. Signatures and out-of-office. Neither migrates. Set them again, and take the chance to standardise them across the company.
7. Mobile and desktop clients. Confirm every phone syncs and no device is still logged into the old server pulling mail out of it.

When to switch the old system off

Keep the old mailboxes for two to four weeks after cutover. That covers the delta import, anything a user notices late, and the slow correspondent who only writes once a month. Before you cancel, take a full copy of the old mailbox data and keep it somewhere safe. Then remove the old mail service, and remember to tidy the DNS: leftover MX records, old SPF entries pointing at the previous host and stale autodiscover records all cause delivery oddities months later.

Inside Workspace there is a related deadline worth knowing. When you delete a user, Google keeps the data for 20 days for restore and it is unrecoverable after that, so transfer Drive and Calendar data before deleting anyone during the tidy-up.

Getting help with the move

WebsNP performs Workspace setup and mailbox migration for its own Workspace customers, from cPanel email, Zoho or another Workspace account, and we plan cutovers around your working hours rather than ours. If you want to see the shape of that work before deciding, our email migration services page describes it, and the setup guide lists every DNS record and console setting a finished migration should end with. If you would rather talk it through with the mailbox list in front of you, get in touch.