A composite story about the things a tenancy migration never tells you up front, and the week we found most of them.

The brief looked clean on paper. A professional-services firm of about 60 people, two offices in the south of England, post-merger, sitting on two Microsoft 365 tenancies (the tenancy is your Microsoft 365 environment, the setup that holds accounts, files, mailboxes and settings; one company, one tenancy is the goal). One tenancy was inherited from the acquired side; one was the acquirer’s. The plan was the obvious one: consolidate everyone into the acquirer’s tenancy, decommission the other, and move on.

We scoped it as a six-week project. Four weeks of preparation, one week of cutover across a weekend, one week of stabilisation. The kit-list was modest. The user count was modest. The two tenancies looked similar from the outside.

Week three is when most of what we’d planned for stopped being the actual job.

What we’d scoped for

The plan covered the things tenancy migrations usually cover. Mail flow, OneDrive content, SharePoint sites, Teams, licensing, security policies, conditional access (the rules that decide who can sign in from where), and the SSO links (single sign-on, one set of credentials for the apps people use day-to-day) into the major business apps. We’d pulled inventories from both tenancies, mapped the licence counts, and identified the SharePoint sites that would need to come over versus the ones we’d archive.

We’d also done what we always do, a stakeholder workshop with the office managers and the heads of each practice group, to flag the things that don’t show up in an admin console. Shared mailboxes nobody owns. Power Automate flows that somebody set up in 2022 and forgot about. Guest users from old client engagements. Calendar permissions delegated to PAs.

The workshop surfaced a usable list. We thought we had the long tail.

What actually surfaced

The first real surprise turned up on day three of week three, when the lead from the acquired side mentioned, in passing, that “the legal team uses a separate sign-in for the document review platform — that’s still fine, isn’t it?” It wasn’t on any list we’d seen. The platform had been provisioned against the acquired tenancy two years ago, with SAML (security assertion markup language, an older single-sign-on standard) linked to the old domain. Decommissioning the tenancy would have killed it on cutover weekend.

That conversation triggered a wider sweep. By the end of week three we’d found:

  • Three more SaaS tools with SAML links to the old tenancy that nobody had flagged, because the people who provisioned them had left.
  • A shared mailbox the marketing team had been using as the inbound for an event series, with two years of replies in it, that wasn’t owned by anyone in the current org chart.
  • A set of automated workflows pushing files from a client portal into a SharePoint site that was on our archive list. Killing the site would have broken the workflow with no warning.
  • Two physical multifunction printers configured to send scans to a mailbox in the old tenancy. One of them had a paper-based handover note next to it from 2023 that said “do not change this”.
  • A team of six in one of the offices who had built a parallel set of Power Automate flows on their own initiative, depending on the old tenancy’s permissions model. The flows worked, and nobody in IT knew they existed.

None of it was anybody’s fault. Three years of normal operating turns into a pile of decisions and shortcuts that nobody documents because they’re working. A merger surfaces it because every link gets stress-tested.

How we handled it

We stopped the cutover. The original plan had us cutting over at the end of week four. We told the client we were extending the prep window by two weeks, pushing the cutover to the end of week six and stabilisation into week seven, and we’d absorb the extra preparation time against our original quote rather than re-negotiate it. The cost of cutting over with known unknowns was going to be much higher than the cost of two extra weeks of discovery.

Then we ran a sweep we should probably have run in week one. We pulled every SAML and OAuth (a newer single-sign-on standard used by most cloud apps) integration off both tenancies. We pulled every Power Automate flow, every shared mailbox, every printer-to-mailbox relay. We cross-referenced against the active user list. Anything orphaned got a triage tag: keep, migrate, retire, ask.

The “ask” pile, about 30 items, was the interesting one. We took them to the office managers in batches over a week and got a decision on each. Three were live and important. The rest were genuinely dead and could be retired.

Cutover weekend ran cleanly after that. There were three small issues in the week after, none of them blocking, and they came from places the discovery sweep had flagged.

What we’d do differently next time

The discovery sweep should have been week one, not a panicked week-three reaction. We’d front-loaded the stakeholder workshop and assumed it would surface most of the long tail. It surfaced about 40% of it.

The other 60% was the stuff nobody currently in the org chart could name, because the people who set it up had moved on. You can’t workshop that out of people who don’t know it exists. You have to pull it out of the tenancy itself.

So our updated case-study template now has a hard rule: before any cutover date gets quoted, we pull the full integration and automation inventory off both tenancies and reconcile it against the active user list. Orphaned items get triaged before week two. It costs a few extra days at the start and saves a lot of phone calls at the end.

Practical lessons

A few things worth carrying into any tenancy consolidation project:

  • Treat the workshop as a starting point, not a complete list. The people in the room can only flag what they know about. Three years of operating creates a long tail of things nobody in the room remembers.
  • The technical inventory is the second source of truth. SAML integrations, OAuth grants, Power Automate flows, shared mailboxes without owners, printer relays, conditional-access exceptions; pull them all and reconcile.
  • Anything that’s been working for two years and isn’t owned by anyone is a high-risk item. It’s almost always doing something useful for somebody who hasn’t thought about it in a while.
  • Pad the schedule before the cutover, not after. Stabilisation weeks fill up with rework if discovery was thin. Better to add the time at the front.
  • Communicate the extension early. Clients tolerate a re-baselined schedule far better than a chaotic cutover.

Where Consulting Services sits

This is the kind of project where the practice earns its keep. Not because the cutover itself is hard (most of the technical work on a tenancy migration is well-understood) but because the discovery work upstream of the cutover is what determines whether it lands well. That’s what our Consulting Services practice does. We’ll run the migration end-to-end, or we’ll sit alongside your in-house team and make sure the discovery work is doing its job before the cutover date gets fixed.

If you’re carrying two tenancies after a merger, or staring down a migration date with a stakeholder workshop that feels too thin, that’s our Consulting Services practice. We’ll either run the migration end-to-end, or sit alongside the in-house team and make sure the discovery work surfaces the long tail before the cutover date gets fixed. Drop us a note at info@jmopartners.co.uk and we’ll set up a conversation.

JMO|Partners · Enterprise IT, sized for SMEs.