The question that sits at the back of every SharePoint migration conversation is rarely asked out loud. What if we get there and something critical doesn’t work?
It’s the anxiety that causes organizations to delay. Not the cost, not the timeline, not even the complexity, but the fear of discovering halfway through that a business-critical process doesn’t have a modern equivalent, and that the decision to migrate has broken something that previously worked fine.
It’s a legitimate concern. Some things do not migrate cleanly from SharePoint 2016 or 2019 to SharePoint Online. Some things don’t migrate at all. And some things that technically move across will cause problems later if they’re not dealt with before they do.
This piece gives you the honest picture. What moves. What doesn’t. And what needs to be rebuilt along with what replaces it.
The three categories every IT leader needs to understand
Not everything in a SharePoint migration falls into a simple yes/no bucket. The more useful frame is three categories:
- Migrates cleanly: content and structure that moves across without significant rework
- Migrates with caveats: things that technically transfer but require attention, testing, or decisions before and after
- Doesn’t migrate: functionality that has no direct equivalent in SharePoint Online and must be rebuilt, replaced, or retired
The third category is where most migration anxiety lives. And it’s also where the real planning work happens.
What migrates cleanly
The good news first. The majority of what lives in a typical SharePoint 2016 or 2019 environment will move to SharePoint Online without significant drama.
Document libraries and files
Files, folders, and document libraries migrate well. Version history transfers. Metadata transfers. File permissions transfer, including item-level permissions, though complex inherited permission structures may need review and simplification before migration.
The SharePoint Migration Tool (SPMT) — Microsoft’s free migration utility — handles this reliably for standard document libraries. For larger or more complex environments, third-party tools provide more granular control and reporting.
Lists and list data
SharePoint lists migrate cleanly, including custom columns, views, and list data. The modern list experience in SharePoint Online is faster and more capable than classic lists — most teams find this a visible, immediate improvement.
Modern pages and news
If your SharePoint 2016 or 2019 environment already uses modern pages — which were introduced in SharePoint 2016 — those transfer well. Modern web parts carry across. The experience on the other side is largely consistent.
Permissions and groups
Site permissions, SharePoint groups, and user access rights migrate. As noted above, the more complex and nested the permission structure, the more it benefits from simplification before migration rather than after.
Site structure
Site collections, sub-sites, and hub site relationships can be recreated in SharePoint Online. Many organizations use migration as an opportunity to flatten their architecture — moving from deeply nested sub-site structures to the flatter, hub-connected model that SharePoint Online is designed around. This is worth doing intentionally rather than just recreating the old structure in a new place.
What migrates but needs attention
Permissions complexity
Permissions technically migrate, but on-premises SharePoint environments accumulate years of inherited and broken permissions that were manageable when the content was static. In SharePoint Online, where content is more accessible and search is more powerful, those permissions gaps matter more.
The right approach is to audit and simplify permissions before migration, not assume they’ll sort themselves out on the other side.
Large files and storage limits
SharePoint Online has a 250GB per-file limit, which is higher than most organizations will encounter. But very large file shares, particularly those that have accumulated over many years, can create unexpected transfer times and storage costs. Knowing your data volume before migration starts is essential — this is one of the first things Cloudwell establishes in the assessment phase.
Classic pages
Classic SharePoint pages technically migrate, but they arrive in SharePoint Online looking exactly as they did on-premises — which is to say, they look dated. They won’t benefit from the modern SharePoint Online experience. Most organizations use migration as the moment to rebuild key pages in the modern format, rather than carrying across a classic page that immediately needs replacing anyway.
External sharing and guest access
If your on-premises SharePoint had external sharing configured, that configuration doesn’t automatically transfer. SharePoint Online’s sharing model is different — and considerably more powerful, with options for domain-restricted sharing, time-limited links, and sensitivity-based access controls. These need to be configured deliberately in the new environment, not assumed to carry across.
For organizations with significant IP or compliance requirements — like the global pharmaceutical company Cloudwell recently worked with — getting the sharing model right is one of the most important decisions in the whole migration.
What doesn’t migrate to SharePoint Online
This is the section most people skip to — and the one that takes the most planning time. Here’s the honest list.
SharePoint 2013 workflows — deadline: April 2, 2026
SharePoint 2013 workflows cannot be migrated to SharePoint Online. They must be rebuilt in Power Automate. Microsoft has confirmed these workflows will be fully retired across all tenants on April 2, 2026 — which means this isn’t just a migration consideration, it’s an independent deadline that’s already passed for new tenants.
For simple approval workflows, the rebuild in Power Automate is relatively quick. For complex, business-critical processes — particularly in regulated industries where workflows are tied to compliance procedures — redesign, testing, and validation take significant time.
If your environment has active SharePoint 2013 workflows, treat them as your first planning priority, not a late-stage task. Full breakdown of the April 2026 workflow deadline
SharePoint Add-Ins — deadline: April 2, 2026
SharePoint Add-Ins — a framework used to build custom functionality and third-party integrations — stop working in SharePoint Online after April 2, 2026. Any custom solutions or packaged third-party tools built on this model cannot be migrated as-is.
Replacements depend on what the Add-In does. Custom functionality needs to be rebuilt using SharePoint Framework (SPFx) extensions or Power Platform solutions. Third-party Add-Ins may have modern equivalents in AppSource, or may need to be replaced with different tools entirely.
InfoPath forms — deadline: July 14, 2026
InfoPath Forms Services is scheduled for retirement after July 14, 2026. If your organization uses InfoPath forms for data collection, approvals, or any business process, those forms need to be rebuilt in Power Apps before or during migration.
In practice, Power Apps forms are more capable than their InfoPath equivalents — they connect to a broader range of data sources and work across devices. But the rebuild takes time, particularly for complex forms with significant business logic. In the Cloudwell pharma migration, custom forms were one of the primary reasons the project needed specialist developer resource alongside the migration work.
Classic SharePoint web parts
Classic web parts don’t have direct equivalents in the modern SharePoint Online experience. Content Editor, Page Viewer, Form web parts, and many others either don’t exist in modern SharePoint or work very differently.
Some functionality can be recreated using modern out-of-the-box web parts. More complex requirements need SPFx custom development. Either way, classic web parts should be inventoried early — they’re often more numerous than IT teams expect, because they’ve accumulated quietly over years.
SharePoint Designer customizations
SharePoint Designer 2013 is deprecated and not supported beyond the July 2026 window. Any customizations built using SharePoint Designer — including workflow-driven processes, custom list forms, and site template modifications — don’t carry forward to SharePoint Online.
This is a wider category than most organizations realize. SharePoint Designer was the path of least resistance for a long time, which means a lot of environments have more Designer-based customization in them than anyone formally documented.
Recurring events in classic SharePoint calendars
This one catches people off guard. Modern SharePoint Online doesn’t support recurring events in the same way classic SharePoint calendars did. Teams that have relied on SharePoint calendars for years of recurring events — training schedules, operational rosters, compliance review cycles — find that functionality simply isn’t there in the modern experience.
Cloudwell’s Calendar Overlay product was built specifically to solve this. It renders existing classic calendar data — including recurring events and historical records — in a modern SharePoint experience, without requiring teams to rebuild their scheduling infrastructure from scratch. It was deployed across multiple teams in the pharma migration for exactly this reason.
Classic Business Intelligence components
Classic SharePoint BI components — including older dashboard and reporting tools built on the classic SharePoint framework — don’t exist in modern SharePoint Online. Reporting and analytics requirements need to be rebuilt using Power BI, which is both more capable and better integrated with the Microsoft 365 ecosystem.
Custom master pages
Classic SharePoint master pages and custom branding built on them don’t transfer to SharePoint Online, which uses a completely different theming model. Branding needs to be rebuilt using SharePoint Online’s site designs, theme configurations, and modern page layouts. For organizations with complex or heavily branded environments, this is a design project as much as a technical one.
There's a fourth category and it's the most important one
Everything above describes what is technically possible to migrate. But there’s a parallel question that determines whether a migration actually delivers value: what should you migrate?
As Cloudwell developer John Becher put it: “You don’t want to spend time and money migrating content or rebuilding workflows that no one actually uses anymore. That’s where SharePoint migrations quietly lose value.”
An on-premises SharePoint environment that’s been running for ten or fifteen years contains years of accumulated operational memory — documents that outlived the projects that created them, sites that survived multiple reorganizations, workflows built for processes that no longer exist. Migrating all of it doesn’t just waste time and money. It imports the mess into a modern platform where it’s harder to untangle, and where AI tools like Copilot will surface it confidently alongside current, trusted content.
The organizations that get the most from SharePoint Online use migration as a reset: deciding what content is current, owned, and worth carrying forward before a single file moves.
Read our blog: Your SharePoint Migration Isn’t a Technical Project — It’s a Content Decision
Quick reference: what migrates and what doesn't
Feature / capability | Migrates to SharePoint Online? | Replacement / action required |
Document libraries and files | Yes | None — transfers cleanly |
SharePoint lists and data | Yes | None — transfers cleanly |
Modern pages | Yes | None — transfers cleanly |
Permissions and groups | Yes, with review | Simplify complex structures before migration |
Classic pages | Technically, but limited | Rebuild in modern page format |
SharePoint 2013 workflows | No — April 2, 2026 deadline | Rebuild in Power Automate |
SharePoint Add-Ins | No — April 2, 2026 deadline | Rebuild in SPFx or Power Platform |
InfoPath forms | No — July 14, 2026 deadline | Rebuild in Power Apps |
Classic web parts | No | Modern web parts or SPFx custom development |
SharePoint Designer customizations | No | Power Automate, Power Apps, or SPFx |
Recurring calendar events | Not natively | Cloudwell Calendar Overlay |
Classic BI components | No | Rebuild in Power BI |
Custom master pages | No | Rebuild using SharePoint Online theming and site designs |
What this means in practice
Knowing what doesn’t migrate is not a reason not to migrate. It’s the planning information you need to do it properly.
The organizations that struggle are the ones that discover these constraints mid-project — after timelines are locked and stakeholders have been briefed on a scope that turns out to be wrong. The ones that succeed treat the dependency audit as the first step, not an afterthought.
That means identifying your SharePoint 2013 workflows before April 2026. It means knowing which InfoPath forms are still in active use. It means understanding which web parts will need custom development, and how that affects your timeline and resource plan. The migration readiness checklist walks through how to do this systematically.
None of this is insurmountable. Power Automate is a more capable workflow platform than SharePoint 2013 workflows ever were. Power Apps builds forms that work across devices and connect to far more data sources than InfoPath could. And a migration handled properly — with the rebuild work scoped and resourced alongside the content migration — lands organizations in a significantly better position than where they started.
The anxiety about what doesn’t migrate is understandable. The answer to it isn’t to delay — it’s to plan early enough that the rebuilds are finished before the deadline arrives.
Not sure what your environment contains?
Cloudwell’s migration assessment covers exactly this: a full inventory of your SharePoint environment, dependency mapping across workflows, forms, and customizations, and a clear picture of what’s involved in getting you to SharePoint Online before July 14, 2026.