Google Workspace Migration

For a team under 20 users moving from a single source, one to two weeks is typical, and the limiting factor is usually finding a cutover window rather than the data itself. Between 20 and 100 users it is more often two to four weeks. Larger organisations with multiple source systems run in phases over four to eight weeks. On-premise Exchange and heavy shared-folder estates are scoped individually, because mailbox sizes and the length of the coexistence period decide the answer more than headcount does.

Not if the cutover is planned properly. Your existing system stays fully live while data is copied across, so nothing depends on a single switchover moment. The DNS time-to-live is lowered days beforehand so the MX change propagates quickly, and forwarding or dual delivery is kept in place until the old server genuinely stops receiving. Mail that arrives during propagation is delivered, not bounced, and a final delta sync after the switch catches anything still in transit.

Mail, contacts, calendars and files move. File sharing permissions move partially — explicit shares usually carry, but permissions inherited from an old folder tree often do not. Distribution lists, aliases and shared mailboxes are rebuilt rather than copied, because Google has no direct equivalent for some of them. Server-side rules, filters and signatures generally do not transfer, and in practice people recreate the handful they genuinely use.

Yes. The bulk of the data is copied while the old system is still running normally, so there is no period where the business is offline waiting. The only moment that needs coordinating is the MX switch itself, which is scheduled for a quiet window and takes effect over a few hours rather than instantly.

Yes, and it matters more than most people expect. The technical migration can be flawless and still be judged a failure if users arrive on Monday to an interface they were not warned about, a signature that has changed and no idea where the shared folder went. A short, role-specific briefing at cutover prevents most of the support load that follows.

If it sits in a mailbox or an exportable file it comes across with everything else. A dedicated journaling or compliance archive is a different matter — those usually need their own export and are scoped separately, and the retention requirement behind them may also decide which Google Workspace edition you need.

Because it is the most commonly missed step in a Google Workspace migration. DKIM signing is not switched on by default — the key has to be generated in the Admin console and published in your DNS deliberately. Skip it and your mail is authenticated more weakly than it was before you moved, which tends to show up as deliverability problems a week or two after cutover when everyone has stopped watching.

Usually, yes. Most business mail systems can export over IMAP or a standard file format, and that is what a migration actually depends on. What we would not do is quote a fixed scope for an unfamiliar platform without first confirming how the data comes out of it — so that verification happens during discovery, before you commit to anything.

It is worth asking, and the honest answer is sometimes not everything. Migrating fifteen years of mail that nobody will ever open costs storage and can push you to a higher edition for no benefit. A common middle path is to bring across a defined period in full, archive the rest in an accessible form, and keep the old system read-only for a while. That decision belongs at discovery, because it affects the edition you buy.

It is scoped on volume, source platform and how much has to be preserved — a dozen mailboxes off cPanel is a different job from 200 users and fifteen years of shared folders off Microsoft 365. We quote it as an explicit line alongside the licences rather than folding it into a rate, so you can see what each part costs. The requirement call and the quote are free.