How to Migrate Email into Google Workspace Without Losing Folders

Moving mail into Google Workspace looks like a menu action — the Admin console has a Data migration page, you point it at your old mail server, and it starts copying. In practice it is a per-user IMAP import with real limits, and the surprises are almost never in the mail that arrives. They are in your folder structure, in the filters you spent years tuning, and in the fact that Gmail stores labels where the old system stored folders.

This is how to migrate email to Google Workspace using Google's built-in Data Migration Service — the tool also called the Data Import Tool in newer Admin console screens. It runs from admin.google.com, authenticates against a source mailbox over IMAP, and copies messages into Gmail. From Google's own migration product matrix it is scoped for organizations up to about 1,000 users, and per its own docs it moves email and label data only. Calendar, contacts, filters, delegates and Drive files are out of scope.

This is a planning guide, not a click-by-click tutorial. Google reworks the Admin console on its own release cadence; the labels below match the current layout, but always cross-check Google's live admin help for the exact button text.

What actually moves — and what doesn't#

The single most useful thing you can do before starting is set expectations correctly on what will and will not be inside Gmail on the other side. Google's own docs are explicit: the built-in service handles mail from an IMAP source, and folders on that source become labels in Gmail. Everything else is a separate tool, a separate project, or a recreate-by-hand job.

Folders becoming labels is the conversion that most surprises people. In Gmail, a message can carry many labels at once — unlike a filesystem-style folder tree where a file lives in exactly one place. Nested source folders arrive as nested Gmail label names such as Clients/2025/Contracts. A message that lived only in that folder ends up on the label with the same path; a message that lived in three source folders arrives in Gmail carrying all three labels.

Pre-migration checklist#

Most Data Migration Service failures trace back to something on this list, not a bug in the tool itself. Work through it in order — several items block later ones, and the ones on top are cheaper to fix a week in advance than an hour before cutover.

• Confirm the source server accepts IMAP over TLS, and note whether it requires an app password (Yahoo, Fastmail, Gmail with 2FA, Outlook.com in many tenants) or a real password.
• Inventory every source mailbox size, so you know which accounts will take longest and can batch the biggest ones separately from the rest.
• Provision every destination user in Google Workspace and assign a license before starting — a migration job cannot import mail into a mailbox that does not yet exist.
• Confirm someone on the project has super-admin rights in the Google Workspace tenant; the migration UI is under the Admin console and needs that role.
• Decide which source folders you actually want migrated and which you want to exclude — Junk and Trash usually should not become new Gmail labels, and DMS supports an explicit exclude list for exactly this.
• Warn users the folder structure they see today will arrive as Gmail labels, and give them one screenshot of what that looks like before they hit 'why does it look different'.
• Drop the source domain's MX TTL under an hour, at least 72 hours before any planned DNS cutover.
• Have a rollback trigger written down — number of missing-mail reports, hour count, and who has authority to call it — before the batch starts, not during it.

The Data Migration Service steps, in order#

1. 1

   Prepare the source mailboxes

   Ensure IMAP is enabled and reachable on the source server, and generate app passwords where the source requires them. Google's built-in tool uses IMAP, not a proprietary API, so anything that blocks IMAP blocks the migration.

2. 2

   Provision the Google Workspace destination users

   Create every target user with the primary address that either matches or intentionally maps to the source mailbox. An unlicensed or missing destination fails the job at start time — earlier than you might expect, which is useful.

3. 3

   Open Data migration in the Admin console

   Sign in as super-admin at admin.google.com and open Data migration. Choose Email as the data type and the source you are migrating from — Google Workspace, generic IMAP, or the Exchange path where offered.

4. 4

   Set the connection and authentication

   Provide the source's IMAP hostname and port, and either connect the source's OAuth or supply per-user credentials or app passwords. Test the connection before saving the endpoint.

5. 5

   Configure scope: date range and folder exclusions

   In the migration's advanced settings, pin a start date if you only want the last N years, and use the Exclude folders list to skip Junk, Trash and any spam-heavy folders you do not want appearing as new Gmail labels.

6. 6

   Add users and start the migration

   Enter source-to-destination user pairs, one at a time for a small team or via CSV upload for a larger one. Google's product matrix caps the built-in tool at about 1,000 users; above that, Google Workspace Migrate is the intended path.

7. 7

   Watch the job report

   The Data migration page tracks discovered, imported, skipped and failed counts per mailbox. Skipped and failed are the ones to open — that is where oversized messages, unsupported folder types, and IMAP timeouts show up in the log.

8. 8

   Re-run for delta as cutover approaches

   Once the initial pass completes, run the same job a day or two later. The tool re-reads the source and imports messages that arrived since. Repeat this delta cycle until you are ready to change MX.

9. 9

   Cut MX, then update SPF, DKIM and DMARC

   Point MX at Google only after the last delta run is clean. Add Google's SPF include, publish the Gmail DKIM selector from Admin console > Apps > Google Workspace > Gmail > Authenticate email, and republish DMARC once both are live.

What breaks during a Data Migration Service run#

The failure modes below cost more hours per incident than the actual migration does, and almost all of them come from a mismatch between what the source expects and what the built-in tool is built to do. None of these are exotic; every one shows up regularly in the Google Workspace admin community's DMS threads.

Rollback plan#

A DMS-based migration is close to fully reversible right up to the moment you flip MX — and, if you keep the source live, for a while after. That is the whole rollback strategy: do not decommission the source until you are certain.

• Before MX cutover: nothing to roll back. The source is still authoritative for mail delivery; the copy inside Gmail is a copy.
• Right after MX cutover: if delivery problems appear, point MX back at the source's mail servers. Propagation takes the same TTL-bound time it did going forward.
• Set the rollback trigger in advance — for example, more than a small handful of missing-mail reports in the first four hours — and name who has authority to call it before anyone is under pressure.
• Keep the source's mailboxes read-only but reachable for at least 30 days after cutover. A cancelled source subscription cannot be rolled back the way a DNS record can.
• Keep a copy of the source's DKIM selectors and SPF include lines somewhere findable outside DNS history. You will want them if you have to roll back inside a business day.

Doing it without downtime#

No downtime during an email migration really means no dropped mail during the hours DNS is propagating. A global MX change reaches every mail server on its own schedule, not yours, and the built-in Data Migration Service is a scheduled import, not a live sync — the two combine into a real cutover window unless you plan for it.

The pattern that gets closest to zero comes down to sequencing. Run the initial DMS pass while the source is still receiving new mail, then run delta passes at increasing frequency as cutover approaches, then flip MX only after the last delta has completed with no messages pending. During the propagation window itself, mail can arrive at either the source or the destination depending on which resolver a sending server used, so keep the source live and pulling for another 24 to 48 hours as a safety net.

One optional overlay: run a routing subdomain — something like migrate.yourdomain.com — with its own MX record pointed at Google Workspace, so you can test full end-to-end delivery through the new tenant before touching the root domain's MX at all. Send and receive a handful of real test messages through it first, one from a Gmail account, one from an Outlook account, one from your own root domain.

Then run one canary user through the entire sequence a day ahead of everyone else. It surfaces broken app passwords, stuck IMAP connections and folder-to-label surprises while the blast radius is one inbox rather than the whole company.

Where AI Emaily fits once the mail is in Gmail#

The Data Migration Service moves messages and labels. It does not rebuild your filters, your delegates, or any of the when-this-arrives-do-that behaviour you had on the source system — those are recreate-by-hand jobs on the Gmail side, and the reason a two-day migration project often turns into a two-week cleanup where everyone rebuilds their own filter chain.

AI Emaily is an AI-native email client that connects to Gmail and Google Workspace by OAuth after the migration is done, and picks up that recreate work automatically. Triage, labelling, drafting and follow-ups run against the freshly imported inbox using rules you describe in plain English, rather than filters you rebuild by hand under Settings. We build AI Emaily. Packaging is a 7-day free trial on Pro or Autopilot (card required, $0 if cancelled before day seven); current tiers are at aiemaily.com/pricing and the trial starts at aiemaily.com.

Honest concession: for a pure Exchange migration where calendar and contact data has to survive intact, a dedicated third-party platform such as BitTitan MigrationWiz does more than Google's built-in service does — and more than we do. That is a migration platform's job, not a mail client's. AI Emaily runs after the mail lands, not during the DNS cutover.