Google Workspace migration services

A migration is four separate data sets that happen to move at the same time: mail, files, calendars and directory. Mail is the easiest because it is append-only. Files are harder because permissions are a graph rather than a list, and the graph rarely matches the org chart anyone will show you. Calendars break in specific, predictable ways around recurring events and room resources. The directory is where the project either lands cleanly or generates six months of low-grade support tickets.

We sequence the work so the risky parts happen before anyone depends on the new tenant. Directory and domain verification first, then a full mail pre-sync while the old platform is still live and authoritative, then Drive with permissions mapped, then the cutover itself, which is mostly an MX record change and a queue drain.

We quote per mailbox rather than per hour because the hourly model punishes you for the messy tenant you already have. The per-mailbox figure covers discovery, the migration itself, both delta passes and 30 days of post-cutover support. Archive data beyond 50GB per user, litigation holds and bespoke third-party integrations are quoted separately, because those genuinely vary.

A 50-seat migration at £95 per mailbox is £4,750. That is the number on the proposal and the number on the invoice. If discovery reveals something that changes the scope, we tell you before the work starts, not in a variation order afterwards.

Three things account for most of the pain in a badly run migration. First, permissions that were never audited: a finance folder shared with an entire domain moves across intact unless someone catches it. Second, recurring calendar events created by people who have since left, which lose their organiser and quietly stop updating. Third, mail rules and forwards that silently keep routing to the old platform after cutover.

Each of those is cheap to find before the move and expensive to unpick afterwards. Discovery produces a written list of every domain-wide share, every orphaned recurring event and every forward rule, and you decide what happens to each one while the old system is still running.

The first week after a migration generates more support volume than the migration itself. Mobile devices need reprofiling, a handful of users will have desktop clients still bound to the old server, and someone always discovers a shared drive they forgot to mention. Thirty days of support is included so that week is covered without a new commercial conversation.

After that, most clients move onto a managed support retainer or handle it internally with an admin runbook we hand over. Both are fine. The runbook is yours either way, written in plain English rather than as a console screenshot dump.