SharePoint On-Prem to SharePoint Online Migration: 7 Real Challenges(and How to Plan Around Them in 2026)

SharePoint Server 2019 reaches end of extended support in October 2026. That deadline
has moved a lot of migrations from “someday” to “this year,” and it’s also why third-party
migration tools have become the default rather than a nice-to-have — most environments
carry more customization than a straight lift-and-shift can handle cleanly.

The appeal of SharePoint Online is real: tighter Microsoft 365 integration, and features like
Copilot, AI-powered search, and Loop components that only exist online, not on-prem. But
the migration itself still trips up teams in the same handful of places. Here’s what actually
causes delays, and what to do about each one.

1. Deprecated templates need rework before you migrate
   Some list and site templates from older SharePoint versions no longer exist in SharePoint
   Online. If your source sites use them, plan for rework on both ends — you can’t just point a
   migration tool at them and expect a clean copy. Run a discovery pass first (Microsoft’s
   SharePoint Migration Assessment Tool, or a third-party scan) so you know which sites
   need attention before migration day, not during it.

2. Identity mapping: on-prem AD to Microsoft Entra ID
   Your on-prem users live in Active Directory; SharePoint Online uses Microsoft Entra ID (the
   current name for what was Azure AD). Don’t assume every account maps over cleanly.
   Former employees, service accounts, and external vendor accounts are the usual gaps.
   Before migrating, identify accounts with no Entra ID match and decide up front whether to
   create new accounts, map them to a placeholder, or drop the permission entirely — then
   validate the mapping with a small test migration before rolling it out broadly.

3. Workflows don’t move as-is
   Built-in workflow histories live in a different list structure in SharePoint Online, so carrying
   them forward takes deliberate mapping, not a straight copy. It’s worse for SharePoint
   Designer workflows specifically — they aren’t supported in SharePoint Online at all. The
   realistic path is rebuilding them in Power Automate, and for custom web parts, rebuilding
   as SPFx components. Treat this as a project within the project: inventory what you have,
   and decide per-workflow whether it’s worth rebuilding or worth retiring.

4. Look and feel rarely survives migration untouched
   Custom master pages and page layouts aren’t supported in modern SharePoint. If your on-
   prem sites have heavy branding or custom page structures, expect to rebuild the look in
   modern SharePoint’s design system rather than replicate it exactly. Decide early which
   customizations are worth rebuilding and which have outlived their business value — not
   everything from your on-prem environment deserves a second life online.

5. MFA adds friction during tenant-to-tenant moves
   Multi-factor authentication complicates migrations that move data between tenants. Plan
   authentication handling as its own step, particularly if your migration tool needs persistent
   access across a long-running job — MFA prompts mid-migration can interrupt automated
   transfers if this isn’t accounted for upfront.

6. Throttling will slow you down if you don’t plan for it
   Moving large volumes of content — especially tenant-to-tenant or within the same tenant
   — can trigger SharePoint Online’s throttling limits. Before migrating, clean up redundant,
   outdated, and trivial (ROT) content so you’re not wasting throttled bandwidth moving data
   nobody needs. Migrate in waves rather than all at once, and build in buffer time; a good
   migration plan assumes throttling will happen rather than treating it as a surprise.

7. Tool limitations you’ll actually hit
   Not all migration tools are equal, and free tools come with hard limits worth knowing
   before you commit to one:
   • Microsoft’s free tool doesn’t support non-Microsoft sources (Google Drive, Box,
     Dropbox) and can’t do tenant-to-tenant migrations at all.
   • Error reporting on failed items is often vague — you’ll know something failed, not
     always why.
   • Long file paths (over ~400 characters) and files with restricted characters can fail
     silently instead of throwing a clear error.
   • File size limits have grown — SharePoint Online now supports files up to 250 GB, up
     from 15 GB — but very large files still need special handling and longer transfer
     windows regardless of the new ceiling.

   For straightforward migrations, the free tool is often enough. For hub-spoke architectures,
   complex permissions, or tenant-to-tenant consolidation, paid tools (Vyapin, ShareGate,
   AvePoint, Quest/Metalogix) provide better permission preservation, pre-migration
   reporting, and support for scenarios the free tool simply can’t do.

After migration: don’t skip validation
Once each migration wave completes, confirm: – Source and target item counts match – File
sizes match – Metadata transferred correctly – Permissions apply as expected – Version
history is preserved

Set up URL redirects from old on-prem links to the new SharePoint Online locations —
users will have bookmarks and shared links pointing to the old URLs for a long time after
migration.

Facing one of these challenges right now? DocKit Migrator is built to handle template
conversion, permission mapping, and throttled transfers without the manual cleanup work
described above.