Ninety days. That was the entire window Coastal Freight Logistics had to move every site, file, and permission out of its old SharePoint tenant before the licence was switched off for good.
Coastal Freight Logistics, a 260-employee regional freight and warehousing company, had just been acquired by a larger national carrier. The acquisition terms were straightforward on paper: fold Coastal's systems into the parent company's Microsoft 365 tenant within one fiscal quarter. In practice, nobody on Coastal's three-person IT team had ever migrated a SharePoint tenant of any size before, let alone one they had not fully mapped out themselves.
Meet Dana, Coastal's IT manager. Dana inherited a tenant that had grown organically over eight years, with dispatch teams, warehouse managers, and regional branch offices all spinning up their own sites as needed, with no consistent naming convention and no central record of what existed where.
The Situation: Acquired, and Handed a 90-Day Deadline
Dana's first instinct was to start migrating the sites she already knew about: dispatch, warehousing, and the shared finance library. Three weeks into planning, a branch manager mentioned in passing that his region had "a couple of other SharePoint things" nobody at head office had ever heard of. That comment stopped the project cold. If sites existed that IT did not know about, the migration could not be scoped, and a scope built on partial information was not a scope Dana was willing to commit a 90-day deadline against.
Rather than keep discovering sites one branch-manager conversation at a time, Dana decided to build a complete inventory first, even though it meant losing a few days at the start of an already tight timeline. She reasoned that a few days spent scoping accurately would cost far less than a mid-project surprise with three weeks left on the clock.
Using Report Master, she ran a full tenant site inventory export in under two hours. The result surfaced 34 site collections. Head office's working list before the export had named 19. Fifteen sites, nearly half again as many as anyone had accounted for, had been created by branch teams over the years and never reported up.
The Inventory-First Approach That Changed the Timeline
With the full list in hand, Dana sorted it by storage and last activity. Eight of the fifteen previously unknown sites turned out to be dormant, no edits in over a year, mostly abandoned pilot projects from branches that had since standardised on the dispatch site instead. She confirmed with each branch manager that those eight could be archived rather than migrated, which immediately cut the effective scope back down closer to her original estimate despite starting from a much larger raw count.
The remaining seven previously unknown sites were active and needed to move. Two of them, however, had heavier permission structures than anything on Dana's original list: a compliance site with contractor accounts and item-level restrictions going back years, and a regional pricing library shared with two external logistics partners. Both would have blown a naive schedule badly if discovered during the final two weeks instead of during scoping.
Dana used the inventory data to build three migration batches, moving simple, low-permission sites first to validate the transfer process before tackling the compliance and pricing sites with their heavier permission mapping. She then ran the actual transfers using Clone Master, sequenced according to the batch plan the inventory had made possible.
| Before inventory | After inventory | |
|---|---|---|
| Sites on the known migration list | 19 | 34 (26 to migrate, 8 archived) |
| High-permission sites identified before scoping | 0 | 2 |
| Migration batches | 1 (all at once, planned) | 3, sequenced by complexity |
| Mid-project scope surprises | Zero, once the inventory was final | |
| Deadline result | Completed with six days to spare before the old tenant was decommissioned | |
See how Report Master scopes a migration
What Dana Would Tell Another Admin in Her Position
Dana's advice to other IT managers facing a similar acquisition deadline is blunt: spend the first few days on an inventory even when the clock is already running, because the alternative is discovering your real scope in pieces, at the worst possible moments, for the entire length of the project. The fifteen sites she did not know about at the start were never going to announce themselves. Something would have surfaced them eventually, and eventually is not a schedule.
She also kept the exported inventory as a living document through the project rather than treating it as a one-time scoping exercise, re-exporting it once midway through the ninety days to confirm nothing new had appeared and that the archived sites had genuinely stayed untouched.
Frequently Asked Questions
Why does an acquisition create a hard SharePoint migration deadline?
The acquired company's Microsoft 365 tenant is often licensed on a fixed schedule tied to the deal terms, and the parent organisation typically wants duplicate infrastructure decommissioned as soon as possible. That combination turns the migration into a fixed-date requirement rather than a project that can slip.
What is the biggest risk in a tight-deadline cross-tenant migration?
Discovering scope mid-project rather than before it starts. A site nobody accounted for, or a permission structure that takes longer than planned to recreate, costs disproportionately more time when it surfaces with weeks left on the clock than when it is caught during scoping.
How much does a site inventory actually shrink migration scope?
It varies, but it is common for a meaningful share of sites in an older, loosely governed tenant to be dormant enough to archive rather than migrate. Confirming that with the business, rather than assuming every site must move, is usually the single biggest lever for cutting total migration time.