Mailbox and email migration
Every mailbox counted and sized first — user, shared, resource, and archive — then public folders, distribution groups, and mail-enabled security groups, then one agreed hour when autodiscover and the MX record move. One written fixed fee, scoped and priced before you commit.
Representative dashboard — sample data
What you get
A mailbox carries calendars, delegate rights, send-as permissions, mobile devices, and a decade of rules. The scoping work is a recipient-by-recipient count, because that count is what sets both the method and the price.
Primary mailboxes, archives, and the Recoverable Items folder are measured per user, not estimated in bulk. Mailbox count and total gigabytes are the two numbers that decide the migration method, the batch plan, and the fee — so they are established before anything is quoted.
info@, accounts@, the two meeting rooms, and the pool car all have owners somewhere. Each is listed, its delegates and full-access rights recorded, and its destination licensing confirmed — unlicensed shared mailboxes are capped at 50 GB in Exchange Online, which catches teams out.
Distribution groups, dynamic distribution groups, mail-enabled security groups, and mail contacts are inventoried with their membership and their managers. Where identities keep syncing from Active Directory, we agree upfront which side of the fence each group will be edited from after cutover.
Public folders migrate in their own batch after the mailboxes, with real limits attached. Oversized folders are split, dead hierarchies are archived instead of carried, and folders that were always a shared mailbox in disguise are converted rather than copied.
DNS is the part users feel. Record TTLs are lowered days ahead, the autodiscover and MX changes are staged in a written runbook against a named low-traffic hour, and a delta pass collects anything that arrived on the old server while the change propagated.
Most projects stall here, because the last server cannot simply be powered off while directory synchronisation is still running. The decommissioning route is chosen at scoping, written down, and finished — not left as a server nobody dares touch.
How it works
A free consultation plus a recipient report tells us how many user, shared, resource, and archive mailboxes exist, how large each one is, how many distribution and mail-enabled security groups are live, what sits in public folders, and which devices and applications relay mail through the server. You get a written scope, a method recommendation, one fixed price, and a cutover date.
Domains are verified, licensing is sized, identities are matched, and mail flow rules, connectors, and retention settings are rebuilt in Exchange Online. A pilot group moves end to end — mail, calendar, delegates, mobile, Outlook profile — so the runbook is corrected against real work before anyone else is touched.
Remaining mailboxes move in batches, public folders follow in their own batch, autodiscover and MX switch at the agreed hour, and a delta pass finishes the job. Then the part most projects skip: the on-premises Exchange organisation is decommissioned properly, documentation is handed over, and 30 days of hypercare begin.
Microsoft is unambiguous about it: “Support for Exchange Server 2019 and 2016 ended on October 14, 2025”, on its own end of support roadmap (opens in new tab). The product lifecycle entries for Exchange Server 2016 (opens in new tab) and Exchange Server 2019 (opens in new tab) record the same milestone. After it, Microsoft no longer ships technical support, bug fixes, security fixes, or even time zone updates for either version.
Nothing switched off, which is exactly why this drifts. Mail still arrives, Outlook still connects, and the only visible difference is that a server holding every contract, invoice, and HR conversation your company has had now accumulates unpatched vulnerabilities permanently. Mail servers are also the most reachable thing you own: they are published to the internet on purpose. That is the honest reason the assessment belongs in this quarter rather than next year.
Microsoft leaves two supported destinations. Move the mailboxes to Exchange Online in Microsoft 365, or stay on-premises by upgrading to Exchange Server Subscription Edition, which is a subscription-licensed product you still patch, host, and back up yourself. For most companies under a few hundred staff the second option means buying the same problem again with a newer version number, and this page is about the first.
The migration method is not a preference, and it is not something to decide after the project starts. Microsoft’s guidance on ways to migrate multiple email accounts (opens in new tab) keys the choice to two things: how many mailboxes you have, and whether user accounts stay managed on-premises. One point worth knowing before anyone quotes you a “staged migration”: staged migration applies only to Exchange 2003 and 2007 sources, so it is not on the table from a 2016 or 2019 organisation at all.
| Method | When it fits an Exchange 2016 or 2019 source | What it costs you in practice |
|---|---|---|
| Cutover migration | Fewer than 2,000 mailboxes and no requirement to keep managing accounts in Active Directory. Microsoft supports up to 2,000 but recommends 150 or fewer (opens in new tab) because of how long creating and moving that many users takes | Everyone moves together over a weekend. Outlook profiles are recreated and OST files redownload, so users need instructions and a hand on the Monday |
| Minimal hybrid (express) | A small organisation that wants directory objects matched and mailboxes moved in a couple of batches, without running a permanent coexistence setup | More preparation than cutover, far less than full hybrid, and the hybrid relationship is deliberately torn down once the last mailbox lands |
| Full hybrid (remote move) | More mailboxes than a weekend can carry, a long coexistence period, or accounts that stay mastered in Active Directory and sync with Entra Connect | The most capable and the most complex. It is the only native route that can also move mailboxes back on-premises if you need to reverse a move |
| IMAP or PST import | A fallback where the source cannot be connected properly, or where a departed user’s archive exists only as a PST file on a laptop | Mail only. Calendars, contacts, tasks, and permissions do not come across, and mailboxes must already exist in the tenant |
Full hybrid earns its complexity when coexistence has to be seamless. Microsoft’s documentation on Exchange Server hybrid deployments (opens in new tab) lists what you buy with it: free/busy visible across both sides, archive-only moves, cross-premises eDiscovery, Outlook on the web redirection, and mailbox moves that keep the mailbox GUID so nobody has to rebuild an Outlook profile. For a fifty-person company moving in one weekend, none of that is worth the setup. For a three-hundred-person company moving department by department over a month, all of it is.
This is the checklist we take into the assessment session. The right-hand column is the one that matters, because the rows marked as a rebuild are where the effort actually goes — and they are invisible in any quote priced purely per mailbox.
| On your Exchange server | Where it lands in Exchange Online | Decided before the first batch |
|---|---|---|
| User mailboxes | Cloud mailboxes with mail, calendar, contacts, rules, and folder permissions. Microsoft’s Exchange Online limits (opens in new tab) give 50 GB on Business Basic, Business Standard, Business Premium, and E1, and 100 GB on E3 and E5 | Which users exceed their destination quota today, and whether the answer is a bigger licence, an archive, or a genuine clear-out |
| Archive mailboxes | Online archives, with auto-expanding archiving growing to 1.5 TB on the plans that include it | Who genuinely needs an archive, and whether local PST files scattered across laptops should be swept into it during the project |
| Shared mailboxes | Shared mailboxes. No separate licence is required to have one, but Microsoft caps an unlicensed shared mailbox at 50 GB; going to 100 GB needs an Exchange Online Plan 2 licence assigned to it | Which shared mailboxes are over the cap, and which ones are really a distribution group or a Microsoft 365 group that grew sideways |
| Room and equipment mailboxes | Resource mailboxes with their booking policies, delegates, and capacity re-applied | Which rooms still exist in the building, and which booking rules were set once in 2017 and never reviewed |
| Distribution and dynamic distribution groups | Cloud distribution groups, or Microsoft 365 groups where the list is really a team that wants a shared inbox and files | Which lists are still used, who owns each one, and which side of the sync boundary they will be edited from afterwards |
| Mail-enabled security groups and mail contacts | Carried across as recipients, with membership intact. A cutover migration moves mail users, mail contacts, and mail-enabled groups along with the mailboxes | Whether the group grants permissions as well as receiving mail, because those two jobs often need separating on the way over |
| Public folders | Public folder mailboxes, via batch migration (opens in new tab) run after the user mailboxes. Microsoft supports a maximum of 100 target public folder mailboxes per migration, each up to 100 GB | Whether any single folder is over the 25 GB Microsoft advises splitting first, and which hierarchies should be archived rather than moved |
| Transport rules, connectors, and journaling | Rebuilt. Mail flow rules, accepted domains, remote domains, and send and receive connectors are configuration, not content, so nothing carries itself | Which disclaimers and routing rules are still required, and which exist only to work around a problem the move removes |
| Scanners, copiers, and applications that relay mail | Reconfigured against Microsoft’s mail flow options (opens in new tab) — authenticated submission, a connector from your public IP, or direct send | The full list of devices and line-of-business apps pointing at the old server. This is the single most common cause of “the migration broke something” three weeks later |
| Autodiscover, MX, SPF, DKIM, DMARC | Repointed at Microsoft 365. Autodiscover (opens in new tab) is what silently reconfigures Outlook and mobile clients, so it is sequenced before the MX change, not after | Every domain you own that receives mail — including the two nobody remembered — and the TTL on each record |
| The Exchange servers themselves | Decommissioned, but only once recipient management has a supported home. Microsoft’s guidance on decommissioning on-premises Exchange (opens in new tab) covers the routes | Whether Active Directory stays as the identity source, which decides whether a server, the management tools, or nothing at all remains |
This is the trap that turns a finished migration into a permanent chore. Microsoft states it plainly: if you migrate mailboxes to Microsoft 365 but keep using Microsoft Entra Connect (opens in new tab) to manage user accounts in Active Directory, you have to keep at least one Exchange server. Remove them all and you cannot change Exchange recipients in Exchange Online at all, because your on-premises Active Directory still holds the source of authority for those attributes.
So the plan is agreed at scoping rather than discovered afterwards. Where Active Directory is going away with the server, identities move to cloud-only and the whole organisation is removed. Where Active Directory stays — because of on-premises applications, file shares, or a domain-joined estate — there are supported ways to shut the last server down without losing recipient management, including Microsoft’s Exchange management tools route (opens in new tab) and transferring the source of authority to the cloud. Either way it is written into the scope with an owner and a date, which is the difference between a migration and an unfinished one.
The table below shows scope and typical timeline rather than prices, because an honest number needs the recipient inventory first — the same principle behind how our fixed-fee process works. Per-mailbox pricing is common in this market and it hides exactly the wrong things: it charges you the same for a 900 MB mailbox as a 90 GB one, and nothing at all for the public folders, the relay devices, and the decommissioning that make up most of the real work. We quote one written figure for the whole project instead, and the reasoning behind that is set out in fixed-fee versus hourly consulting.
| Phase | Scope | Typical timeline | Fee |
|---|---|---|---|
| Phase 1 — Recipient assessment and method choice | Per-mailbox inventory with sizes and archives; shared, room, and equipment mailboxes; distribution groups, mail-enabled security groups, and contacts; public folder sizing; relay device and application list; every mail domain and its DNS records; the cutover, minimal hybrid, or full hybrid recommendation, a batch plan, and a cutover date | About 1 week | Fixed fee — scoped after your free consultation |
| Phase 2 — Tenant preparation and pilot | Domains verified, licensing sized, identity matching and Entra Connect confirmed, mail flow rules and connectors rebuilt, retention and holds carried over; a pilot group migrated end to end with delegates, mobile devices, and Outlook profiles proven on real work | About 1 week | Fixed fee — scoped after your free consultation |
| Phase 3 — Batches, cutover, decommissioning, hypercare | Remaining mailboxes migrated in batches, public folders in their own batch, autodiscover and MX cutover at the agreed hour, delta pass, relay devices repointed, staff guidance, the on-premises Exchange organisation decommissioned to the agreed route, admin handover, then 30 days of included hypercare | 1–2 weeks, plus 30 days of hypercare | Fixed fee — scoped after your free consultation |
Everything lands in the tenant you own. Mailboxes, groups, mail flow configuration, the runbook, and admin access are yours throughout, so your team can carry on in-house the moment hypercare ends.
The usual fit is a US company of roughly 20 to 500 people running one Exchange Server 2016 or 2019 organisation that has quietly become the most exposed thing on the network — a few hundred mailboxes, a handful of shared inboxes finance depends on, a public folder tree from 2014, and a copier that emails scans to everyone. Often the trigger is a cyber-insurance questionnaire or a client security review asking, in writing, whether any unsupported server software is in scope. The work is delivered by senior US-based engineers from our Orange County, CA base and remotely across all US states.
If your mail is on Google rather than on your own Exchange server, the artifacts are completely different — Gmail labels, shared drives, and Google-linked apps rather than public folders and hybrid — and our Google Workspace to Microsoft 365 migration covers that path instead. If the mail is already in a Microsoft 365 tenant that GoDaddy sold and still controls the sign-in for, nothing needs to leave the cloud; our GoDaddy to Microsoft 365 migration services defederate that tenant and move the licensing to Microsoft direct or a CSP instead. Companies retiring a whole on-premises estate usually pair this with our SharePoint Server to SharePoint Online migration, since the same end-of-support conversation applies to the file and intranet workload. Once mail is in the tenant, a Microsoft 365 tenant security assessment is the sensible follow-on: Exchange Online Protection, multi-factor authentication, and mail flow policies are the controls your insurer will ask about next.
Related services
The same destination tenant from a different source: Gmail, Calendar, Drive, and shared drives moved without losing a day of email.
The other half of an on-premises retirement — site collections, content databases, workflows, and forms moved off the farm.
Once the mailboxes land, a written review of identity, mail flow, and sharing settings against what your insurer and clients now ask for.
Mailbox size, archiving, and compliance differ between the two plans — which matters the moment you size licensing for a migration.
The playbook for the other on-premises box in the cupboard: inventory, structure design, and a cutover that does not eat a weekend.
Why an hourly meter on a migration rewards the slowest possible migration, and what a written scope changes about that.
FAQ
Microsoft states that support for Exchange Server 2019 and 2016 ended on October 14, 2025, which means no security fixes, no bug fixes, and no technical support. The server keeps delivering mail, so nothing looks wrong. What has changed is that every new vulnerability in it now stays open permanently.
Mailbox count decides it. Microsoft supports cutover for up to 2,000 mailboxes but recommends 150 or fewer, so most small teams cut over in one weekend. Above that, or where accounts stay managed in Active Directory, a hybrid remote move migration lets mailboxes cross in batches.
They migrate, but in their own batch after the mailboxes. Microsoft supports batch migration from Exchange 2016 CU4 and later and from all Exchange 2019 builds, caps a migration at 100 target public folder mailboxes, and advises splitting any single folder larger than 25 GB first.
Not automatically. Microsoft warns that if you keep Entra Connect syncing accounts from Active Directory, removing every Exchange server leaves you unable to change Exchange recipients, because on-premises Active Directory still holds the source of authority. Decommissioning is planned deliberately, using the supported management tools or source-of-authority route.
No, if the sequence is right. Historical mail copies while the old server is still receiving, TTL on the MX record is lowered days ahead, the record is switched at an agreed low-traffic hour, and a delta pass sweeps up anything that landed mid-switch.
Typical delivery is two to four weeks from kickoff, with a pilot group of mailboxes first and the rest following in batches. The fee reflects mailbox count and sizes, shared and resource mailboxes, public folder volume, the number of mail domains, and the migration method. You approve one written price first.
Book a free consultation
Tell us what you’re trying to fix — a report, an approval process, an intranet, a Copilot rollout. We scope it as a fixed-fee project, you approve, and a senior engineer delivers in 2–4 weeks.
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.