Method
Anatomy of a tenant consolidation
What actually happens between “we have four tenants” and “we have one” — the sequence, the artifacts produced at each stage, and the decisions that determine whether a cutover holds.
What the mail is attached to
Moving mail is the part everyone can price. What determines whether the project succeeds is everything the mail was quietly attached to — identity that grew rather than got designed, applications authenticating against a tenant nobody planned to keep, a relay someone set up years ago and left.
The pieces are coupled, so sequencing is the actual work. And the failure mode is a business event rather than a technical one: a business unit that cannot invoice on Monday, an executive whose calendar history is gone, a partner integration that silently stops.
The eight phases
The same eight the rest of the site names. Movement is one phase with three stages inside it — separated here because each one has its own artifacts and its own way of going wrong.
Discover
Weeks, on a multi-tenant estate
Nothing gets a cutover date before this finishes. Every tenant is inventoried — identities, aliases, domains, authentication methods, admin roles, licensing, mail flow, DNS, SharePoint and OneDrive estates, Teams, applications, integrations, SMTP relays, endpoint dependencies. The output is not an estimate. It is a map of what is actually there.
What the client receives
- Estate inventory, per tenant
- Identity and access map
- Dependency map
- Remediation register
- Security and configuration findings
What tends to break here
The relay nobody remembers configuring. An application authenticating against a tenant somebody planned to retire. A domain verified in two places.
Design
Decided once, deliberately
What the destination actually looks like — identity model, domain strategy, licensing shape, security baseline, naming and governance. This is the decision that is expensive to revisit later, so it is made explicitly and written down rather than emerging from whatever the migration tool did first.
What the client receives
- Target-state design — identity model, domain strategy, licensing shape, security baseline
- Domain and mail-flow cutover design
What tends to break here
Two source tenants with the same UPN suffix. A target tenant that already has its own accumulated weaknesses waiting to be inherited.
Prepare
Before the move, not after
Blockers found in discovery get closed first. Duplicate identities reconciled, unsupported dependencies retired or replaced, mail security corrected, admin privilege reduced to something defensible. A migration that carries the problems across has not finished — it has relocated them.
What the client receives
- Remediation register, worked to closure
- Pre-migration validation checklist
- Findings the client chooses not to fix, recorded
What tends to break here
Remediation that needs a business decision, not a technical one. Those are surfaced early because they set the real timeline.
Migrate
Three stages, in this order
Movement happens in three distinct stages rather than as one operation, and they are not interchangeable. Each has its own rollback position, and none of them starts because the previous one ran out of time.
Pilot — a small group, fully
A representative cohort moves end to end — not a test mailbox, but real people. They bring real dependencies: calendars, delegate access, shared mailboxes, devices and the applications they actually use. The pilot exists to find what discovery missed, because discovery always misses something.
What the client receives
- Pilot cohort definition and rationale
- Validation results
- Runbook corrections fed back into the migration plan
What tends to break here
Delegate and shared-mailbox permissions. Devices that need re-enrollment. The department whose workflow depends on something nobody documented.
Waves — sequenced by dependency
Users move in groups shaped by how they work together, not alphabetically and not by headcount. People who share calendars, mailboxes and files move together, because the coexistence gaps between waves are where the visible pain lives.
What the client receives
- Migration plan, with the dependency rationale for each wave
- Per-wave communications and support plan
- Coexistence handling for the gaps between waves
What tends to break here
Cross-tenant free/busy during coexistence. Distribution lists spanning two waves. External partners with cached routing.
Cutover — a stated window, with a rollback
Domains and mail flow move inside an agreed window. There is a rollback plan, and the conditions that would trigger it are written down before the window opens. The decision to roll back is one nobody makes well at 2am without a document.
What the client receives
- Cutover runbook, timed
- Rollback plan and its trigger conditions
- DNS and mail-flow change sequence
What tends to break here
TTL values that were never lowered. An MX record with a second, forgotten dependency. SPF, DKIM and DMARC that follow the domain and must move with it.
Validate
Against criteria agreed beforehand
Each wave is checked against what was agreed would count as finished for that wave, and the result is recorded rather than asserted. Doing it per wave rather than once at the end is what keeps a fault from being carried into the next group.
What the client receives
- Results against the criteria, per wave
- Evidence for mail flow, authentication, permissions and device compliance
- Exceptions accepted, with who accepted them
What tends to break here
Criteria nobody wrote down in advance, which turns validation into a negotiation about what finished was supposed to mean.
Stabilize
While people find what testing did not
The period after a wave lands, when real use meets the new environment. What surfaces here is rarely dramatic and rarely in the plan. A permission that was never exercised. A workflow that runs monthly. A device somebody had switched off during the wave.
What the client receives
- Open issues with an owner against each
- Corrections folded back into the runbooks
- Legacy cleanup completed or scheduled with a reason
What tends to break here
The process that only runs at month end, and is therefore first exercised weeks after the wave that moved it.
Support
Closing the engagement, not opening a contract
Everything stabilization surfaced gets fixed or gets an owner. The people who will run the environment are brought up to it while the engineers who built it are still there. What this step is not is an arrangement that continues — there is no monitoring here, no response time and nobody on call afterwards.
What the client receives
- Remediation of what hypercare raised, closed or assigned
- Knowledge transfer to the team that will operate the environment
- Anything still open, with a named owner on the client side
What tends to break here
Knowledge transfer booked as one session at the end, so the people who inherit the environment meet it for the first time after the engineers have left.
Handoff
Once, and it is the end of the engagement
The documentation the client keeps, and the source environments switched off. The test of a finished engagement is whether another competent engineer could pick the environment up and operate it from what is written down. If the answer is no, the work is not done regardless of whether the data moved.
What the client receives
- Configuration records and architecture documentation
- Operational runbooks
- Decommissioning plan for source environments
What tends to break here
Source tenants that cannot be decommissioned yet for retention or contractual reasons. That is scoped, not pretended away.
What we will not do
These are checkable during the sale, which is the point of stating them.
- No cutover date before dependencies are understood. A date given earlier than that is a guess wearing a commitment’s clothes.
- No zero-downtime promise. The commitment is a stated cutover window, a pilot, and a rollback plan with written trigger conditions.
- No silent migration of security problems. Findings are surfaced and the client decides who remediates — us, their team, or someone else.
- No certification or attestation. Configuration is assessed against published baselines, including CISA’s SCuBA baselines where they apply. Assessing against a baseline is not accreditation by anyone.
Where this starts
Every engagement of this shape begins with discovery. It is purchasable on its own, and the artifacts are yours whether or not we perform the migration.