What are Microsoft 365 core workloads?
Also known as
Definition
Microsoft 365 isn't one thing to migrate. It's a collection of services, each with its own data model, permissions structure, dependencies, and migration behavior. What lives in Exchange behaves differently from what lives in SharePoint. Teams is built on top of both. Microsoft 365 Groups tie many of these together in ways that aren't always obvious.
Core workloads are the services that show up in almost every migration and governance plan: the ones with the most user impact, the most complexity, and the most dependencies. Planning around them individually rather than treating Microsoft 365 as one bucket is what separates migrations that go smoothly from ones that surface surprises after cutover.
tip
Create a workload inventory before migration. Map what you have across each workload, like volume, ownership, dependencies, and any content that needs special handling. What you don't know about before the move becomes a problem during it.
Why it matters
Exchange, SharePoint, OneDrive, and Teams each behave differently when you migrate or govern them. What works for one doesn't work for another. Here's where that difference actually shows up.
- Migration: Each workload has its own migration complexity, sequencing dependencies, and validation needs.
- Governance & security: Each workload has its own lifecycle, access controls, compliance requirements, and owner responsibilities.
- Day-to-day operations: Cleanup, consolidation, and rightsizing opportunities differ for every workload. Inactive Teams channels, stale OneDrive accounts, and orphaned SharePoint sites each need their own process.
What we see out there
Scope is always bigger than expected.
IT teams often start a workload inventory and discover more data than anticipated: sites nobody remembers, OneDrives that haven't been touched in years, mailboxes that should have been decommissioned. The scope conversation happens after planning, not before.
Frequently asked questions
Which workloads should be migrated first?
Before any content can move to a target tenant, the users it belongs to need to exist there. If you skip this step, you'll most likely spend days untangling broken permissions and orphaned accounts after the move. Get identity right first and every workload migration that follows has a solid foundation.
Once identity is set, workload sequencing is driven by dependencies. Include Exchange and Teams in the same migration batch—Teams meetings and chats depend on a successful mailbox migration and migrating them separately can cause unexpected issues. For SharePoint and OneDrive, Microsoft recommends migrating them at the same time since they share a permissions model.
How are Teams and SharePoint related?
Every Microsoft Teams team has a SharePoint team site behind it. Files shared in a Teams channel are stored in that SharePoint site. When you migrate Teams, the underlying SharePoint content has to move with it, or the channel will have broken links and missing files after cutover. You can't treat them as independent workloads.
What dependencies should I know about before starting?
The three that cause the most issues: Teams meetings depend on Exchange mailboxes, Teams channel files depend on SharePoint sites, and Microsoft 365 Groups must exist in the target before workloads that use them can be migrated. Also worth flagging: OneDrive sync configurations can't be migrated. Users need to re-establish sync manually after the move.
What should be validated after each workload is migrated?
For Exchange: confirm mailboxes, calendars, and contacts migrated completely. For SharePoint: check site structure, permissions, and navigation. For Teams: verify channel access, file links, and post history. For OneDrive: confirm personal files are present and accessible. Review migration reports for errors and warnings on each workload and use incremental migration to re-process anything that didn't transfer cleanly the first time.
