Three tenants, four identity providers, and everyone wants it consolidated by Q3.
Migrations fail when they're treated as a weekend engineering exercise. Ours ship with project management, user communication, training, and post-migration support from one accountable team — because the cutover is the easy part.
It looks straightforward on paper. It never is.
Every acquisition brought its own tenant, its own naming convention, and its own way of doing permissions. Users live in two Outlooks. Files exist in four places, three of them stale. Licensing is duplicated and nobody can say by how much.
The organization needs one identity and one bill — but every consolidation story you've heard from peers involves a lost mailbox, a furious executive, and a weekend that didn't end.
One tenant, one identity, one bill — and a paper trail clean enough to hand to an auditor.
Mailboxes, files, Teams, and identities arrive in one tenant, wave by wave. Nothing user-facing disappears without a mapped replacement.
License reconciliation is built into the inventory phase, not an afterthought. What we reclaim often pays for a meaningful slice of the project.
Who moved, when, what changed — documented per wave, clean enough for the auditor and the board.
The playbook, phase by phase.
Every consolidation we run follows the same five phases. The tenants change; the discipline doesn't. Each phase ends with a document in your hands — that's how the paper trail gets built, not reconstructed afterwards.
Mailboxes, drives, Teams, domains, and licenses across all tenants — read-only access, no changes. Duplicate spend surfaces here, before anything moves.
Target identity design, naming conventions decided once, domain and alias mapping, coexistence plan. The arguments happen here — on paper, not at cutover.
A small group of real users — including at least one skeptic. Item counts verified against source, comms and training tested on people who'll tell us the truth.
Department by department, each wave announced ahead of time, trained, migrated, delta-synced, and verified before the next begins. Go/no-go gate on every wave.
MX and domain cutover with no downtime and no bounced mail. Surge support while habits settle, then a closeout you can hand to the auditor.
Week ranges reflect a typical engagement — your written plan comes with dates and fixed prices before anything starts.
The horror stories, and the engineering that prevents them.
Every consolidation horror story you've heard from a peer is a known failure mode with a known control. Here are the four we get asked about, and what's in the plan for each.
Someone's archive vanished in the move and nobody noticed for three weeks.
The CEO's delegate access broke and the whole project got renamed after the incident.
Cutover started Friday 6pm; Monday 9am it was still going, with mail bouncing.
People arrived to a new login screen, a moved J: drive, and a helpdesk queue three days deep.
Assembled from published, fixed-price engagements.
A consolidation isn't a mystery quote — it's assembled from the same fixed-price services on our public catalog, multiplied by your tenants and mailboxes. These are the engagements that anchor nearly every M&A project.
Names, not logos.
Consolidation is the work we're known for — and our clients recorded their stories themselves, on camera, under their own names.
Recorded by the clients themselves — real names, real projects. Videos open in a new tab.
Questions we get asked, answered without spin.
If your question isn't here, ask it below — an engineer answers by email, and Mike reads every one.
How long does a tenant-to-tenant consolidation take?
A two-tenant merge of roughly 500 seats typically runs 6–10 weeks end to end: two weeks of inventory and mapping, a pilot, then waves. More tenants add sequenced waves, not parallel chaos — multi-acquisition clients are done one tenant at a time, each on its own runbook.
Will mail go down at cutover?
No. The cutover method we use keeps both tenants live in coexistence, times the MX change, and delta-syncs until the switch — no downtime, no bounced email is the published scope of the migration service, not a stretch goal. If a wave's go/no-go gate fails, users keep working where they are.
What happens to the acquired company's domain and addresses?
Old domains get mapped, not dropped: every address becomes an alias in the target tenant, signatures and SPF/DKIM/DMARC records are re-pointed, and reply-ability to old addresses is preserved for as long as you choose to keep the domain. Retirement happens on a schedule, documented in the runbook.
Can you actually find the duplicate licensing?
Yes — it falls out of Phase 1 mechanically. When every tenant's license assignment is in one inventory, the double-paid SKUs and dormant accounts are just rows in a report. We document what we reclaim; on multi-tenant consolidations it's often enough to fund a meaningful slice of the project.
We're closing another acquisition mid-project. Now what?
It becomes another wave. The runbook is built to absorb new tenants — that's the point of doing identity and naming decisions once, up front. For clients who acquire regularly, the call to us moves onto the day-one checklist and each new tenant follows the same playbook.
Talk to the person who’ll actually be accountable.
Thirty minutes with Mike — our CEO, not a sales rep. He’ll tell you whether we’re the right fit, including when we’re not.