Every object you drag into the new tenant costs you: a migration licence, a slice of the data window, and storage you may have to buy once you land. The real migration question is not how to move everything. It is what deserves to move, and that decision belongs to the business, not IT. <\/p>\n\n\n\n
There are two legitimate paths: pay for the space and carry everything across or decide what stays behind and move only what you need. Each carries different budgets and risks. The only option you do not have is refusing to choose. <\/p>\n\n\n\n
That choice sounds simple until you try to make it. The rest of this post shows why it usually starts with one uncomfortable truth: nobody one person or department knows what deserves to move. <\/p>\n\n\n\n
Ask IT how many Teams are in the tenant and they will give you an answer. It will sound confident. It will be wrong. The same is true for sites, and especially for OneDrives, because tenants do not stay still. Microsoft 365 makes creation easy, cleanup optional, and ownership unclear. Give a tenant three years and it quietly grows a second version of itself: old Teams, forgotten sites, abandoned OneDrives and objects nobody remembers creating. The real number is almost always higher than anyone wants to believe. <\/p>\n\n\n\n
Discovery comes first because everything sponsors care about depends on it. You cannot price the work, shape the scope, commit to a date, or defend the risk profile of an environment you have not counted. Until you know what is actually in the tenant, every budget is provisional, every timeline is optimistic, and every assurance is doing more work than the evidence behind it. <\/p>\n\n\n\n
That is why Microsoft 365 tenant migration planning<\/a> has to begin with understanding the current environment, not the migration tool.\u00a0<\/p>\n\n\n\n Counting is the easy half. Modern migration platforms will scan a tenant and hand back an inventory: objects, sizes, counts, ages, sharing configurations. Genuinely useful, and it takes very little time. <\/p>\n\n\n\n What it won’t tell you is what any of it means<\/em>. Which of those Teams still matters. Whether the site last modified in 2022 is abandoned or is the one thing your compliance officer would notice missing. Who to ask about the shared mailbox called admin-temp. Those answers don’t live in the tenant. They live in people’s heads, and some of those people have left.<\/p>\n\n\n\n Every tenant accumulates the same sediment, roughly in order of how surprised people are to find it: <\/p>\n\n\n\n None of this is unusual. It is the normal residue of people getting on with their jobs, and finding it is not a judgement on how the tenant has been run. <\/p>\n\n\n\n The problem is not that the mess exists. The problem is discovering it in week nine, after the plan is signed, the date is locked, and every forgotten object has become a decision someone needs to make by Friday. <\/p>\n\n\n\n This is also why determining the scope of a tenant migration<\/a> needs to go beyond headline workloads. The scope is shaped by the objects, dependencies, domains, infrastructure and end state you uncover during discovery.<\/p>\n\n\n\n \u201cAn inventory without owners is a list, not an audit.\u201d<\/strong> <\/p>\n\n\n\n An object shows up in a scan in seconds. Working out whether it still matters takes a conversation, often several, frequently ending at a name in the directory that’s been disabled since 2023. The IT team can tell you what a site is, how big it is, and who has access. What they can’t tell you, and have never had reason to know, is which department its two hundred members belong to, whether the process it supports still runs, or which of four near-identical Teams is the real one. That knowledge lives out in the business, with the people doing the work. Nobody in IT is hiding it. They were simply never asked to hold it. <\/p>\n\n\n\n And it’s rarely one object that costs you. Nobody loses a fortnight to a single mysterious mailbox. What costs the weeks is the aggregate: every user, every group, every Team, every site, each needing a small decision about whether it comes, where it lands, and who it belongs to, and each landing on the same desk. We’ve watched one capable person work through a list of thousands, asking around, getting answers one at a time because everyone who has them has another job to do. <\/p>\n\n\n\n Nothing has failed. Nobody has made a mistake. The project has simply stopped moving, and it stays stopped until answering these questions becomes part of more than one person’s job. <\/p>\n\n\n\n Discovery needs named business participants with time carved out. Not a distribution list. Not “we’ll loop in the department heads if we need to”. Named people who know their area and have been told this is part of their job for the next month (or however long it\u2019s estimated to take). <\/p>\n\n\n\n If your plan doesn’t have those names in it, discovery will take considerably longer than anyone has told you. <\/p>\n\n\n\n Carrying rubbish across isn’t free, and the mechanics are worth understanding rather than nodding along at the principle. <\/p>\n\n\n\n It costs licences<\/strong>. Migration platforms are generally licensed per object or per user. A Team nobody has posted in since 2022 consumes the same licence (and cost) as the one running your busiest project. So does the abandoned site, the orphaned mailbox, the OneDrive belonging to someone who left last year. You’re paying full rate to move things you’d have deleted if anyone had asked. <\/p>\n\n\n\n It costs time in the window<\/strong>. Teams, SharePoint and OneDrive carry the bulk of the data, and a terabyte nobody wants takes exactly as long to move as a terabyte somebody needs. Throughput is finite. Every gigabyte of dead weight sits in the queue ahead of something that matters, and that queue is what your cutover date is calculated from. <\/p>\n\n\n\n It costs storage on the other side<\/strong>. SharePoint Online tenant storage is pooled and finite. It scales with your licence count, not with your ambitions, and if what you’re planning to send exceeds what the destination can hold, additional capacity is a purchase. A recurring one. That’s the version of this cost that outlives the project; everything else closes when the project does. <\/p>\n\n\n\n This is the garage problem. Everyone has a box in their garage, nobody has opened it in years, and the question only ever gets asked when the removalist is standing in the driveway wanting to know whether it’s contents are coming to the new garage. <\/p>\n\n\n\n You can pay for the space or put in the effort to avoid needing it.. Both are legitimate choices, but they create completely different projects with different budgets, timelines and risks. How you choose between them is the subject of the next post.<\/p>\n\n\n\n There’s an asymmetry in most of these projects, and it catches people out. There are two environments to understand, not one. The unfamiliar one gets all the attention. The familiar one holds the surprises. <\/p>\n\n\n\n The incoming tenant gets scrutiny because it is unfamiliar. The target tenant often gets a pass for exactly the opposite reason: it feels known. That is the risk. You are not just moving data into a clean destination; you are dropping several hundred people, their content, their permissions and their working habits into an environment that already has years of decisions, exceptions and compromises baked into it. <\/p>\n\n\n\n Maybe make a call out statement along the lines of \u201cIf you think the incoming tenant has redundant data that can be removed, why do you think yours is any different\u201d <\/p>\n\n\n\n The storage ceiling belongs to the target, so if that’s you, “is there room for what’s arriving” is your question, and you can’t answer it without knowing what’s already taking up space. Then the softer collisions: naming conventions that contradict each other, sharing settings one side finds normal and the other finds alarming, guest policies written for two different organisations. <\/p>\n\n\n\n Somebody has to decide whose habits win, and that’s a fight worth having deliberately. <\/p>\n\n\n\n There’s a whole post on it later in this series.<\/p>\n\n\n\n The first post in this series, What a Microsoft tenant-to-tenant actual involves<\/a>, set out fidelity as a standard requirement: data, metadata, permissions and versions arrive intact, or the deviations are consciously accepted and written down. Discovery is where you find out which ones you’ll be accepting.\u00a0<\/p>\n\n\n\n Three things surface repeatedly. <\/p>\n\n\n\n Permissions<\/strong>. References to identities which won’t exist on the other side, or which will exist under a different name. <\/p>\n\n\n\n Retention policies and legal holds<\/strong>. Policies attached to objects nobody can currently account for, in an area where “we think it’s fine” isn’t an answer you can give an auditor. <\/p>\n\n\n\n Links<\/strong>. Addresses about to change, embedded in documents, in site content, in bookmarks, in third-party systems, in a spreadsheet somebody built in 2019 that half the department still opens every Monday. No standard migration tool will find them. They will be found by users, after go-live, in the worst possible way. <\/p>\n\n\n\n Each of those is specialist work. What matters at this stage is knowing they exist before the plan is signed, not after. <\/p>\n\n\n\n No, you won’t! <\/p>\n\n\n\n There is always a post-migration window, but it is not a cleanup window. It is for stabilising the service, handling support noise, decommissioning old access and removing the scaffolding the migration needed. That work is real, but it is not the moment anyone starts debating whether a forgotten site should have moved. <\/p>\n\n\n\n By then, the decision has already been made by default. The team is keeping the lights on, the budget is closing, and the people who know what matters are back in their day jobs. Whatever you carried across becomes part of the new tenant, mixed in with the content people actually use, until someone finds it years later during the next migration. <\/p>\n\n\n\n There is a compliance cost as well. Every unexamined file you move enters an environment already governed by retention, eDiscovery and audit obligations. If it turns up in a future search, someone still has to answer for it. <\/p>\n\n\n\n If content isn’t worth the effort of understanding before it moves, that’s a reasonable clue about whether it’s worth moving. The question gets asked once, and it gets asked now.<\/p>\n\n\n\n Nobody has ever regretted starting discovery earlier than they thought necessary or complained about knowing too much about their own environment. <\/p>\n\n\n\n The object count at kickoff isn’t the count you’ll migrate. It moves, usually upwards, once the scan comes back. Plan for a provisional number, not a fixed one. <\/p>\n\n\n\n The business owner who’s too busy in week two is the one escalating in week ten. Their time doesn’t get cheaper by being booked late; it just arrives at a worse moment. <\/p>\n\n\n\n And discovery findings changing your scope is discovery working. An estimate that survives contact with the real environment untouched was a guess that got lucky. <\/p>\n\n\n\n The awkward part of discovery isn’t the scanning. It’s walking into a department and asking someone to justify a site they haven’t opened in two years. An outside party can ask that more directly than someone who has to keep working alongside these people afterwards, and Insentra has done it often enough to know the difference between an answer and an assumption. Talk to Insentra<\/strong><\/a> about your environment before scope, budget and cutover dates become fixed. We can help you understand what is really in the source and target tenants, identify the decisions the business needs to make and turn those findings into a migration plan you can actually defend.\u00a0<\/p>\n\n\n\n Next in the series: you now know what you’ve got. The harder question is how much of it deserves to come with you. <\/p>\n\n\n\n <\/p>\n","protected":false},"excerpt":{"rendered":" Every object you drag into the new tenant costs you: a migration licence, a slice of the data window, and storage you may have to buy once you land. The real migration question is not how to move everything. It is what deserves to move, and that decision belongs to the business, not IT. There… Continue reading Know Your Tenant Before You Move It: Why Migration Discovery Is A Whole-of-business Job<\/span><\/a><\/p>\n","protected":false},"author":175,"featured_media":40841,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"content-type":"","footnotes":""},"categories":[22],"tags":[],"class_list":["post-40840","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-migrations","entry"],"_links":{"self":[{"href":"https:\/\/www.insentragroup.com\/nz\/wp-json\/wp\/v2\/posts\/40840","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.insentragroup.com\/nz\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.insentragroup.com\/nz\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.insentragroup.com\/nz\/wp-json\/wp\/v2\/users\/175"}],"replies":[{"embeddable":true,"href":"https:\/\/www.insentragroup.com\/nz\/wp-json\/wp\/v2\/comments?post=40840"}],"version-history":[{"count":1,"href":"https:\/\/www.insentragroup.com\/nz\/wp-json\/wp\/v2\/posts\/40840\/revisions"}],"predecessor-version":[{"id":40843,"href":"https:\/\/www.insentragroup.com\/nz\/wp-json\/wp\/v2\/posts\/40840\/revisions\/40843"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.insentragroup.com\/nz\/wp-json\/wp\/v2\/media\/40841"}],"wp:attachment":[{"href":"https:\/\/www.insentragroup.com\/nz\/wp-json\/wp\/v2\/media?parent=40840"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.insentragroup.com\/nz\/wp-json\/wp\/v2\/categories?post=40840"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.insentragroup.com\/nz\/wp-json\/wp\/v2\/tags?post=40840"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}The things nobody remembers owning<\/h2>\n\n\n\n
\n
Finding the thing is easy. Finding its owner is the expensive part<\/h2>\n\n\n\n
What this means for your project plan<\/h2>\n\n\n\n
What the junk actually costs<\/h2>\n\n\n\n
The target tenant has its own history<\/h2>\n\n\n\n
What breaks fidelity<\/h2>\n\n\n\n
“We’ll bring it all over and clean it up later”<\/h2>\n\n\n\n
Four things worth knowing before you start <\/h2>\n\n\n\n
Key takeaways<\/h2>\n\n\n\n
\n
When you’d rather someone else did the asking<\/h2>\n\n\n\n
If you are planning a Microsoft 365 tenant-to-tenant migration, acquisition, divestiture or consolidation, discovery is the place to find the problems while you still have choices about what to do with them. <\/p>\n\n\n\n