Migration

Moving to Microsoft 365 without losing a morning

Four ways businesses arrive here: Google Workspace, a Microsoft tenant somebody else set up, mail bundled with web hosting, or an Exchange server in a cupboard. Each has a different method and the same aim — keep your data intact and nobody locked out for a day.

The honest downtime answer

You will not lose mail. You may briefly receive it in two places.

We keep the old system accepting mail while the new one comes up, so nothing bounces. Once we change your MX record, the internet takes time to notice — typically under an hour for most senders, but up to 24–48 hours for the slowest, because that is how DNS caching works and no provider can shorten it. During that window some mail arrives at the old system and some at the new one; we keep both running and reconcile at the end. The switch itself is scheduled with you, usually outside business hours.

Where you are moving from

The method changes; the plan price does not. Migration is part of onboarding on every plan.

From Google Workspace

The most common move we do. Gmail, Drive, and Calendar come across; the habits take a week to follow.

What moves

Mail, including folders — Gmail labels become Outlook folders, and nested labels become nested folders.
Calendars, including recurring events and the meeting rooms you have defined.
Contacts, both personal and shared directory entries.
Google Drive and Shared Drive files into OneDrive and SharePoint, with the folder structure preserved.
Groups and distribution lists, rebuilt as Microsoft 365 groups or shared mailboxes.

What does not, or needs rebuilding

Google Docs, Sheets, and Slides convert to Word, Excel, and PowerPoint. Most convert cleanly; heavily scripted Sheets and complex Docs formatting need checking, and we flag those before the move.
Apps Script automations have no Microsoft equivalent — we rebuild the ones you rely on as Azure workflows.
Google Vault holds and Chat history do not transfer; if you need them, keep the Workspace subscription for the retention period.

What cutover looks like

1We provision the Microsoft tenant and verify your domain while Google is still live and untouched.
2We run a first full mail and file sync in the background. Nobody notices; nothing changes.
3We switch the MX record on an agreed evening, then run a delta sync to pick up anything that arrived during the switch.
4Everyone signs in to Outlook the next morning. Your Workspace subscription is yours — we'll tell you when everything has arrived so you can cancel it with confidence.

Expected downtime

Mailboxes stay reachable through the switch. The only real window is DNS: after we change your MX record, most senders reach the new mailbox within an hour, but the slowest caches can take up to 24–48 hours. We keep Google accepting mail throughout and sync anything that lands there.

What we need from you

Google Workspace super-admin credentials, or an admin willing to sit with us for the setup.
Access to your DNS, or someone available to change one record while we are on the call.
A list of shared drives and who should be able to reach each one.
A decision on which Docs and Sheets are business-critical, so we test those conversions first.

From An existing or retail Microsoft 365 tenant

You already have Microsoft 365, bought direct or set up by someone who has since disappeared. Nothing moves — we take it over and fix it.

What moves

Nothing has to migrate at all. Your mail, files, and tenant stay exactly where they are.
What changes is management: we take a proper look at the tenant and put right what was never set up.
Where a second tenant exists from a merger or an old brand, we consolidate mailboxes and sites into one.

What does not, or needs rebuilding

Your subscription stays in your own name on your own payment method. Nothing about your billing relationship with Microsoft changes.
Existing licences are not reissued. If you are on the wrong tier we tell you, and you change it yourself in your own admin center.

What cutover looks like

1We run an audit of the tenant as it stands: mail delivery records, permissions, shared access, admin accounts, and anything a previous provider left behind.
2You consent to a named ID360 application in your own admin center, revocable by you at any time. Its Microsoft Graph permissions are tenant-wide rather than confined to the mailboxes and sites you nominate — the terms set out exactly how wide, and how to narrow the Exchange half from your own tenant.
3We hand you the audit findings before we change anything, including anything we think is a genuine risk.
4We fix what we agreed, then start building your automations. Nobody has to sign in differently.

Expected downtime

None expected — there is no mail cutover, because mail is already where it is going to be. Anything we change that could interrupt people — a permission model, a conditional access policy — is scheduled with you and rolled out gradually.

What we need from you

A global administrator in your business who can grant that consent.
The name of whoever set the tenant up, if you know it, and any account they still hold.
Access to your DNS, so we can correct mail delivery records if they are wrong.
A list of anything that has been quietly broken, however small.

From IMAP, cPanel, or your web host's mail

Mail bundled with your website hosting. It works until it does not — and it usually has no calendar, no backup, and a mailbox quota from 2011.

What moves

Mail, folder by folder, over IMAP — including everything sitting in Sent and Archive.
Address books, where the host exposes them in a usable format.
Aliases and forwarders, rebuilt as proper shared mailboxes and distribution groups.

What does not, or needs rebuilding

Calendars and contacts, in most cases: cPanel-style mail rarely stores them centrally, so they usually live in each person's mail client and we export them per machine.
Server-side filters and vacation rules — we rebuild these as Outlook rules.
Webmail settings, signatures, and folder colours. Each person sets those up again once.

What cutover looks like

1We collect a mailbox list and either an admin login or each person's password — IMAP has no delegated access, so one of the two is unavoidable.
2We sync every mailbox into Microsoft 365 in the background while the old mail keeps running.
3We change the MX record on an agreed evening and run a delta sync afterwards to catch anything that arrived mid-switch.
4Once everything has arrived, we help you turn the hosting mailbox off and reclaim the storage — on your decision, not a clock.

Expected downtime

No mailbox goes offline, but this is the path where DNS matters most, because host mail is often on a long TTL. We lower the TTL a few days beforehand where we can. Expect most mail to arrive at the new mailbox within an hour of the switch, with stragglers on the old system for up to 24–48 hours — we sync those across.

What we need from you

A full list of every mailbox, alias, and forwarder — including the ones nobody uses but everybody would miss.
IMAP server details and either an admin account or per-mailbox passwords.
Access to DNS, which for hosted mail is often at the same provider.
A warning if any mailbox is close to its quota; nearly full mailboxes sync slowest.

From On-premises Exchange

A physical Exchange server in a cupboard. Moving off it is the biggest of these jobs and the one that most reliably pays for itself.

What moves

Mailboxes, calendars, contacts, and tasks, with the folder structure intact.
Public folders, either as-is or reshaped into shared mailboxes and SharePoint libraries — usually the better answer.
Distribution groups and mail-enabled security groups.
File shares alongside the mail, into SharePoint and OneDrive, where you want that done at the same time.

What does not, or needs rebuilding

Transport rules and custom connectors are rebuilt rather than copied — Exchange Online expresses them differently.
Anything that relies on a server on your network, such as a scanner or line-of-business app that sends mail through it, needs reconfiguring. We inventory these first, because they are the usual cause of a nasty surprise.
Third-party archive and journaling products need their own extraction; we scope this separately.

What cutover looks like

1We inventory the server first: mailbox sizes, public folders, transport rules, and every device or application that relays mail through it.
2For a larger team we run a hybrid configuration, so mailboxes move in batches with mail flowing correctly between the moved and the not-yet-moved.
3Smaller teams move in one weekend cutover instead — simpler, and cheaper, when the mailbox count allows.
4We reconfigure the scanners, apps, and relays, then decommission the server once you have run a full month without it.

Expected downtime

Each mailbox is unavailable only for the final few minutes of its own move, and users are told when their slot is. The DNS window is the same as every other path: most senders switch within the hour, the slowest within 24–48 hours. Hybrid exists precisely so a large mailbox count does not turn that into a long weekend.

What we need from you

Administrative access to the Exchange server and to Active Directory.
Mailbox sizes and counts, so we can size the batches and be honest about elapsed time.
A list of every device and application that sends mail through the server — printers, scanners, accounting software, the alarm system.
Access to DNS, and a maintenance window agreed in advance.

Migration timings above are what these jobs typically look like, not a contractual commitment. Mailbox count, mailbox size, and your current provider's throttling all move the elapsed time — we give you a specific estimate after the inventory, on the setup call, before you commit to anything. See the first week in full.

How it works Browse automations What we manage in each app Which licence do I need?

Tell us where your mail lives now

Twenty minutes on a call and we'll tell you the method, the realistic timeline, and the one thing most likely to be awkward about your particular setup.

Book a call

You will not lose mail. You may briefly receive it in two places.

Where you are moving from

The method changes; the plan price does not. Migration is part of onboarding on every plan.

From Google Workspace

The most common move we do. Gmail, Drive, and Calendar come across; the habits take a week to follow.

What moves

Mail, including folders — Gmail labels become Outlook folders, and nested labels become nested folders.
Calendars, including recurring events and the meeting rooms you have defined.
Contacts, both personal and shared directory entries.
Google Drive and Shared Drive files into OneDrive and SharePoint, with the folder structure preserved.
Groups and distribution lists, rebuilt as Microsoft 365 groups or shared mailboxes.

What does not, or needs rebuilding

Google Docs, Sheets, and Slides convert to Word, Excel, and PowerPoint. Most convert cleanly; heavily scripted Sheets and complex Docs formatting need checking, and we flag those before the move.
Apps Script automations have no Microsoft equivalent — we rebuild the ones you rely on as Azure workflows.
Google Vault holds and Chat history do not transfer; if you need them, keep the Workspace subscription for the retention period.

What cutover looks like

1We provision the Microsoft tenant and verify your domain while Google is still live and untouched.
2We run a first full mail and file sync in the background. Nobody notices; nothing changes.
3We switch the MX record on an agreed evening, then run a delta sync to pick up anything that arrived during the switch.
4Everyone signs in to Outlook the next morning. Your Workspace subscription is yours — we'll tell you when everything has arrived so you can cancel it with confidence.

Expected downtime

What we need from you

Google Workspace super-admin credentials, or an admin willing to sit with us for the setup.
Access to your DNS, or someone available to change one record while we are on the call.
A list of shared drives and who should be able to reach each one.
A decision on which Docs and Sheets are business-critical, so we test those conversions first.

From An existing or retail Microsoft 365 tenant

You already have Microsoft 365, bought direct or set up by someone who has since disappeared. Nothing moves — we take it over and fix it.

What moves

Nothing has to migrate at all. Your mail, files, and tenant stay exactly where they are.
What changes is management: we take a proper look at the tenant and put right what was never set up.
Where a second tenant exists from a merger or an old brand, we consolidate mailboxes and sites into one.

What does not, or needs rebuilding

Your subscription stays in your own name on your own payment method. Nothing about your billing relationship with Microsoft changes.
Existing licences are not reissued. If you are on the wrong tier we tell you, and you change it yourself in your own admin center.

What cutover looks like

1We run an audit of the tenant as it stands: mail delivery records, permissions, shared access, admin accounts, and anything a previous provider left behind.
2You consent to a named ID360 application in your own admin center, revocable by you at any time. Its Microsoft Graph permissions are tenant-wide rather than confined to the mailboxes and sites you nominate — the terms set out exactly how wide, and how to narrow the Exchange half from your own tenant.
3We hand you the audit findings before we change anything, including anything we think is a genuine risk.
4We fix what we agreed, then start building your automations. Nobody has to sign in differently.

Expected downtime

What we need from you

A global administrator in your business who can grant that consent.
The name of whoever set the tenant up, if you know it, and any account they still hold.
Access to your DNS, so we can correct mail delivery records if they are wrong.
A list of anything that has been quietly broken, however small.

From IMAP, cPanel, or your web host's mail

Mail bundled with your website hosting. It works until it does not — and it usually has no calendar, no backup, and a mailbox quota from 2011.

What moves

Mail, folder by folder, over IMAP — including everything sitting in Sent and Archive.
Address books, where the host exposes them in a usable format.
Aliases and forwarders, rebuilt as proper shared mailboxes and distribution groups.

What does not, or needs rebuilding

Calendars and contacts, in most cases: cPanel-style mail rarely stores them centrally, so they usually live in each person's mail client and we export them per machine.
Server-side filters and vacation rules — we rebuild these as Outlook rules.
Webmail settings, signatures, and folder colours. Each person sets those up again once.

What cutover looks like

1We collect a mailbox list and either an admin login or each person's password — IMAP has no delegated access, so one of the two is unavoidable.
2We sync every mailbox into Microsoft 365 in the background while the old mail keeps running.
3We change the MX record on an agreed evening and run a delta sync afterwards to catch anything that arrived mid-switch.
4Once everything has arrived, we help you turn the hosting mailbox off and reclaim the storage — on your decision, not a clock.

Expected downtime

What we need from you

A full list of every mailbox, alias, and forwarder — including the ones nobody uses but everybody would miss.
IMAP server details and either an admin account or per-mailbox passwords.
Access to DNS, which for hosted mail is often at the same provider.
A warning if any mailbox is close to its quota; nearly full mailboxes sync slowest.

From On-premises Exchange

A physical Exchange server in a cupboard. Moving off it is the biggest of these jobs and the one that most reliably pays for itself.

What moves

Mailboxes, calendars, contacts, and tasks, with the folder structure intact.
Public folders, either as-is or reshaped into shared mailboxes and SharePoint libraries — usually the better answer.
Distribution groups and mail-enabled security groups.
File shares alongside the mail, into SharePoint and OneDrive, where you want that done at the same time.

What does not, or needs rebuilding

Transport rules and custom connectors are rebuilt rather than copied — Exchange Online expresses them differently.
Anything that relies on a server on your network, such as a scanner or line-of-business app that sends mail through it, needs reconfiguring. We inventory these first, because they are the usual cause of a nasty surprise.
Third-party archive and journaling products need their own extraction; we scope this separately.

What cutover looks like

1We inventory the server first: mailbox sizes, public folders, transport rules, and every device or application that relays mail through it.
2For a larger team we run a hybrid configuration, so mailboxes move in batches with mail flowing correctly between the moved and the not-yet-moved.
3Smaller teams move in one weekend cutover instead — simpler, and cheaper, when the mailbox count allows.
4We reconfigure the scanners, apps, and relays, then decommission the server once you have run a full month without it.

Expected downtime

What we need from you

Administrative access to the Exchange server and to Active Directory.
Mailbox sizes and counts, so we can size the batches and be honest about elapsed time.
A list of every device and application that sends mail through the server — printers, scanners, accounting software, the alarm system.
Access to DNS, and a maintenance window agreed in advance.