We've been running Microsoft infrastructure projects since 2010 — mail migrations, directory consolidations, virtualization programs, the occasional rescue job. Six years in, we keep having the same conversations with new clients, and we keep re-learning the same lessons on new engagements. So we're going to start writing them down, roughly once a month: what we're working on, what broke, what we'd do differently. No product pitches, no vendor slideware. Field notes.
First up, because it's what's consuming most of our calendar right now: the assessment phase of an Office 365 migration for a state government agency. Roughly 15,000 mailboxes on Exchange 2010, spread across two datacenters, with a directory that has accumulated fifteen years of decisions. The Exchange 2010 to Office 365 path is well-trodden by now — hybrid configuration, remote mailbox moves, the Mailbox Replication Service doing the heavy lifting — but the migration tooling is honestly the easy part. The assessment is where migrations are won or lost, and this post is about what a real Office 365 migration assessment looks like when the number of mailboxes has three zeroes on the end.
If you take one thing from this post, take this: nobody on the client side fully knows their own estate. Not because they're bad at their jobs — because estates this size outlive the people who built them. The assessment exists to replace institutional memory with data.
The estate nobody fully knew
On paper, the environment was tidy: Exchange 2010 SP3 with a current rollup, eleven mailbox servers in two DAGs, CAS arrays in front, about 15,000 user mailboxes plus a few hundred shared and resource mailboxes. On paper.
Two weeks of discovery later, the real picture included: 1,900 mailboxes belonging to accounts disabled more than a year ago (litigation hold policies meant nobody dared delete them); 340 mailboxes over 25 GB, several over 80 GB, mostly belonging to people with "director" in their title; public folders — 600 GB of them, last meaningfully reorganized around 2009; and 47 applications, scanners, and appliances relaying SMTP through the Exchange servers, of which the client's own documentation listed nine.
None of this blocks a migration. All of it changes the plan. The 80 GB mailboxes need archive-first treatment or they'll blow the move windows. The relay inventory determines what has to stay on-premises (an Exchange hybrid server for relay and management is a near-certainty here). The disabled-but-held mailboxes are a licensing conversation, because in Office 365 an inactive mailbox behaves differently than a disabled AD account with a live mailbox, and the legal team needs to sign off on the difference.
Mailbox statistics: the census before the move
The first deliverable of any assessment we run is a mailbox census. Not a summary — a full per-mailbox export that we can slice for the next three months. On Exchange 2010 this is unglamorous PowerShell:
Get-Mailbox -ResultSize Unlimited |
Get-MailboxStatistics |
Select DisplayName, TotalItemSize, ItemCount,
LastLogonTime, DatabaseName |
Export-Csv -Path C:\Assess\mailbox-stats.csv -NoTypeInformation
Add Get-MailboxFolderStatistics for the outliers, and dumpster sizes for anything on hold, because the Recoverable Items folder moves too and people forget it exists. We also pull Get-CASMailbox to find every mailbox with POP or IMAP enabled — each one is a client-remediation ticket waiting to happen — and message tracking logs for 30 days to build the real mail flow picture, as opposed to the Visio from 2012.
From the census you derive the two numbers that drive the entire project schedule: total data volume and migration velocity. This estate: roughly 26 TB of primary mailbox data, average mailbox around 1.7 GB, with a long tail of monsters. At a realistic sustained move rate — and we plan on measured pilot throughput, never on theory — you're looking at months of data movement, not weeks. Which brings us to the math everyone avoids.
The network egress math nobody wants to do
Office 365 mailbox moves are onboarding pulls: the Mailbox Replication Service in Exchange Online reaches back to your hybrid endpoint over HTTPS and drags the data up. That means your internet egress, your firewall, and any proxy or IDS in the path are all part of the migration infrastructure, whether they were invited or not.
The arithmetic is simple and merciless. This client has a 500 Mbps internet connection shared with, well, the internet needs of 15,000 government employees. Assume we can responsibly consume 200 Mbps of it during business hours and more overnight. At 200 Mbps sustained, you move roughly 2 TB per day in theory; in practice, MRS throttling, mailbox item pathology (100,000 tiny items move far slower than one large PST-shaped blob), and change windows cut that in half or worse. Call it 1 TB a day on a good day. Twenty-six terabytes is now a minimum of a month of continuous, saturated data movement — before you schedule a single cutover batch, before rerouting around the inevitable bad weeks.
So the assessment produces a velocity model: mailboxes per week, batched by size band and by department (because cutover comms are per-department, not per-terabyte). For this agency we're modeling 700–900 mailboxes per week at steady state, which puts data migration at roughly five months. Anyone who quotes you a 15,000-seat migration in six weeks has either done the math wrong or is planning to do it to you, not with you.
One more egress note: check whether your outbound path does SSL inspection. MRS traffic through an inspecting proxy is a reliable source of mysterious, intermittent move failures. Get the Office 365 endpoints excluded now, in writing, from whoever owns the proxy.
ADFS and the identity dependency map
This client requires federated authentication — password synchronization alone wasn't acceptable to their security office, so ADFS 3.0 on Windows Server 2012 R2 with Web Application Proxy in the DMZ is part of the design, alongside Azure AD Connect for directory synchronization. We'll write up the ADFS build separately (it deserves its own post; multi-domain federation has sharp edges). What belongs in the assessment is the dependency mapping.
Directory synchronization is brutally honest about your Active Directory. IdFix run against this forest returned about 3,200 objects with errors: non-routable UPN suffixes (.local, naturally), duplicate proxyAddresses from a decade-old merger, illegal characters in attributes that nobody had looked at since Windows 2000. Every one of those is remediation work that must finish before the first mailbox moves, because a mailbox whose object won't sync is a mailbox that can't migrate.
The assessment also has to answer: what happens to every application when identity moves? We inventory everything that authenticates against Exchange or AD — the ERP that sends mail via EWS, the MFP fleet doing scan-to-mail, the two line-of-business apps doing LDAP lookups against a CAS server for reasons lost to history. Each gets a disposition: reconfigure, replatform, or retire. Finding these in month one costs a spreadsheet row. Finding them the morning after cutover costs a war room.
Why the assessment deck matters more than the migration tool
Here's the opinion part. The industry talks endlessly about migration tools — native hybrid moves versus third-party movers, throughput benchmarks, feature matrices. Tools matter at the margins. What actually determines whether a 15,000-mailbox migration lands on schedule is the assessment deck: the document where scope, sequencing, velocity, risks, and exclusions are written down and signed.
Our assessment deliverable for this agency runs about sixty pages and every page earns its place: the mailbox census summary and outlier registry; the velocity model with its assumptions stated (so when reality differs, we argue about assumptions, not blame); the identity remediation backlog with owners and dates; the relay and application inventory; the public folder disposition (short version: shrink ruthlessly before you even think about moving them); and the explicit not-in-scope list, which prevents more project failures than any technology decision.
The deck is also the political instrument. A government migration has stakeholders who will never read a PowerShell transcript but will absolutely read the page that says their department cuts over in March. Getting that page agreed in July is the whole game.
Exchange 2010 estates are aging. Mainstream support ended last year, and every quarter an organization stays put, the move gets harder, not easier. But the answer to "we need to get to Office 365" is not to download a tool. It's to spend four to six weeks measuring what you actually have. The tool works fine. It's the estate that surprises you.
If you're facing this
If you're staring down an Exchange 2010 estate and an Office 365 mandate — whether it's 500 mailboxes or 15,000 — the assessment phase is where we can save you the most pain, and it's the part most often skipped. We've done this at government and enterprise scale, and we're happy to compare notes on yours. Drop us a line.