Fix SharePoint Migration Errors, Complete Setup Guide

SharePoint migration setup problems almost always trace back to permissions, either on the source, the destination, or the Azure App Registration that Migration Manager uses to authenticate. Let's lock this down first.

In the Microsoft 365 admin center, navigate to Azure Active Directory > App registrations and find the app you registered for Migration Manager. Open it, go to API permissions, and confirm you have these granted with admin consent:

Sites.FullControl.All (SharePoint)
User.Read.All (Microsoft Graph)
Files.ReadWrite.All (Microsoft Graph)

If any of those show a yellow warning or "Not granted for [tenant]", click Grant admin consent for [tenant name] and confirm. Without admin consent, Migration Manager can authenticate but silently fails on write operations, you'll see tasks complete with 0 files migrated and no useful error.

As of March 2025, Migration Manager added support for Certificate Based Authentication for Azure App Registrations when migrating file shares. If your organization's security policy blocks client secret authentication, set up a certificate in your app registration: go to Certificates & secrets > Certificates, upload a valid .cer file, then configure Migration Manager to use that certificate. This is now the recommended auth model for enterprise file share migrations.

On the destination SharePoint side, run this PowerShell to confirm site collection admin rights (replace the URL and UPN with your values):

Connect-SPOService -Url https://[tenant]-admin.sharepoint.com
Get-SPOUser -Site https://[tenant].sharepoint.com/sites/[destination-site] | Where-Object { $_.IsSiteAdmin -eq $true }

If the migration account isn't in that list, add it:

Set-SPOUser -Site https://[tenant].sharepoint.com/sites/[destination-site] -LoginName migration@yourdomain.com -IsSiteCollectionAdmin $true

When it worked: the scan job in Migration Manager completes with a green status and a populated file count. If the scan still shows 0 files or throws "Unauthorized," double-check that MFA isn't interrupting the app registration auth flow, service account credentials used in Migration Manager should use app-only auth, not interactive login.

I cannot stress this enough, identity mapping is not optional. If you skip it and migrate anyway, your files will arrive in SharePoint with broken permission inheritance. Every document that had specific user permissions on the source will show as "access denied" to those users on the destination. Cleaning that up post-migration is a nightmare that takes longer than the migration itself.

Here's how to do it right. In Migration Manager, go to Settings > Identity mapping. You have two options: auto-mapping and manual mapping.

Auto-mapping works when your source and destination user accounts share the same email addresses (common in Google Workspace to Microsoft 365 migrations). Click Auto-map and let Migration Manager match users by email. Review the results, any accounts that didn't match will show in red and need manual attention.

Manual mapping is needed for on-premises Active Directory accounts or renamed accounts post-merger. You can upload a CSV with source-to-destination mappings. The CSV format is:

SourceUser,TargetUser
domain\jsmith,jsmith@newcompany.com
domain\mwilliams,mwilliams@newcompany.com

As of May 2024, the entry limit for identity mapping increased from 50,000 to 500,000 entries, which finally makes this viable for large enterprise migrations. You can also export your current identity map to CSV, edit it externally, and re-import, useful when you need to audit mappings across thousands of accounts. The export button is at Settings > Identity mapping > Export.

One thing that trips people up: identity mapping only runs at task creation time. If you create migration tasks and then update your identity map, the existing tasks don't pick up the new mappings. You need to delete the tasks and recreate them, or use the "Copy to Migrations" panel to push updated scan results through with fresh settings.

When it worked: go back to your migration tasks and hover over the identity column, it should show a count of successfully mapped users. Any remaining unmapped users will be flagged as warnings, not blockers, but you should resolve them before starting the actual migration run.

If you're running a SharePoint migration over your WAN link and it's grinding, either taking weeks or saturating your internet connection to the point where normal work grinds to a halt, you have a real option that Microsoft specifically built for this: Azure Data Box.

Here's how the process works. You order an Azure Data Box device directly through the Azure portal at portal.azure.com > Create a resource > Azure Data Box. Microsoft ships you a physical storage appliance, typically a 100 TB ruggedized device. You copy your source data from your file servers or SharePoint Server directly onto the device using standard SMB or NFS protocols. Then you ship it back to Microsoft. Their engineers copy the data into your Azure Blob storage, and from there, you use SPMT to migrate from that Azure Blob endpoint into SharePoint. Your WAN link is completely out of the equation for the bulk data transfer.

For files specifically, here's what you need to know about size limits. As of December 2024, Migration Manager supports files up to 250 GB across all migration scenarios, file share, Google Drive, Dropbox, and SharePoint Server. Before that update, cloud migration scenarios had a 15 GB limit that caused silent failures for anyone with large video files, database exports, or design assets. If you migrated before December 2024 and noticed large files were missing from the destination, this is why, and you'll need to re-migrate those specific items.

To identify which files were skipped due to size, pull your migration report from Migration Manager: go to Migrations tab > select your task > Download report > All items. Filter the CSV by the Status column for "Skipped" and look at the Message column, size-related skips will say something like FileExceedsLimit or ItemTooLarge.

Once you've identified them, create a new migration task in Migration Manager targeting just those files and re-run. They'll migrate cleanly under the new 250 GB cap.

This step catches a lot of organizations by surprise, especially those running long-lived intranets or legacy approval processes. Microsoft removed SharePoint Server 2010 workflow services from all existing tenants on November 1, 2020. That means if you're migrating a SharePoint Server environment that has classic out-of-the-box (OOTB) workflows, approval workflows, collect-feedback workflows, anything running on the 2010 workflow engine, those will not function in Microsoft 365. They don't migrate as live workflows. The workflow definitions and associations migrate as data, but the engine that runs them doesn't exist in the cloud.

SPMT can migrate the workflow definitions and associations (the metadata about what workflows existed), but you need to rebuild the actual logic in Power Automate. Here's the practical path:

First, before you migrate, export a list of all active workflows on your SharePoint Server. Run this PowerShell against your on-premises farm:

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
$site = Get-SPSite "http://yourfarm/sites/yoursite"
foreach ($web in $site.AllWebs) {
    foreach ($list in $web.Lists) {
        foreach ($wfAssoc in $list.WorkflowAssociations) {
            Write-Output "$($web.Url) | $($list.Title) | $($wfAssoc.Name) | $($wfAssoc.BaseTemplate)"
        }
    }
}

This gives you an inventory of every workflow association across your site collection. Sort by BaseTemplate to identify 2010-engine workflows, they'll show as TodoItemWorkflow, ApprovalWorkflow, or CollectFeedback.

For each one, you need to build a Power Automate equivalent. Microsoft has pre-built templates for the most common ones, in Power Automate, search for "SharePoint approval" in the template gallery and you'll find drop-in replacements for OOTB approval workflows. The triggers map to SharePoint list item creation or modification events. For custom workflow logic, you'll need to rebuild step-by-step, but the standard approval and feedback loops take about 20 minutes each using the templates.

When it worked: after migration, open your destination SharePoint list, go to Automate > Power Automate > See your flows, and confirm the new flow is enabled and connected to the list. Run a test by creating a new list item and verifying the approval email arrives at the expected recipient.

Not every SharePoint migration involves terabytes of server data. Sometimes the problem is simpler: users have files on their local machines, their Desktop, Documents, Pictures folders, that need to move to OneDrive or SharePoint as part of the migration project. Trying to do this manually at scale is chaos. The right tool for this is Known Folder Move, built into the OneDrive sync app.

Known Folder Move redirects Windows known folders, Desktop, Documents, Pictures, Screenshots, and Camera Roll, to OneDrive automatically, without requiring users to drag anything. To deploy it across your organization, push these Group Policy settings or registry keys (both work, GPO is cleaner for domain-joined machines):

Registry path: HKLM\SOFTWARE\Policies\Microsoft\OneDrive
Value name: KFMSilentOptIn
Value type: REG_SZ
Value data: [Your Microsoft 365 tenant ID]

Value name: KFMSilentOptInWithNotification
Value type: DWORD
Value data: 1

Your tenant ID is in the Azure portal under Azure Active Directory > Overview > Tenant ID. Once this registry key is pushed via Group Policy or Intune, the next time the OneDrive sync app starts on a user's machine, it silently redirects their known folders to OneDrive, no user interaction required. The KFMSilentOptInWithNotification flag means users get a small toast notification so they're not confused about where their Desktop went.

For files that aren't in known folders, files on the user's C drive in random locations, or on a mapped network share, the easiest path is the OneDrive sync app itself. Have users open File Explorer, find the OneDrive folder in the left sidebar, and drag their files there. Yes, it's manual, but for small sets of files it's faster and less error-prone than trying to script it.

A critical note from the official documentation: migrating your content to Microsoft 365 copies the files, your source files are not deleted. This is intentional. Don't delete your source after migration until you've verified everything landed correctly, tested access with a sample of users, and run through your migration report. I've seen teams delete source data the day after migration and then discover a specific folder was excluded due to a path-length error. Keep your source intact for at least 30 days post-migration.