Email migration services

A mailbox is not one object. It is messages, folder hierarchy, read and unread state, flags, calendar entries with organiser relationships, contacts, delegated access, forwarding rules and aliases. A migration that copies messages and nothing else technically succeeds and is still experienced by everyone using it as a failure, because the shape of their working day lives in the parts that were skipped.

We migrate all of it, and we tell you in advance which elements have no equivalent on the destination platform. Exchange public folders have no true Google counterpart. Gmail labels are not folders and collapse when written into a folder-based store. Those are mapping decisions you should make deliberately during discovery rather than discover in week two.

We quote per mailbox rather than per hour, because an hourly model charges you more for the messy estate you already have and gives us no reason to make discovery efficient. The per-mailbox figure covers discovery, the migration itself, both delta passes and thirty days of support after cutover.

Archive data beyond 50GB per user, litigation holds and bespoke integrations are quoted separately, because those genuinely vary between organisations. If discovery changes the scope we say so before starting the work rather than issuing a variation afterwards.

Authentication first, data second, MX last. We publish SPF, enable DKIM signing and set DMARC to a monitoring policy on the destination platform while the old system is still live and authoritative. Then mail is pre-synced in full, which is the long part and the part nobody notices. Only then does the MX record change, which is the moment people think of as the migration and which usually takes under an hour to propagate.

Because mail is pre-synced, the cutover window is a DNS change and a queue drain rather than a data transfer. Senders whose mail arrives mid-change retry automatically under standard SMTP behaviour, so nothing bounces.

The week after cutover produces more support volume than the migration itself. Mobile devices need reprofiling, a handful of desktop clients stay bound to the old server until they are repointed, and somebody always remembers a shared mailbox that was never mentioned in discovery. Thirty days of support is included so that week does not turn into a new commercial conversation.

After that most clients either move onto a managed support retainer or take the written runbook and handle it internally. Both outcomes are fine, and the runbook is yours either way.