8 min readWhat Gets Migrated in a OneDrive Tenant to Tenant Migration?

When planning a Microsoft OneDrive tenant to tenant migration, one of the first questions is: what actually gets migrated, and what does not?

That question matters because migration results are not limited to files alone. IT teams also need to understand what happens to folder structure, permissions, version history, metadata, and shared links.

This guide breaks down what Apps4.Pro migrates in a OneDrive tenant-to-tenant migration, what it does not migrate, and where workarounds are needed.

The Full OneDrive Migration Scope Table

The table below provides a high-level view of Microsoft 365 OneDrive migration scope before each item is explained in more detail. 

Want the full scope across all Microsoft 365 workloads, Exchange, Teams, SharePoint, and more? Check out the Apps4.Pro What Gets Migrated knowledge base. 

What Migrates Successfully

OneDrive Files

This one’s straightforward. Every file in a user’s OneDrive – documents, spreadsheets, presentations, images, videos, PDFs, code files, you name it – gets migrated to the target tenant.

Apps4.Pro uses the Microsoft Migration API under the hood, which means you’re getting native, high-throughput transfers at speeds between 500 GB and 1 TB per day depending on your tenant conditions.

The bottom line? Your users open their OneDrive in the new tenant and everything’s right where they left it. No manual re-uploads, no missing files.

Folder Structure

Microsoft OneDrive folder structure is preserved so users can navigate the destination OneDrive exactly as they did in the source. Apps4.Pro recreates the full folder, subfolder, and nested folder hierarchy in the target tenant.

The good news is Apps4.Pro rebuilds your entire folder tree in the target before moving any files. Every folder, subfolder, and nested directory gets recreated with identical paths. So, when users log in post-migration, their navigation is exactly the same. No reorganizing, no confusion.

Unique File and Folder Permissions

Direct file and folder-level permissions are preserved when identity mapping is configured correctly. If you’ve broken inheritance on specific files or folders and granted access to particular users or groups, those direct permissions, including Edit and View access, do migrate.

Here’s how it works: Apps4.Pro reads the permission settings (technically called Access Control Lists) on each item in the source OneDrive, then maps those source identities to their equivalents in the target tenant using the user/group mapping you configure. The mapped permissions get applied to the matching items in the destination.

Empty Folders

This is a small detail that makes a big difference. A lot of M365 OneDrive migration tools quietly skip empty folders to save time. But those “empty” folders? They often project templates, placeholders for upcoming work, or part of a department’s standard folder structure.

Apps4.Pro keeps them. Every empty folder gets created in the target, so your organizational structure stays complete, even the parts that don’t have content yet.

File Versions

OneDrive Version history matters, especially for compliance, auditing, and those “I accidentally overwrote the whole document” moments. Apps4.Pro migrates a configurable number of versions for each file.

Your users will still be able to roll back changes, compare versions, and keep their audit trails intact.

You can also review document version control in SharePoint for strategies on managing version history effectively.

Metadata

Metadata such as Created By, Created Date, Modified By, and Modified Date can be preserved when files and folders are newly created in the destination during M365 Tenant migration.

This matters a lot for compliance and auditing. When your legal team asks “who created this file and when?” the answer will be accurate. The Migration API supports writing these properties during the initial upload, so everything lines up correctly from day one.

What Does Not Migrate

Microsoft 365 OneDrive tenant to tenant migration preserves every element exactly as it exists in the source. In Apps4.Pro, the main limitations are shared links, metadata on items that already exist in the destination, and permissions on items that were already migrated in an earlier pass.

Share Link Permissions

This is the one that catches people off guard. If someone shared a file using “Anyone with the link,” “People in your organization,” or a “Specific people” link, those links do not survive the migration.

Here’s the thing: sharing links aren’t just permissions, they’re unique, tenant-specific URLs. They’re tied to your source tenant’s domain, internal IDs, and sharing tokens. When you move to a new tenant, all of that changes. There’s simply no way to recreate those URLs in a different tenant, because the underlying infrastructure is completely different.

What does it mean for your users: Anyone who was accessing files through a shared link will lose access. The file won’t show up in their “Shared with me” view. The content owner will need to re-share it with the new tenant.

Workarounds:

• Pre-migration: Audit sharing links in the source tenant using SharePoint admin reports or PowerShell. Identify files shared exclusively via links and document the intended recipients.
• Post-migration: Re-create sharing links manually in the target tenant, or convert critical shares to direct permissions (which are migrated) before migration.
• Communication: Notify users before migration that shared links will break and provide instructions for re-sharing.

Metadata for Existing Files/Folders

It applies whenever a file or folder with the same name already exists in the target tenant.

If Apps4.Pro finds an existing file or folder in the destination, it does not overwrite that item. Because the item is not recreated, its metadata also remains unchanged. That means values such as Created By, Created Date, Modified By, and Modified Date are not refreshed in the target.

Workarounds:

• Get it right the first time: Enable metadata migration on your first full migration pass to ensure accurate timestamps from the start.
• Delete and re-migrate: If metadata accuracy is critical for specific files, delete them from the target and re-run the migration. This is impractical at scale but viable for high-priority documents.
• PowerShell correction: Use SharePoint PnP PowerShell to manually update metadata (Created/Modified dates and authors) on specific files post-migration.

Permissions on Existing Files and Folders

The same rule applies to permissions. If a file or folder with the same name already exists in the target tenant, Apps4.Pro does not overwrite it, and its existing permissions remain unchanged.

Permissions are applied when a file or folder is created in the destination. If the item already exists, that creation step is skipped, so the permission-setting step is skipped as well. As a result, Apps4.Pro does not overwrite or refresh permissions on existing target items.

This means that when matching files or folders are already present in the destination, their access settings stay as they are in the target, even if the source item has different permissions.

Workarounds:

• Get it right the first time: Ensure user and group mapping is fully configured before the first migration creates items in the target so permissions are applied correctly from the start.
• Delete and re-migrate: If permissions on an existing target item need to match the source, delete the item and re-run the migration so permissions are applied during creation. This is not practical at scale but works for high-priority items.
• Manual correction: Use SharePoint PnP PowerShell or Microsoft 365 admin tools to update permissions on specific files or folders after migration.

Your Pre-Migration Checklist

Based on everything above, here’s what you should nail down before hitting “Start Migration”:

1. Get your user and group mapping right – This is the single most important thing you’ll do. Every source identity needs a matching target identity, or permissions won’t apply.
2. Enable metadata on your first pass – You only get one shot at setting accurate metadata. Miss it, and you’re stuck with manual cleanup.
3. Audit sharing links – Find out what’s shared via links, document the recipients, and convert critical shares to direct permissions before migration.
4. Tell your users what to expect – A brief communication about shared links breaking and the need to re-share goes a long way. Set expectations early and your support queue stays manageable.

For the complete setup walkthrough, follow the OneDrive for Business migration guide.

For the complete migration walkthrough, visit the OneDrive for Business migration guide. For enterprise-scale planning across all Microsoft 365 workloads, explore the full migration scope table.

Frequently Asked Questions