Moving from SharePoint Server to SharePoint Online: What to Plan For
Your SharePoint Server is aging. The hardware warranty expired. The version is approaching end of support. Your IT team spends more time maintaining the infrastructure than improving the platform. Your users complain that it is slow, outdated, and does not work well on mobile devices.
It is time to move to SharePoint Online. You know this. The question is how to do it without breaking things, losing data, or disrupting the business.
Having planned and executed these migrations for mid-market organizations, here is what the process actually looks like — and where the complexity hides.
Start with the Inventory You Do Not Have
Before you migrate anything, you need to understand what you are migrating. Most organizations are shocked by what they find when they actually inventory their on-premises environment.
How many site collections exist? How large are they? When was each one last modified? Who owns it? Is anyone actually using it? You will almost certainly find abandoned sites, test environments from years ago, project sites for projects that ended long before anyone thought about a migration, and sites that nobody remembers creating.
This inventory is not busywork. It determines the scope, timeline, and cost of the entire project. Without it, you are estimating in the dark.
Beyond content, you need to document every customization — custom master pages, web parts, workflows, event receivers, timer jobs, and third-party solutions. These are the things that will not move cleanly to SharePoint Online because the cloud architecture is fundamentally different. Each one needs a plan, and some may not have a direct equivalent.
The Cleanup Is the Project
The single best thing you can do for a migration is to clean up before you move. Migrating everything as-is just moves the mess from one place to another.
Abandoned sites, permission sprawl, deprecated customizations, content nobody has touched in years — all of this should be addressed before migration, not after. Organizations that skip this phase save time upfront and spend double on the back end dealing with a cluttered, confusing cloud environment.
This phase often saves more time and money than any tool or technology decision in the entire project.
Architecture: Do Not Just Recreate What You Have
The biggest strategic mistake in a SharePoint migration is recreating your on-premises structure in the cloud. SharePoint Online is a fundamentally different platform with different capabilities, and it rewards a different architecture — flatter hierarchies, modern site types, metadata-driven organization instead of deep folder nesting, and a permissions model built around groups rather than individual users.
The migration is an opportunity to redesign how your organization manages information. Taking that opportunity requires architectural planning that accounts for how your teams actually work today, not how someone set up the original environment years ago.
The Customization Problem
Customizations are the single biggest source of migration complexity, and most organizations underestimate them.
SharePoint Online does not support classic server-side customizations — Designer workflows, InfoPath forms, sandbox solutions with custom code, server-side event receivers. Each one needs a remediation path: some become Power Automate flows, some become Power Apps, some become modern SPFx solutions, and some need to be retired entirely because the capability they provided no longer justifies the effort.
For environments with significant customizations, remediation is not a side task — it is often the most time-consuming workstream of the project and needs to be budgeted and planned separately from the content migration.
Migration Strategy: It Is Not Just Moving Files
The actual data migration is the part that gets the most attention, but it is rarely the hardest part. The decisions around timing, sequencing, and cutover strategy matter more than the tool you use.
Do you move everything at once over a weekend, or phase it department by department over weeks? How do you handle the period where some content is in the old environment and some is in the new one? How do you ensure that content migrated early stays in sync with changes users make before the final cutover? How do you validate that permissions, metadata, and version history survived the move?
Each of these questions has tradeoffs that depend on your organization's size, risk tolerance, and how much downtime you can afford.
Post-Migration: Where Projects Stall
The migration is not done when the content lands in SharePoint Online. Post-migration validation, URL redirects, user support, and workflow adjustment are where projects stall if they are not planned for.
Users will have questions. Things will look different. Workflows that ran automatically in the old environment need to be rebuilt or replaced. Bookmarks and saved links point to URLs that no longer exist. DNS records need updating. And your team needs hands-on support during the transition, not just a knowledge base article.
How to Know If You Are Ready
A small environment with minimal customizations and a few dozen users can often be migrated by a capable internal team willing to invest the planning time. If your environment has significant customizations, large content volumes, regulatory requirements, or more than a few hundred users, the risk surface grows quickly — and mistakes in a migration are expensive to unwind.
The question is not whether you can move files to the cloud. The question is whether you can do it without breaking the workflows, permissions, and findability that your organization depends on.
MTRC Enterprises specializes in SharePoint migrations for mid-market organizations. We handle the assessment, architecture design, customization remediation, migration execution, and post-migration support so your team can focus on their work instead of their infrastructure. Schedule a free consultation at mtrcenterprises.com/consultation.