The meeting always goes the same way.
Someone asks whether we’re taking everything. Someone else says let’s just bring it all across and sort it out later, which we’ve already established is a decision to never sort it out. Then someone senior, quiet until now, says: *while we’re in there, could we finally do something about SharePoint?*
And now there are two projects on the table. Nobody has said so out loud, and nobody will, until about week fourteen.
Both answers are defensible. They’re answers to different questions, with different budgets, and the organisation that doesn’t choose between them consciously ends up doing an expensive impression of both.
Fidelity is a dial, not a standard
The first post “What a Microsoft 365 Tenant-to-tenant Migration Actually Involves”, listed fidelity as a standard requirement: data, metadata, permissions and versions arrive intact, or the deviations are consciously accepted and written down. Time to be precise about that, because “intact” sounds binary and isn’t.
Version history is a dial. Metadata is a dial. So are folder structures, permissions, chat history and mailbox rules. Every one is a separate question with a separate cost, and every one can be set anywhere from “exactly as it was” to “we’re not bringing that”.
Nobody sets them all to maximum. What happens instead is that nobody sets them at all, everyone assumes maximum, and the assumption survives right up until it meets the schedule. Then comes the week-eleven conversation where someone learns that a fidelity target they never articulated is going to cost them money or time, and they have to pick.
The reframe worth carrying into every conversation from here: fidelity is a target the business sets, not a standard the platform meets. A deviation that was chosen, documented and signed off is a design decision. The same deviation discovered by a user in March is an incident.
It feeds the schedule too. How much you carry affects how long moving it takes, which affects what kind of cutover is available to you at all. That decision comes later in this series.
Three options, and everybody forgets the third
Frame it honestly and there are three.
Lift and shift. Take it as it stands. Fast, predictable, easy to explain to a steering committee. You also carry every structural decision anyone made in a hurry since 2014, and you pay to move all of it.
Redesign. Restructure as you go. Expensive, slower, and genuinely the only moment the business will ever fund this work, because “we’re doing it anyway” is the most persuasive sentence in enterprise IT.
Leave it behind. Archive it where it sits, retain it in place, or decommission it outright.
That third one never makes the slide. It’s the cheapest by a distance, it’s available far more often than people assume, and it gets skipped because it feels like an admission of defeat. Somebody paid for that content once. Deciding not to move it feels like conceding the money was wasted.
It wasn’t wasted. It was spent, the content did its job, and its job is finished. A good portion of what’s in your tenant is a record of work that concluded years ago, and the right home for a finished record is rarely an expensive collaboration platform in a live tenant.
Where the storage ceiling comes in
The second post “Know Your Tenant Before You Move It”, left this open. SharePoint Online tenant storage is pooled and finite, it scales with licence count, and additional capacity is a recurring purchase.
That ceiling isn’t the reason to have this argument. It’s the reason you can’t postpone it. If what you’re planning to send is larger than what the destination can hold, the decision gets made within the fortnight either way: as a purchase order, or as a conversation about what stays behind.
The decision is per workload, not per project
Here’s where organisations go wrong structurally. They try to answer this once, for everything.
It doesn’t work, because the four main workloads present completely different versions of the problem.
SharePoint
The most tempting and the most dangerous.
Information architecture is a discipline in its own right. Restructuring it properly means understanding how the business actually organises its information, which is rarely how the sites suggest it does, and it carries its own discovery, its own decisions and its own sign-off. It’s a piece of work, not a task.
The temptation is straightforward: the content is moving anyway. Restructuring while everything’s in motion is genuinely cheaper than doing it standalone later, and later almost never arrives.
The danger is that it’s a project with its own timeline, and it has just been placed inside a project whose timeline was set by a contract. Renovation logic applies. While the walls are open, the rewiring is cheap. But nobody has ever moved a kitchen without learning something about the plumbing, and your builders have to be finished by March regardless.
There’s a version of this that works. It involves deciding early, scoping it properly, and running it as parallel work with its own budget rather than something absorbed into the migration’s contingency. There’s also a version where it’s agreed enthusiastically in a workshop and never scoped at all.
Teams
Sprawl, mostly. Teams created for a project that finished, teams duplicating other teams, teams that are functionally a group chat with governance aspirations.
The easy call is that dead teams don’t move. The harder question underneath: a team nobody has posted in for two years may hold the only surviving record of how a decision was made. Activity is a poor proxy for value, and the difference between “abandoned” and “concluded” matters enormously to anyone who later needs it.
That’s a business judgement about corporate memory, not a technical one about last-modified dates.
OneDrive
Two problems wearing one name.
The first is departed users, and the unresolved question of whose data that is. Somebody left in 2023, their OneDrive is still there, it holds a mix of work product and whatever else people keep in a personal drive. It has a size, it has a licence implication, and it has no owner anyone can ask.
The second is what sits in the drives of people who are still here, which gets its own section below.
Mail and archives
Mailbox size is a monument to the fact that nobody has ever deleted an email. Archives, likewise, with the added feature that nobody has opened them since the day they were created.
Mail is where the leave-it-behind option is most under-considered, because email feels precious in a way a dormant SharePoint site does not. Some of it genuinely is. A lot of it is fifteen years of calendar invitations and delivery receipts.
The things that aren’t in the tenant
A T2T attracts passengers.
Somewhere in the first month, someone mentions the file share. Then the old archiving product nobody decommissioned. Then a server-based application with its own document store, which turns out to matter quite a lot to the finance team.
These are sometimes legitimately in scope. A tenant migration can be exactly the right moment to deal with them, while the business’s attention and budget are already pointed that way.
What they’re not is free, and what they must never be is absorbed. Each is a separate piece of work with its own discovery, risks and cost. Bringing them in is a decision that changes the scope, the price and the date. Letting them arrive quietly through a series of reasonable-sounding workshop conversations is how a fixed-price engagement turns into a dispute.
Content with no business requirement
Then there’s the material nobody would defend if asked directly.
PSTs full of mail from a job somebody had two roles ago. Music libraries. Holiday photos. Installers for software that no longer exists. The complete 3 hour video of a conference from 2017 that nine people attended.
Nobody is paying to migrate a wedding album, and yet organisations do, in volume, every year. Cleanest case for the option three, and usually the easiest saving available.
Here’s the thing though: nobody is going to find it for you. No organisation is trawling through eight hundred OneDrives making judgement calls about whether someone should have kept that. What organisations do instead is ask. An email goes out, users are told the migration is coming, and they’re asked to clean up their OneDrive and their mailbox before it does.
Which turns a data decision into a communications problem, and communications problems have a much lower success rate than project plans assume.
Some people will do it thoroughly. Most will do it in the last twenty minutes before the deadline, if at all. And the people carrying the most junk are reliably the least likely to act on an email about it. The ask has to go out early, be specific about what’s wanted and why, and come from someone with more authority than the migration project. One message from IT three weeks out will not do it.
Migration tooling can generally exclude content by file type, which is a useful blunt instrument and worth knowing you have. Blunt is the operative word. Deciding what gets excluded across an entire organisation is a policy call with consequences, and someone still has to own it.
One geographic caveat. Where your people are employed changes what you’re allowed to do here. A blanket sweep that raises no eyebrows in Sydney or Chicago can run into employee data protections in the UK and across Europe, and the answer isn’t obvious from the outside. If you employ people in those jurisdictions, settle the position on personal content with someone who knows the rules that apply to them, before the comms go out rather than after.
None of this changes who decides. Whether the business asks users to clean up, excludes categories wholesale, or accepts the cost and carries it all, that’s a choice with a price attached, and it belongs to the business rather than the migration team.
Retention, holds, and the limits of leaving things behind
One hard boundary on all of the above.
Everything so far assumes the decision is yours. For most content it is. For content under a legal hold or a live retention obligation, it isn’t, and the discretion you’ve been exercising for the rest of this post simply stops.
That doesn’t automatically mean the content has to move. Obligations attach to the data, not to the tenant it happens to sit in, and there are legitimate outcomes where content stays exactly where it is and remains preserved and retrievable. What it does mean is that the choice belongs to whoever owns the obligation, made with full knowledge of what’s covered, and cost is not one of the inputs.
What has never worked is discovering the obligation afterwards. “We didn’t bring it across” is not a defence, and neither is “nobody told us it was on hold”.
That’s the ceiling on the leave-it-behind option, and it’s why the compliance requirement from Post 1 needs answering before the data decisions get made. Knowing what’s under obligation is a prerequisite for having this conversation at all.
What happens when nobody chooses
The outcome I’d most like readers to avoid is also the most common one.
Nobody makes the decision, so it gets made in pieces by whoever is loudest in each conversation. Marketing, engaged and enthusiastic, negotiate a restructure of their sites. Finance, who are busy, insist nothing changes and get their way. Three other departments are never asked and find out from the go-live communications.
What you’ve bought is the redesign’s cost and the lift-and-shift’s mess, simultaneously. Some content is restructured, most isn’t, and the organisation now has two information architectures where it previously had one (and even then not necessarily a great one). It also has a project that ran over, because the restructure work was never in the plan or the budget.
The accidental hybrid is worse than either pure option. It’s also, in my experience, the single most common result of not putting this decision in front of someone with the authority to make it.
Who actually signs this off
Not IT.
IT can tell you what each option costs, how long it takes, and what the consequences are. That’s the right contribution and it’s substantial. What IT can’t do is decide what the business’s information is worth, because that’s a judgement about the business, and asking a platform team to make it is asking them to guess.
Who needs to be in the room: the content owners Post 2 told you to name, someone from compliance who can speak to retention and hold obligations, and somebody with the authority to spend money. If that group hasn’t met before the migration plan is finalised, the decision hasn’t been made. It’s been deferred to whoever’s available when it becomes urgent.
Key takeaways
- Fidelity is a set of dials the business sets, not a standard the platform meets. Undocumented assumptions become week-eleven surprises
- There are three options, and the forgotten one, leaving content where it is, is usually the cheapest and most available
- The decision is per workload. SharePoint, Teams, OneDrive and mail present different versions of the problem and deserve different answers
- Retention and legal holds override preference entirely. Cost is not a factor in that conversation
Making the call before it makes itself
Pricing lift-and-shift against a restructure, per workload, against a deadline somebody else set: most organisations do this once, while the clock is running. It’s a decision that benefits from having been made before, several times, by people who have watched both versions play out.
If a merger, acquisition or divestiture has put a tenant migration on your roadmap, the cheapest time to decide what moves, what gets restructured and what stays behind is before the plan is locked. Contact Insentra today and let’s talk it through.
Next in the series: the people who have to find their files on Monday morning, and why they’ll judge the entire migration on that experience.
