Google Workspace IMAP Import Goes GA: Migration Guide

Google Workspace's IMAP import feature reached general availability in September 2026, letting admins pull historical email from any IMAP-based provider directly during Workspace setup, according to Google's GA announcement. The feature only migrates email. It does not move calendar events, contacts, or Drive files, so a full tenant migration still needs separate tooling and a plan for the parts this feature does not touch.

For anyone running a client off an old mail provider and onto Google Workspace, that distinction matters more than the GA announcement itself. Here is what shipped, what it actually covers, and how to scope the rest of the migration so nothing falls through the gap.

What Is Google Workspace's New IMAP Import Feature?

The new IMAP import option lives inside the Workspace setup flow itself, not the admin console's separate migration tools. Once a domain is verified and email activated, an admin can connect to any IMAP server, including Hostinger, Zoho, Yahoo!, and iCloud among others, by entering the IMAP address and password. The import then runs in the background while the rest of setup continues.

Google frames this as a way to cut the time and effort of switching providers, and for a straightforward mail-only move from a generic IMAP host, it does exactly that. There's no third-party connector to buy or configure, and it's available to all Google Workspace customers on both Rapid Release and Scheduled Release domains.

What Does the New IMAP Import Actually Migrate?

Just email. The GA announcement describes importing "past emails" from the source IMAP mailbox, and nothing in the feature description mentions calendar events, contacts, or files. It also imports one user's mailbox per flow; moving multiple accounts means repeating the process per user or following Google's separate Help Center guidance for bulk IMAP imports.

That narrow scope is the whole story for integration teams. If a client's migration brief says "move us to Google Workspace," the new setup-flow IMAP import handles one slice of one system. Everything else on the tenant, calendar history, contact lists, shared drives, custom scripts tied to the old mail system, is still the integration team's job to plan and execute.

How Is This Different From the Admin Console's Data Import Tool?

Google already has a broader migration tool called Data import, reachable from the admin console rather than the setup wizard, and it's a different product with a different scope. That tool, generally available since April 2026, migrates emails, calendars, and contacts from sources like Exchange Online, and it requires super admin access to run.

Google later extended the same admin console Data import tool to cover file migrations too: Data import for Microsoft OneDrive reached GA in August 2026, moving files along with their sharing permissions, with a migration planning utility to estimate timelines and data volume first.

So Workspace migrations now split across at least three distinct tools, each with its own scope:

Tool	Where it runs	What it moves	Who can run it
IMAP import (new, GA Sept 2026)	Workspace setup wizard	Email only, one mailbox at a time	Any admin during setup
Data import (GA April 2026)	Admin console	Email, calendar, contacts	Super admin
Data import for OneDrive (GA Aug 2026)	Admin console	Files and permissions	Super admin

None of these three tools cover Google Chat history, third-party app data, or anything living in custom modules bolted onto the old mail or CRM platform. That's where a migration plan built on "we'll use the built-in import" quietly runs out of coverage.

Each tool also has its own rollout and access model. The Data import tool for OneDrive explicitly requires no additional infrastructure or third-party licensing cost, and ships with a migration planning utility for estimating data volume and timeline before the cutover starts. The original April 2026 Data import tool for email, calendar, and contacts carries the same no-extra-cost framing. The new IMAP import sits apart from both: it's bundled into setup, has no separate planning utility, and is scoped to run per mailbox rather than as a bulk administrative job.

What This Means for ISVs and Platforms Building Onboarding Flows

If your product's onboarding flow assumes a customer is coming from Gmail, Exchange, or a specific named provider, the new IMAP import GA is worth testing against. Because it accepts any IMAP-based provider, including smaller consumer hosts like iCloud and Yahoo!, it widens the pool of customers who can self-serve their email history into Workspace without your product needing to build or maintain its own IMAP-pulling connector.

That's a genuine scope reduction for an ISV's own migration tooling, but only for the mail piece. If your platform also needs the customer's contacts (for a CRM sync, for example) or calendar data (for a scheduling integration), you still need your own path to that data, because Google's setup-flow import won't surface it to your API. Plan the data you actually need per customer record, not per mailbox.

What Still Needs a Separate Migration Plan?

Three categories consistently get missed when a client assumes the built-in import tools are the whole migration:

Calendar and contacts, if migrating from a raw IMAP host. The new setup-flow IMAP import does not touch these. If the source is a generic IMAP provider rather than Exchange, there's no first-party Google tool that pulls calendar and contact data from it, which means either a manual export/import via standard formats (iCal, vCard) or a third-party connector built for the specific source.

Shared drives and file structures. Data import for OneDrive covers Microsoft's ecosystem specifically. A client moving off a different file store, a self-hosted NAS, Box, or a legacy document management system tied into their old CRM, needs a dedicated file migration plan, with permissions mapping as the hardest part to get right.

Anything wired into custom modules. This is the piece vendor migration tools never claim to solve, and it's usually the real reason a client hired an integration partner in the first place. If the old mail or file system triggers downstream automations (ticket routing, approval emails, document generation), those integration points need to be rebuilt against Workspace's APIs, not just pointed at a new mailbox.

How Should Integration Teams Scope a Workspace Migration Project Now?

Treat the IMAP import GA as a scope reduction, not a scope elimination. It removes the need to write or buy a custom email-pulling script for IMAP-based sources, which used to be a real line item on Workspace migration projects. That's a genuine time save on any client coming from a smaller IMAP-based provider.

But the project plan still needs explicit line items for:

1. Calendar and contact migration, sourced and scheduled separately from the mail import.
2. File and shared drive migration, scoped to whatever the client's actual file system is (OneDrive has a first-party path now; most others don't).
3. Any custom integration currently wired to the old platform: webhook triggers, email-to-ticket automations, or workflow tools that assumed the old inbox existed.
4. Admin access provisioning during the cutover window. Google also shipped temporary administrator roles with automatic expiration in the same September 25 update cycle, which is a genuinely useful fit here: grant a migration contractor super admin access for the exact window they need it, and have it revoke itself. fluidlabs covered the mechanics of that feature for integration work in Google Workspace Temporary Admin Roles for Integrations.

Writing the scope this explicitly protects both sides of the engagement. Clients stop assuming "Google will migrate everything" because one feature got announced, and the integration team has a clean list to quote against instead of discovering gaps mid-project.

Frequently Asked Questions

Does the new Google Workspace IMAP import feature migrate calendar and contacts? No. The feature only imports past email from the connected IMAP server. Calendar and contacts need a separate tool or manual export, depending on the source platform.

Can I use the new IMAP import to migrate multiple users at once? Not through the setup-flow version. Google's announcement describes importing one user's mailbox per flow; bulk multi-account imports follow a separate, Help Center-documented process.

Is this the same as the Google Workspace Data import tool in the admin console? No. The admin console's Data import tool, GA since April 2026, is a separate, broader tool that moves email, calendar, and contacts and requires super admin access. The new IMAP import runs inside the setup wizard itself and covers email only.

Does Google have a first-party tool for migrating files into Workspace? Yes, but scoped to Microsoft: Data import for OneDrive reached GA in August 2026 and moves files along with sharing permissions. Other file sources need a separate migration plan.

The Takeaway

IMAP import going GA is a real, useful change for one specific case: email-only moves from a generic IMAP-based provider. It shortens the Workspace migration checklist by removing a script that used to need custom building. It does not shorten the checklist for calendar, contacts, shared files, or anything wired into a client's custom systems, and treating it as a full migration solution is how projects end up with a client discovering a missing piece of their inbox history two weeks after go-live.

If you're scoping a Google Workspace migration that touches more than mailboxes, especially one where the old platform feeds custom modules or downstream automations, fluidlabs builds and runs the integration work that first-party import tools don't cover. Book a working session with the team to map out what the built-in tools handle and what still needs custom integration work, or browse more on fluidlabs' resources page for related platform-change breakdowns.