Litigation hold blocks the mailbox migration you planned

The wave plan looks finished. Mailboxes grouped by department, a pilot cohort, a cutover weekend, two weeks of hypercare afterwards. Then somewhere around the third wave a mailbox behaves oddly, or — worse — the move completes cleanly and a month later somebody in the general counsel's office asks what happened to the preserved copies for a matter that is still open.

A mailbox on hold is a mailbox that does not migrate cleanly, and plenty of migration plans discover it mid-cutover. We have run into it during scoping work ourselves. It is a genuinely recurring gate, it is almost never written up plainly, and it is one of the few migration problems where the correct next step is not an engineering decision at all.

What a hold is actually protecting

A hold is not a backup and it is not a copy job. It changes how the mailbox behaves underneath: items the user deletes, and previous versions of items the user edits, are retained rather than aged out of existence on the normal schedule. That preserved material accumulates in the mailbox's Recoverable Items area, not in the folder tree the user browses. To the custodian, nothing looks different. To the compliance boundary, a great deal is different.

The consequence for a migration is direct: the mailbox a user sees and the mailbox a hold is protecting are not the same set of content, and only one of them is what a migration tool is pointed at by default. A cutover that reports a clean pass on every visible folder can still have left the part that mattered behind.

Why moving the mailbox is a preservation event

A cross-tenant move is not a relocation. It is a copy of content into a newly provisioned mailbox inside a different compliance boundary, with a different set of policies, a different audit trail, and a different administrator.

Holds live in the source tenant. A litigation hold is a property of the source mailbox; an eDiscovery hold belongs to a case in the source tenant's compliance estate. None of that configuration travels with the content. At the moment of cutover you therefore have two facts that somebody will eventually be asked to explain: the destination mailbox is under no hold unless a person deliberately places one there, and the preserved source material has either been carried, or has not, depending on a tooling decision that was probably made for throughput reasons months earlier.

There is a second-order effect that surprises people, and it lands on the budget rather than the risk register. In Exchange Online, removing the license from a held mailbox — or deleting it — does not discard it. It becomes an inactive mailbox that the source tenant continues to preserve. That is the correct behavior and usually the desired one, but it means a source tenant with held mailboxes in it cannot simply be wound down on the date you promised. The source tenant becomes a preservation asset with an owner, a cost, and an administrator who still has to be able to search it. Migration business cases that assume the old tenant switches off at cutover plus thirty days are the ones that break here.

The hold census is a gate, not a task

The census belongs in discovery, ahead of the wave plan — not as a checklist item inside migration execution.

What it has to enumerate:

• Mailbox-level litigation holds. The straightforward case, and the one a per-mailbox check finds.
• eDiscovery case holds. These are applied by a policy attached to a case, not by a flag set on the mailbox, so a script that only reads mailbox properties will report a held custodian as unheld. This is the gap we see most often in an otherwise diligent census.
• Older in-place holds. Long-lived tenants accumulate them. A tenant that has been through two prior migrations and three compliance owners usually has one nobody remembers creating.
• Retention holds. A different control entirely — see below — but it has to be in the inventory because it is the one people mistake for preservation.
• Shared, resource, and departed-employee mailboxes. Held mailboxes with no live user attached are the ones with no obvious owner to ask, which is exactly why they get skipped.
• Archive mailboxes. Held custodians' older material disproportionately lives there.
• And for each row: which matter, and who owns that matter. This is the column that turns an inventory into a decision document — and the column IT cannot fill in on its own.

The reason it must run first is sequencing, not thoroughness. A hold is a legal instruction with a named owner, and that owner needs lead time to answer questions about it. Find one during cutover and you have two options, both bad: stop a wave that is already moving, or move the mailbox and explain the decision afterwards. Run the census in discovery and the same finding is a scheduling input.

Archive mailboxes: the second thing everyone forgets

The archive is a separate mailbox. It has its own contents, its own growth pattern, and — where auto-expanding archive is in play — potentially more than one underlying storage area rather than a single object to copy.

Two things follow. Throughput estimates built from primary mailbox sizes will be wrong, sometimes by a margin that eats the cutover window. And archive support is a specific question for whichever tooling you have selected, asked before the plan is fixed: does it move archives, does it move auto-expanding archives, and what does it do with a held custodian's archive in particular.

The tooling underneath is moving

One constraint worth stating precisely, because it is new and because it is easy to state too strongly. As of 2026, public folder and archive mailbox migration is not yet supported on Microsoft Graph, and Microsoft's stated position is that work in those areas is ongoing. That is a current gap, not a permanent one.

It matters because the other half of the picture is moving at the same time: Exchange Web Services is being retired in Exchange Online, which we wrote up in the August deadline most tenants will miss. So the workloads that sit at the tail of a tenant-to-tenant cutover — public folders, archives, the long slow content that determines the actual cutover date — are exactly the workloads where the interface underneath the tooling is in transition.

This is not a reason to stop planning. It is a reason to ask your migration vendor which interface their archive and public folder lanes use today and what their published path forward is, rather than assuming a Graph-based product covers every workload or that last year's tool has this year's lane. Where those workloads normally sit in the sequence is covered in our tenant-to-tenant Microsoft 365 migration playbook.

Retention policy, retention label, retention hold, and a hold

Four controls, routinely collapsed into one word, and the difference changes the plan.

The conflation is not academic. "We have retention on everything" is the sentence we most often hear ahead of a missed hold, because retention is a lifecycle rule applied broadly, while a hold is an instruction about one matter with a lawyer's name attached to it. Getting the label and policy model coherent in the first place is Microsoft Purview data governance work, and it is considerably cheaper to do before a migration than to reconstruct after one.

Whose decision this is

Worth being blunt here, because the pressure at cutover runs the other way.

Whether a hold applies, how broadly it is scoped, what content it reaches, and whether it may be released or narrowed are legal judgments belonging to the client's counsel. Not the IT director's. Not the internal messaging team's. Not the migration provider's, and not ours. A hold being inconvenient for a scheduled weekend is not an input into that judgment, and "the wave was already booked" is not a reason that survives being written down.

What the IT side genuinely owns is substantial, and worth stating just as plainly:

• An accurate, complete census, produced early enough to be useful.
• An honest account of what the chosen migration path does and does not carry — including the parts that are unknown until a pilot proves them.
• Execution of whatever is decided, and a durable record of what moved, when, and under whose instruction.
• The technical ability to preserve, search, and export on both sides of the move for as long as it is needed.

If counsel's answer is that the hold stays and the mailbox still has to move, that is a legitimate answer and it converts cleanly into an engineering problem — source preservation, an inactive mailbox with an owner, a documented search capability on the old tenant. What IT should never do is release a hold, narrow a hold, or move a held mailbox because the calendar demanded it. Get the decision in writing, per matter, with a date on it. The job is not to have an opinion about the hold; it is to make the decision easy to make and impossible to lose.

Sequencing: held mailboxes get their own wave

The practical shape that falls out of all of the above is a separate wave. Start its decision cycle first and run its execution last.

1. The decision has external lead time. Every held mailbox needs an answer from someone who does not report to IT and does not work to the migration schedule. Batch those questions and ask them in discovery.
2. The content behaves differently. Preserved items and archives mean the throughput numbers from your general waves do not transfer. Sizing a held wave off an unheld wave's rate is how cutover windows overrun.
3. The source-side obligation changes the decommission plan. Held mailboxes are the reason the source tenant stays alive past the date everyone assumed. That belongs in its own line on the plan and its own line on the budget, not buried in a wave summary.
4. Isolation is evidentiary, not just operational. If something goes wrong with a held mailbox, you want it isolated and documented — not tangled in a four-hundred-mailbox weekend where the record is a tool log nobody can read back to a lawyer.

Why this bites law firms hardest

Every organization with open matters has this problem. Firms have it at a different density: more matters, more custodians under preservation at any given moment, and holds that cross organizational boundaries when lawyers move between firms with a book of business. A merger or a lateral group move is precisely the event that triggers a tenant migration and the event most likely to have live preservation obligations attached to the people being moved.

That is the argument for doing the census before anyone draws a wave plan, and for keeping the matter owner in the room from the start. The wider shape of that work — matter-driven architecture, the label and retention model, and eDiscovery readiness that is actually usable on a Tuesday afternoon — is on our legal IT consulting page. The migration side sits under tenant-to-tenant migration.

Related reading

• Where public folders and archives sit in a cross-tenant sequence, and what the phases actually cost in time: the tenant-to-tenant Microsoft 365 migration playbook.
• The interface change underneath the tooling: EWS retirement — the August deadline most tenants miss.
• Getting the label, retention and policy model coherent before it has to survive a move: Microsoft Purview data governance.
• What this looks like inside a firm, including matter-driven architecture and eDiscovery readiness: legal IT consulting.

The 30-second version

A hold changes how a mailbox behaves underneath, preserving deleted and edited items in an area the user never browses — so the content a migration tool sees and the content a hold protects are not the same set. Holds are source tenant configuration and do not travel, which makes a cross-tenant move a preservation event rather than a relocation, and which usually means the source tenant cannot be wound down on schedule. Run the hold census in discovery, before the wave plan — including the eDiscovery case holds a per-mailbox check will miss, the older in-place holds, the ownerless shared mailboxes, and the archives. Keep retention policy, retention label, retention hold and a preservation hold clearly distinct, because collapsing them is how holds get missed. Confirm your tooling's archive and public folder lanes, given that as of 2026 those workloads are not yet supported on Microsoft Graph while Exchange Web Services is being retired in Exchange Online. Then put held mailboxes in their own wave — decision first, execution last. And the decision itself is counsel's, always.

If you have a tenant move or an Exchange migration on the calendar and nobody has asked counsel about holds yet, that is the conversation to have this month rather than during the cutover. The project intake form takes about three minutes; two-business-day response with scope and timeline.

Pro IT NW is a senior-led, labor-only Microsoft consultancy in the Seattle area. We engineer preservation, search and migration infrastructure for firms and corporate legal departments — the census, the sequencing, the tenant work. We do not advise on preservation obligations, spoliation risk, or whether a hold may be released, and nothing in this post is legal advice. Those calls belong to your counsel.