A Microsoft 365 migration runs late for reasons you could have seen on day one. Count objects instead of gigabytes, agree up front what gets rebuilt at the far end, and confirm which licences your route needs. Those three answers set your window, your budget and your cutover weekend.
Why does a Microsoft 365 migration run late?
A Microsoft 365 migration rarely slips because somebody picked a slow tool. It slips because nobody measured the source.
I've sat in enough kickoff calls to know how this goes. Somebody reads a storage number off the admin centre, divides it by a throughput figure from a vendor page, and announces a date. Four weeks later that date moves, because storage was never what the clock runs on.
Microsoft 365 throttles per request, not per gigabyte. So 400 GB spread across 1.2 million small files takes far longer than 400 GB sitting in a few large ones. Count objects and your estimate stops being a guess.
Every migration I've watched go wrong went wrong in week one, on a spreadsheet, long before anybody touched a migration tool.
Jamie Kaler Marketing Head and Content Strategist, RecoveryTools
What do you inventory before a Microsoft 365 migration?
Take inventory first, because every later number depends on it. Run discovery against your source tenant before anybody quotes a date.
You want four figures out of that discovery pass.
- Sites and subsites. How many exist, and how many still get opened.
- User accounts holding data. Count accounts with content behind them rather than licences issued.
- Item count. Files, list items and versions, counted separately.
- Cold content. How much hasn't been touched in three years.
That fourth figure pays for itself. Archived material costs exactly what live material costs to move, and nobody opens it on the far side.
Count objects, not storage. Your admin centre reports gigabytes. Migration speed follows item count, so a report saying 400 GB tells you far less than one saying 1.2 million items.
What should you clean up before you migrate?
Anything you move is something you pay to move twice, once in transfer hours and again in storage. Cleaning up first is the cheapest hour in your entire project.
Work through four piles before transfer starts.
- Stale sites. Sites with no activity in 12 months. Archive them to a file system instead of moving them.
- Orphaned content. Files owned by accounts that left. Reassign an owner now or lose the audit trail later.
- Version bloat. A library keeping 500 versions per file multiplies your item count, so cap it while you still have time to re-run the pilot.
- Duplicates and ROT. Redundant, outdated and trivial content usually accounts for a quarter of a mature tenant.
Get sign off on what gets archived rather than moved. A department that finds its old site gone on Monday will escalate, even when nobody opened it for two years.
Do built in Microsoft tools cover your migration route?
Check this before your budget meeting, because for tenant to tenant work the answer is usually no. Microsoft documents these boundaries on its own pages.
SharePoint Migration Tool moves content from SharePoint Server on premises into Microsoft 365. Microsoft states it can't move content from another Microsoft 365 tenant. Migration Manager covers file shares, Google, Dropbox and Box, so it doesn't fill that gap either. Mover, which used to handle part of this, retired at the end of October 2024. The full list of SharePoint Migration Tool limitations is worth reading before anybody budgets around it.
Microsoft does sell a native tenant to tenant route, and it's licensed separately. SharePoint content is priced per 100 GB moved and offered to Enterprise Agreement customers. OneDrive needs a per user add on licence, and Microsoft warns migrations fail without it.
So your route is what sets your licence bill. Price both paths before you commit to either.
Is your destination tenant ready to receive data?
A destination tenant that is not ready turns a clean Microsoft 365 migration into a failed one. Build it before you schedule anything.
- Verify your domains. Domain verification and MX record changes have their own propagation time, measured in hours.
- Assign licences first. Microsoft 365 will not write into a mailbox or a OneDrive that has no licence behind it. Licence the accounts, then migrate.
- Create your site structure. Agree naming and hub architecture up front, because renaming sites after transfer breaks every link again.
- Set storage quotas. Default OneDrive quotas are smaller than many source accounts, and jobs fail silently on full targets.
Run one small transfer into the new tenant before your pilot. It surfaces licence and quota problems while they still cost minutes. Teams without spare hands for this stage often hand it to our cloud migration service.
What survives a Microsoft 365 migration and what gets rebuilt?
Your data moves across. Most of your configuration does not, and sorting out which is which in week one is what stops arguments on cutover night.
Files, folder structure, metadata and version history all travel across when your tool supports them. Permissions travel when identity is mapped first.
Power Automate flows, retention policies, sharing links, Teams app tabs and anything wired to a tenant ID get rebuilt by hand. Write that rebuild list in week one and give it an owner. Teams moves carry extra weight here, because tabs and apps rebuild rather than transfer. Our Teams Migration Tool page lists what moves and what does not.
Older mailbox work has its own rules. If part of your estate still sits in Exchange or in PST files, our post on how to migrate Outlook emails to Office 365 covers that track, and Exchange Server Migration Tool runs it. Both stay separate from your SharePoint content.
How do you size a Microsoft 365 migration window?
One timed pilot turns your Microsoft 365 migration schedule from a guess into arithmetic, so measure something real before you promise a date.
- Pick a representative site. Average size, average item count, real permissions.
- Run it end to end and time it. Record items per minute, not megabytes per second.
- Divide your total item count by that rate. Now you have hours.
- Add 40 percent. Throttling, retries and overnight gaps are real and they always land.
A pilot costs you a day. A date pulled out of the air costs you a quarter. Here's what that difference looks like on paper.
| Planning decision | Without a pilot | With a timed pilot |
|---|---|---|
| Window estimate | Based on a storage figure | Based on measured items per minute |
| Version history | Discovered mid transfer | Decided up front, full or capped |
| Licence count | Guessed, then topped up | Taken from your discovery report |
| Rebuild list | Written on cutover night | Agreed in week one |
| Rollback plan | Delete and retry | Source kept read only |
Swipe the table sideways to see both columns.
Who owns what after a Microsoft 365 migration?
Identity is the control plane for your move. Map it before anything transfers, because permissions ride on it.
One CSV pairing every source account with its destination account solves most of this. Build it from your discovery report, not from a licence list.
Two cases need a decision in advance. Departed employees who still hold permissions on live content, and external guests invited by your old tenant rather than stored inside it. Guests don't come across. Somebody re-invites them, and that somebody needs naming now.
Mailbox and contact ownership follows the same logic. Teams rosters break quietly when identity mapping is skipped, and so does anything rebuilt afterwards, including exporting Office 365 contacts to Teams.
Which security settings need deciding first?
Security settings decide whether your Microsoft 365 migration tool can even connect, so they belong in week one rather than on cutover night.
Four of them block transfers more often than anything else.
- Multi factor authentication. Your migration account needs either an exclusion or app level access. Tools stall silently on an MFA prompt nobody sees.
- Conditional access policies. Location and device rules will block a migration service running from somewhere your policy does not expect.
- External sharing policy. Your new tenant often ships tighter than your old one, so shared content lands locked down.
- Retention and sensitivity labels. Labels do not travel. Rebuild your policy at the destination while the libraries are still empty.
Write down which account runs your migration and what it is allowed to do. Auditors ask for exactly that line six months later.
How do you prepare users for the move?
A Microsoft 365 migration can be technically perfect and still feel like an outage to the people using it. Preparation is what closes that gap.
Tell people three times. Two weeks out, two days out, and on the morning itself. Keep every message to what changes for them, not what changes for you.
- Run a pilot group. Pick 10 users across 3 departments, move them a week early and collect what breaks.
- Send one page of instructions. New sign in address, what to expect on first open, who to contact.
- Name your champions. One person per department who answers the small questions so your service desk keeps the big ones.
- Warn your service desk. Ticket volume roughly doubles in week one. Staff for it or your migration gets blamed for the wait.
Your pilot group also gives you honest timing. People report slow search and missing links long before any report does.
How should cutover weekend run?
Split the move in two and cutover weekend stops being frightening. Move bulk content during the working week, then run a short incremental pass on the day.
- Run your long batch early. Start it days ahead while people keep working, because a copy only job reads your source and never writes to it.
- Freeze new work briefly. A few hours covers it. Your freeze only needs to span the delta pass.
- Run your delta pass. Incremental mode moves what changed since your batch, so nothing arrives twice.
- Switch your links. Email signatures, Teams tabs and department bookmarks all point at your old address until somebody changes them.
- Keep your source read only. Don't delete anything on the day. Weeks of overlap cost nothing and answer every question that follows.
Route by route, the tools that run these passes are SharePoint Migration Tool, Teams Migration Tool and OneDrive Migration Tool. For mailbox heavy estates, Office 365 Migration Tool handles that side. Taking one site at a time? Our walkthrough on how to migrate a SharePoint site to another tenant runs the same order start to finish.
Size your own estate before you plan a date
Discovery and read only scanning run without volume limits in trial, so you can count sites, accounts and items across your tenant before spending anything.
No credit card, no sign-up. Runs on Windows 11, 10 and Windows Server.
What do you verify after a Microsoft 365 migration?
Five checks catch almost everything that surfaces in week one, so run them before anybody sends the all clear email.
- Item counts match. Compare source against destination per site rather than as one total.
- Permissions resolve. Spot check 10 users across 3 sites, including one guest.
- Version history landed. Open a file you know had 12 versions.
- Sharing links work. Old links point at your old tenant and die quietly.
- Search returns content. Indexing lags transfer by hours, sometimes a day.
Keep a copy outside both tenants while you check. Office 365 Backup Tool holds that copy outside both tenants, so a failed verification costs you an afternoon instead of a dataset.
Frequently asked questions
How far ahead should Microsoft 365 migration planning start?
Start discovery at least four weeks before your target date. That leaves room for a timed pilot, a rebuild list and a licence purchase without anybody rushing scope.
Does a Microsoft 365 migration delete anything from the source?
It shouldn't. A copy only job reads your source and never writes to it, so people keep working while it runs and there's nothing to roll back if settings were wrong.
Why does item count matter more than total size?
Microsoft 365 throttles per request rather than per gigabyte. A million small files take far longer than the same storage held in a few large ones, and every file version counts as its own object.
What gets missed most often in Microsoft 365 migration planning?
Three things turn up late again and again. Version history rules, departed users who still hold permissions, and sharing links pointing at your old address after everyone has moved.
Do we need to migrate archived content at all?
Often no. Content untouched in three years can be exported to a file system instead, which keeps it available for audit without paying to move it into your new tenant.
How long should the source tenant stay alive?
Keep it read only for a few weeks after cutover. It costs very little, and it answers every question about a missing file without anybody guessing.
Where to start this week
Run discovery and write down four numbers. Sites, accounts, items and how much content nobody has opened in three years.
Those four numbers turn every later argument into arithmetic. Your date stops being an opinion and starts being a calculation.
So before your next planning call, answer the question that sets everything else. Do you know how many items sit in your source tenant right now?
Published 30 September 2026. Microsoft limits quoted above come from the SPMT FAQ, the Migration Manager FAQ, the Mover retirement timeline, the cross tenant SharePoint migration page and the cross tenant OneDrive migration page.