Situation
Divestitures and tenant separation
Part of the organization is being sold, spun out or carved off — and everything it works with currently lives in a tenant that keeps running for everybody else.
The date is already fixed, usually by the agreement rather than by anyone who will have to do the work.
The first useful engagement here is scoping, not moving. What has to be established is what actually leaves, what is copied, what stays and what has to be provably gone. Most of that is a set of decisions the transaction has not made yet. Where the separated entity is landing in another Microsoft estate, that side is a consolidation.
A separation is not a consolidation reversed
In a consolidation everything is going to the same place, so the hard question is sequence. In a separation the destination is the easy part and the hard question is the boundary — what belongs to the entity that is leaving.
A merge can be conservative: when something is ambiguous it moves, and it is sorted out later in one environment. A separation has no equivalent. Once the entity is gone the two halves are administered by different organizations, and anything left on the wrong side is a request rather than a task.
What has to be decided before anything moves
Four questions with no equivalent in a consolidation. None of them is answered by the technology, and all four have to be answered before a separation can be planned.
What leaves, and what only looks like it should
A mailbox is obvious. A shared drive that both entities used is not, and neither is the document library where one team filed work for both. The boundary runs through the data rather than around a department.
What is copied rather than moved
Both sides frequently need the same records — contracts, project history, anything with an obligation attached. A copy is a legal question before it is a technical one, and it is the question that most often has no owner.
What the seller keeps, and for how long
Retention obligations do not transfer with the people. The separated entity leaves, and the original organization is often still required to hold records about the work it did.
What is destroyed, and who confirms it
The half of a separation nobody schedules. Access removed is not data removed, and a transaction agreement that requires deletion requires somebody to be able to say it happened.
The clock belongs to the agreement
A transitional services agreement usually keeps the seller running the environment for the separated entity for a defined period after the deal completes. It ends on a date, and on that date the arrangement stops being available.
Until then, one organization is operating IT for a company it no longer owns. That is a commercial position as much as a technical one, and it is usually the reason the date is not movable.
Where the entity is being bought rather than spun out, the same date is the buyer's deadline to have somewhere for it to land.
Where this usually starts
With an assessment of the estate as it stands, because the boundary cannot be drawn from an org chart. What comes out of it is a defined view of what the entity actually uses, what it shares, and what a separation would have to resolve. It is also the document the transaction side tends to need.
Migration Readiness Assessment
Where the entity is landing in another Microsoft 365 estate, that half is a tenant consolidation, and it is the same work as any other move into an occupied tenant.
If the separation is one half of a transaction that also combines estates, M&A technology integration covers the other direction.
Where there is no transaction and no deadline — several businesses simply sharing one tenant — that is a different problem with a different opening move.
Draw the boundary before the date arrives
The work that cannot be compressed is deciding what belongs to whom. Everything after that is scheduling, and everything before it is guessing.