SharePoint Online to SharePoint Online Migration: Restructuring Inside One Tenant

Two environments show up in our discovery calls more than any other. The first is one giant site with close to 200 document libraries and a hub site nobody ever joined. The second is a tenant that moved off file shares around five years ago and copied the folder tree into SharePoint one-for-one, so the old S: drive now lives in a document library with the same twelve levels of nesting it had in 2021. Both organizations describe what they want the same way: a SharePoint Online to SharePoint Online migration.

Neither of them needs a migration. They need a structure, and then a move.

That distinction decides whether the project takes six weeks or stalls for a year, so this post covers the decisions that come before any tool runs, and then what actually moves and where the tools fit once the thinking is done.

What a SharePoint Online to SharePoint Online migration actually is

A SharePoint Online to SharePoint Online migration moves content between sites inside the same Microsoft 365 tenant: splitting one oversized site into many, consolidating scattered sites under a hub, pulling a department’s files out of a Teams site that was never meant to hold them, or rebuilding libraries so metadata replaces folders. The tenant and the licensing stay exactly where they are, and so do the users. Only the structure changes.

That makes it a different project from the two migrations people usually mean. A tenant to tenant migration crosses a boundary between two organizations and carries identity, licensing, domain, and coexistence problems with it. A SharePoint Server to SharePoint Online migration leaves an on-premises farm behind. In a same-tenant restructure there is no boundary to cross and nothing to retire. The whole job is deciding what the new structure should be and getting content into it without losing history, permissions, links, or the trust of the people who use it.

Vendors sell this as a tool problem. Most of the work happens before a tool is opened.

Why most of these projects are not migrations at all

A same-tenant restructure is an information architecture project with a content move at the end. The move is usually the shortest phase. The long phase is deciding which sites should exist, which libraries belong in them, who owns each one, and which content should not come along.

Look at the two environments from the opening again.

The giant site with 200 libraries did not get that way by accident. Each library was somebody’s answer to “where do I put this?” when no site existed for it. Moving all 200 libraries into new sites without asking that question again recreates the problem one level up. The actual work is grouping those libraries by owner and by how long the content lives, then checking who needs access to each group, which usually collapses 200 libraries into 25 or 30 sites with a few libraries each.

The copied file share is the same problem in a different shape. The folder tree was built for a network drive with no search, no metadata, no versioning, and no permission model beyond folder-level security. Moving it to a new site with the same tree changes the URL and nothing else. The work is mapping folder levels to sites, libraries, columns, and content types, which we walk through in how to map legacy folder structures to metadata in SharePoint.

If you skip the architecture and just move, you have paid for a migration and kept the mess.

What to decide before anything moves

Four decisions set the scope of a same-tenant restructure, and they are made in this order: what the target structure is, what content is in scope, what gets archived or deleted instead of moved, and what the cutover looks like for users.

The target structure

Start from the hub. A same-tenant restructure almost always ends with hub sites doing the work that one giant site or a pile of unconnected sites was doing badly. Our hub site architecture framework lays out how to decide how many hubs you need and what associates to each. The short version: hubs follow how the organization actually works, departments and functions and major programs, not the org chart and not whoever asked for a site first.

Under each hub, sites are defined by who owns them and how long the content lives, with the audience deciding the permission model. A library that holds HR policies and a library that holds HR project files have different owners and different retention rules. They should not share a site just because both say HR. The SharePoint information architecture best practices guide covers the rules we use to draw those lines.

What is in scope

Inventory every site and library, with owner, last modified date, item count, size, and whether it has unique permissions. The SharePoint admin center gives you most of this. The item count and last modified columns tell you more than anything else: a library with 40,000 items untouched since 2023 is not a migration candidate, it is an archive candidate.

What does not move

This is where the project is won. In the restructures we run, a large share of the content never moves to the new structure. It is archived in place, moved to Microsoft 365 Archive, or deleted under a retention policy. Every item that does not move is an item you do not have to remap, re-permission, re-link, or explain to a user. Make the archive decision per library, document it, and get the content owner to sign it. Nobody wants to be the person who deleted the 2019 audit folder, so the sign-off matters.

Cutover

Decide whether the move happens in one weekend or in waves by department, and what users see in between. Waves are safer for anything over a handful of sites. Users need a date, a new location, a reason, and someone to ask when a link breaks. The SharePoint migration project plan post covers how to lay the phases out.

What moves, what breaks, and what gets rebuilt

Inside one tenant, documents can move intact, and version history and metadata come with them. Permissions, links, workflows, and library settings usually do not come along, and planning for that is most of the technical work.

Content moves. Permissions, links, flows, and library settings have to be planned for.

Here is what to expect for each:

• Documents and version history: Move To in SharePoint keeps version history and metadata when moving between sites in the same tenant. Copy To keeps only the latest version. Third-party tools preserve both and also keep created-by and modified-by values, which Move To does not always do cleanly
• Metadata columns: content moves cleanly only if the destination library has matching columns. If the new structure introduces site columns or content types, map the old values before the move, not after
• Permissions: unique permissions at the folder and item level do not transfer through Move To. Treat the restructure as the moment to replace folder-level permissions with site-level and library-level permissions. The complete guide to SharePoint permissions explains why the old model should not survive the move
• Links: every link to the old location breaks, including links in Teams channels, intranet pages, Outlook, and bookmarks. Redirects exist for site URL changes but not for individual moved files. Plan a communication for each wave and keep the old library in read-only for a defined period
• Workflows and Power Automate flows: flows bound to the old library stop working. Inventory them before the move and rebuild them against the new library
• Teams-connected sites: a site that backs a Team cannot simply be merged into another. Decide whether the Team stays, gets archived, or gets a new site, and do that in Teams admin, not in SharePoint
• Library settings: views, column formatting, versioning limits, and required fields are configuration, not content. They get rebuilt in the destination, which is a good thing, because most of them were wrong

Where the tools fit

For a same-tenant restructure, native Move To handles small, well-defined moves, and a third-party tool earns its license when you have many libraries, a metadata remap, a delta pass to run, or a need to preserve authorship. Neither one replaces the architecture decisions.

Move To and Copy To work from the library command bar, one library or folder at a time. They are fine for a few dozen libraries moved by a site owner who knows the content. They are not fine for 200 libraries, for anything with a column remap, or for a move that needs to be repeated after a delta.

ShareGate, AvePoint, and similar tools do bulk site-to-site moves, remap columns and content types during the move, preserve created and modified values, run incremental passes, and produce a report you can hand to the content owner. In the two environments from the opening, both would use a tool, and in both cases the tool phase is the shortest part of the project. We compare the options in SharePoint migration tools compared.

Microsoft’s own SharePoint Migration Tool is built for file shares and on-premises SharePoint. It is not the tool for moving content between SharePoint Online sites.

One more option that people forget: sometimes the right move is no move. A site with the right content and the wrong URL can be renamed. A library that should be its own site can sometimes stay in place while the old site gets archived around it. Ask whether the structure can be fixed where the content sits before you plan to move it.

How long it takes and what it costs

A same-tenant restructure for a mid-sized organization typically runs eight to sixteen weeks, and the move itself is one to three weeks of that. The rest is inventory, architecture, archive decisions, and user communication. That ratio surprises people who were quoted a two-week migration by their IT department or a tool vendor.

The cost follows the same split. Tool licensing is a small line. Consulting time goes mostly into the architecture and the archive decisions, because that is where a wrong call costs the most later. How much does a SharePoint migration cost breaks the ranges down, and the SharePoint migration ROI calculator lets you run your own numbers against time currently lost to searching and duplicates.

If the environment is bad enough, the honest question is whether to restructure at all or to start over. We laid out how to make that call in fix SharePoint, rebuild it, or start over.

Where to start

Start with an inventory and a target structure, not with a tool trial. A SharePoint migration readiness assessment produces both: a scored view of what you have, a proposed hub and site model, a list of what should be archived before anything moves, and a realistic timeline. From there the move is a project with a known scope instead of a guess.

If you are weighing this against other types of SharePoint moves, the complete guide to SharePoint Online migrations covers every source we work with, and our SharePoint migration services page explains how we run the engagement.

Frequently asked questions

Is a SharePoint Online to SharePoint Online migration the same as a tenant to tenant migration?

No. A same-tenant restructure moves content between sites inside one Microsoft 365 tenant. A tenant to tenant migration moves content between two separate tenants, usually after a merger or divestiture, and carries identity and licensing work that a restructure does not.

Does Move To keep version history?

Yes, when moving between sites in the same tenant, Move To retains version history and metadata. Copy To keeps only the latest version. Neither reliably preserves created-by and modified-by values or unique permissions, which is why larger restructures use a third-party tool.

Can I just move my 200 libraries into new sites?

You can, but you will have recreated the same problem across 30 sites. Group libraries by owner and retention first. In most restructures a large share of the libraries are archived rather than moved, and the ones that move are reorganized around metadata instead of folders.

Should I use a migration tool for a same-tenant move?

For a few libraries, Move To is enough. For many libraries, a metadata remap, incremental passes, or a need to preserve authorship, a tool like ShareGate or AvePoint is worth the license. Microsoft’s SharePoint Migration Tool is not built for SharePoint Online to SharePoint Online moves.

What happens to links after the move?

Links to moved files break. Site URL renames get a redirect; individual file moves do not. Keep the old library read-only for a set period, announce the new location per wave, and update links in Teams, on intranet pages, in bookmarks, and in any flows that reference the old path.

How long does a same-tenant restructure take?

Eight to sixteen weeks is typical for a mid-sized organization. The move itself is one to three weeks. The rest is inventory, architecture, archive decisions, and communication.