SharePoint Migration Issues: How to Fix and Avoid Them in 2026
Every SharePoint migration looks straightforward on paper: pick a source, pick a target, move the content. The reality shows up a few hours into the job, when a batch of files stalls, a user reports an access error, or a document that opened fine yesterday throws a broken link today. These SharePoint migration issues are rarely random. They trace back to specific platform limits, permission models, and file-naming rules that native tools surface only after the job is already running.
This guide walks through the checks that prevent most failures, the six problems administrators hit most often, and where a dedicated migration tool changes the outcome.
Before You Begin: A Pre-Migration Checklist for Reducing SharePoint Migration Risks
A short assessment phase catches most SharePoint Online migration challenges before they become production incidents. At minimum, verify the following on the source environment:
File and path inventory. Scan document libraries for files approaching 250 GB, paths nearing 400 characters, and names containing unsupported characters.
Permission audit. Export site, library, and item-level permissions, including SharePoint groups and any broken inheritance, so you have a baseline to compare against the target after migration.
Account status. Cross-reference every user and group referenced in site permissions or in "Created by" and "Modified by" fields against your current Active Directory or Microsoft Entra ID. Accounts that no longer exist are the orphaned users covered later in this guide.
License assignment. Confirm target-tenant accounts have an active Microsoft 365 license. Migration into an unlicensed account typically fails or gets queued indefinitely.
Compliance policies. Check whether Purview sensitivity labels or information barriers apply to the content. These can block Graph API reads and cause protected files to fail silently during transfer.
Site collection administrator rights. Confirm the migrating account holds Site Collection Administrator rights on both the source and the target, not just standard contributor or owner access.
Checked-out or locked files. Files checked out to a user, or locked by a co-authoring session, will fail to read during a scan until they're checked in.
Running this checklist against a pilot site before the full migration turns unpredictable failures into a known, fixable list.
Top Five Recurring SharePoint Migration Mistakes and How to Fix Them
The following five problems account for most support tickets during and after a SharePoint move. Each one has a distinct cause, and treating them as a single "something went wrong" bucket usually wastes more time than diagnosing them individually. These are the reasons SharePoint migrations fail.
Large Files and the 250 GB Ceiling
SharePoint Online caps individual file uploads at 250 GB. This limit is uniform across the modern web interface, the OneDrive sync client, the SharePoint mobile apps, the Teams Files tab, and the Microsoft Graph API, so switching upload methods will not get a larger file through. List item attachments have a separate, much smaller cap of 250 MB.
Two related limits catch administrators off guard during bulk moves:
Cross-geo copy or move operations are capped at 15 GB per file.
A single bulk move or copy operation is capped at 30,000 files or 100 GB of total data, whichever limit is reached first.
A migration involving several terabytes of content, in other words, is not one operation. It's dozens or hundreds of them, batched under these ceilings. Files that exceed 250 GB outright cannot be migrated as single objects; they need to be split, compressed, or excluded and delivered through another channel.
Broken Links After Migration
Broken links are one of the most common SharePoint migration mistakes reported after go-live, and they are not a bug. When a file server path or an on-premises SharePoint URL changes to a SharePoint Online address, any link hardcoded inside a document, spreadsheet formula, or wiki page still points to the old location. Microsoft's own migration guidance confirms that its SharePoint Migration Tool does not rewrite these embedded links; only navigation elements and list or library references built by SharePoint itself get updated automatically.
Metadata-driven links behave differently again. A lookup column pointing to another list item can break if the item's internal identifier changes during migration, even though the destination link in the site navigation looks correct.
The practical fix is prevention rather than repair. Before migration, identify documents with a high density of internal cross-references, such as financial models or engineering documents, and flag their owners so they can update source references once the new locations are live, rather than discovering the break during a monthly close.
Why You Receive "Access Denied" Errors During SharePoint Migration Disaster
"Access Denied" during a migration job almost always comes down to one of five causes:
The migration account lacks Site Collection Administrator rights on the target site, even if it has that role on the source.
Permission inheritance is broken at the list, library, or item level, so a role that applies at the site level never reaches the content underneath it.
The source permission model doesn't translate cleanly. NTFS-style access control lists and classic SharePoint permissions map imperfectly onto SharePoint Online's role-based sharing model, and the gap shows up as denied access rather than a clean conversion.
The account is checked out or locked by another process, blocking read access during the scan phase.
The local admin account running the migration agent lacks read access to the source share or farm.
Granting the migration account explicit Site Collection Administrator rights on the target, and confirming it before the job starts rather than after the first failure, resolves the majority of these cases without a support escalation.
Which File Names Are Not Supported in SharePoint Online?
SharePoint Online rejects specific characters, names, and path lengths. A file or folder that violates these rules gets skipped during migration and logged as an item failure rather than transferred with a warning.
Restriction
Detail
Disallowed characters
* : . < > ? / \ |/td>
Reserved names
CON, PRN, AUX, NUL, COM1–COM9, LPT1–LPT9
Leading or trailing spaces
Not permitted in file or folder names
Trailing period
Not permitted at the end of a file or folder name
Total path length
Must stay under 400 characters, including site URL, library, folders, and file name
# and %
Supported in modern SharePoint and OneDrive, though some tenants haven't enabled this and some organizations still disable it deliberately
Administrators syncing content locally through OneDrive face a second, tighter constraint: Windows File Explorer's own 260-character path limit, which can flag a file as too long even when the SharePoint-side 400-character limit still has room. Running a path-and-character scan against the source library before migration, and asking file owners to rename flagged items, avoids a batch of unexplained item failures during the actual transfer.
How Orphaned Users Affect SharePoint Migration?
An orphaned user is an account that SharePoint still references in its User Information List, in site permissions, or in fields like "Created by" and "Modified by," even though the account has been deleted or disabled in Active Directory or Microsoft Entra ID. Deactivating a departing employee's directory account does not remove their trace from SharePoint. External guest accounts, which live in Entra ID rather than the on-premises directory, can become orphaned the same way.
During migration, this creates two distinct problems. First, content that references an orphaned user in a person-or-group field can fail validation on the target, since the destination environment has no matching identity to assign. Second, error logs fill with "user not found" or "non-existent user" entries that have nothing to do with the actual migration logic, making it harder to spot genuine failures buried in the same report. Microsoft provides no built-in tool to clean these references; resolving them typically requires SharePoint Online PowerShell or Microsoft Graph PowerShell scripting against the User Information List.
Where Native Migration Tools Reach Their Limit?
Microsoft's SharePoint Migration Tool and PowerShell-based approaches handle straightforward, single-tenant moves competently, and they include a genuinely useful scan feature that flags path length and invalid characters ahead of time. Their limitations show up at scale. Bulk operations still cap at 30,000 items or 100 GB per operation, so a multi-terabyte library requires manually tracking dozens of separate batches. Authentication relies on the signed-in account's existing claims and permissions, which is exactly the pathway that breaks down during an ACL-to-RBAC translation. And neither tool checks target-tenant license status or scans for orphaned user references before the job starts, leaving those checks to the administrator's own scripts or spreadsheets.
For a single site with a modest content volume, this manual overhead is manageable. For enterprise migrations, tenant-to-tenant moves during mergers or divestitures, or any project spanning hundreds of libraries, the same manual steps repeat often enough to become the main source of delay. Anyone planning a move across tenants specifically should also review the considerations involved in a SharePoint site migration to another tenant, since cross-tenant jobs add domain, identity, and licensing steps that a same-tenant move doesn't need.
How Does the SysInfo Microsoft SharePoint Tenant-to-Tenant Migration Tool Help?
The SysInfoMS365 SharePoint Migration Tool addresses several of the operational gaps above without replacing the checks covered earlier in this guide.
It authenticates through OAuth 2.0 modern authentication with Microsoft Entra ID app registrations, using admin impersonation rather than a stored password. That model is compliant with MFA enforcement and avoids the legacy authentication paths that most often trigger permission translation failures during a migration.
For content organization, the tool supports site mapping so the target structure mirrors the source, along with custom and file-based filtering to prioritize the documents that matter most for an initial cutover. A deduplication feature identifies redundant files before transfer, which matters directly for the 30,000-item and 100 GB bulk caps: fewer duplicate files in a batch means fewer batches needed to clear a library. Incremental sync, which skips content already migrated in a prior run, lets an interrupted or paused job resume without re-transferring completed files.
Before migration starts, the tool cross-verifies target-tenant accounts against assigned and unassigned licenses, since Microsoft 365 accounts without an active license cannot receive migrated content. It does not create or assign licenses itself; that step still belongs to the tenant administrator. The tool also does not bypass Purview Information Barriers or Sensitivity Labels; if those policies restrict Graph API access to protected content, they need to be temporarily suspended and reapplied after migration completes, the same requirement that applies to any Graph API-based tool.
Two things it does not solve on its own are worth naming plainly: broken hardcoded links inside documents, and orphaned user cleanup. Both remain the same manual, scan-driven fixes described earlier, regardless of which migration tool moves the content. To evaluate and verify, explore the Best MS365 Tenant Migration Software for Mailbox, OneDrive, and SharePoint.
These are the basic steps you have to follow to migrate SharePoint to another tenant:
01
Launch the tool and choose Office 365 as both the source and destination platforms.
02
Select the SharePoint Sites workload and apply filters if you only want to migrate specific sites or content.
03
Connect both tenants by entering and validating the admin credentials for the source and destination Microsoft 365 accounts.
04
Map users and SharePoint sites to ensure content and permissions are migrated to the correct destination.
05
Review the settings and click Start Migration. Monitor the progress and verify the migration report once the process is complete.
OAuth 2.0 modern auth, Entra ID admin impersonation
Pre-migration license check
Not built in
Cross-verifies assigned vs. unassigned licenses
Duplicate handling
Manual review required
Built-in deduplication before transfer
Resuming an interrupted job
Re-scan and manual batch tracking
Incremental sync skips already-migrated items
Path/character pre-scan
Included (ScanSummary and item failure reports)
Filtering by file type/custom rules for staged transfer
Broken link correction
Not supported
Not supported
Orphaned user cleanup
Requires PowerShell/Graph PowerShell scripting
Requires the same scripting; not built in
The last two rows matter as much as the differences above them. No tool in this comparison rewrites embedded document links or automatically resolves orphaned user references, so budgeting time for those two fixes belongs in every migration plan, not just the ones using native tools.
Best Practices to Avoid SharePoint Migration Mistakes
Run the pre-migration checklist against a pilot site before scheduling the full-tenant job.
Fix path length and invalid character violations at the source; renaming after migration is harder and often breaks links that were still working.
Grant Site Collection Administrator rights on the target explicitly, rather than assuming inherited permissions carry over.
Disable or suspend sensitivity labels and information barriers only for the duration of the migration window, then reapply them immediately after.
Clean up orphaned user references before migration rather than after, since removing them post-migration means auditing two environments instead of one.
Keep a rollback plan for the pilot site so a bad batch doesn't force troubleshooting on production data.
Conclusion
Almost all SharePoint migration issues come from a small, repeatable set of causes: a file that exceeds 250 GB, a link nobody rewrote, a permission model that didn't translate, a file name SharePoint won't accept, or a user account that no longer exists anywhere but SharePoint's own records. None of these turn into a SharePoint migration disaster when they're caught during an assessment phase instead of during the transfer itself. Whether the job runs through native tools or the SysInfo MS365 SharePoint Migration Tool, the checklist and the fixes stay the same: scan first, verify permissions and licenses before the move, and treat broken links and orphaned users as their own line items rather than migration failures.
Frequently Asked Questions
What should I check before migrating SharePoint data?
Ans. Inventory file sizes and path lengths, audit source permissions, confirm target accounts are licensed, check for Purview sensitivity labels or information barriers, verify Site Collection Administrator rights on both environments, and identify any checked-out or locked files.
Can I migrate SharePoint files larger than 250 GB?
Ans. No. The 250 GB limit applies uniformly across the web UI, OneDrive sync client, mobile apps, Teams, and the Graph API. Files above that size need to be split, compressed, or handled outside the standard migration path. Bulk operations are separately capped at 30,000 files or 100 GB per operation.
Can broken links occur after SharePoint migration?
Ans. Yes. Links hardcoded inside documents, spreadsheets, or wiki pages still point to the old file server path or SharePoint URL, since migration tools update navigation and list references but not embedded links inside file content.
Why do I receive "Access Denied" errors during SharePoint migration?
Ans. The most common causes are a migration account missing Site Collection Administrator rights on the target, broken permission inheritance, an ACL-to-RBAC mismatch from the source environment, or files locked or checked out during the scan.
Which file names are not supported in SharePoint Online?
Ans. Names containing * : . < > ? / \ |, names starting or ending with a space, names ending in a period, reserved device names like CON or LPT1, and any path exceeding 400 total characters.
How do orphaned users affect SharePoint migration?
Ans. Orphaned users are accounts deleted or disabled in Active Directory or Entra ID but still referenced in SharePoint's permissions and metadata fields. During migration, items referencing these accounts can fail field validation, and "user not found" errors can clutter migration logs, making genuine failures harder to spot.