Transfer time is arithmetic, not a guess. Microsoft publishes maximum throughput by content type, from 10 TB a day down to 250 GB a day, and your average file size decides which figure applies. The rest of the calendar is preparation, which is where projects actually slip.
How long does a SharePoint migration take?
A SharePoint migration has two clocks. Transfer takes hours to days. The project takes weeks to months. Those are two different questions and almost every answer online blends them into one vague range.
You will find pages saying 2 to 4 weeks for a small business, 6 to 12 weeks for a mid sized one and several months above 2 TB. Those bands are not wrong, they are just useless for planning, because they describe somebody else's SharePoint migration rather than yours.
Your SharePoint migration has a transfer time you can calculate from three numbers you already own, and a preparation time that depends on decisions nobody else can make for you. Work out the first and the second stops being a mystery.
Nobody has ever missed a date because the files moved slowly. They miss it because the date was set from a storage figure before anyone counted the files.
Jamie Kaler Marketing Head and Content Strategist, RecoveryTools
What SharePoint migration throughput should you plan for?
Microsoft publishes maximum throughput for SharePoint migration by content type, and the spread between the top and bottom figure is forty to one.
| Content type | Examples | Maximum per day |
|---|---|---|
| Light metadata | ISO files, video files | 10 TB |
| Medium metadata | List items, Office files around 1.5 MB | 1 TB |
| Heavy metadata | List items with custom columns, files around 50 KB | 250 GB |
Two things to notice about those rates. None of those figures mentions your internet connection, and the thing separating them is overhead per object rather than volume.
These are maximums as well, not averages. Microsoft applies tighter limits to background apps during weekday daytime hours, so a batch running on a Tuesday afternoon will not reach the published rate. The error codes and limits behind that sit in SharePoint migration throttling.
What is the SharePoint migration timeline formula?
A SharePoint migration estimate needs three numbers, then one division. Pull them from a discovery scan rather than the admin centre.
- Total volume in gigabytes. The easy one, and the one everybody starts with.
- Total item count. Files plus list items plus every version you plan to carry.
- Average file size. Volume divided by item count. This single figure tells you which row of the table above applies.
Average file size above about 1 MB puts you in the medium band or better. Below roughly 100 KB puts you in the heavy band. Then volume divided by the daily rate gives transfer days at best case, and doubling that gives a figure you can say out loud to a business owner.
Count versions as items. A file with 60 versions is 60 objects to read and write, not one. Deciding what version history travels changes your item count more than any other setting, as SharePoint version history migration explains.
Why does 2 TB take five hours or eight days?
Same storage figure, three different answers. This is the calculation agencies skip.
| What the 2 TB is | Roughly how many items | Rate | Best case transfer |
|---|---|---|---|
| Training videos and disk images | Around 400 | 10 TB a day | Under 5 hours |
| Office documents around 1.5 MB | Around 1.4 million | 1 TB a day | 2 days |
| Small files and list items with custom columns | Tens of millions | 250 GB a day | 8 days |
Swipe the table sideways to see every column.
Three profiles, one storage number, and the answer ranges from an afternoon to over a week. Any estimate built on gigabytes alone is guessing which of those three rows you are standing in.
Then there is a multiplier most people miss. Microsoft prices a permission operation at five resource units against one for a file read, so a job carrying access rights spends its budget faster and finishes later. What travels and what does not is covered in how to migrate SharePoint permissions to another tenant.
Where does the rest of the SharePoint migration calendar go?
If 2 TB transfers in two days, why do SharePoint migration projects run eight weeks? Because transfer is the shortest phase of a SharePoint migration project.
- Discovery and assessment. Two to four weeks on a mid sized estate, longer on an old farm with custom work in it.
- Cleanup at the source. Dead accounts, per item sharing and abandoned sites. Unglamorous, and it shortens everything after it.
- Destination build. Domains verified, licences assigned, identities precreated, site architecture agreed.
- Pilot. One real site with real people, which is also where your throughput estimate gets corrected.
- Waves. Bulk content during working weeks while people carry on using the source.
- Cutover and verification. A short freeze, a delta pass, then proving what landed.
- Rebuild work. Forms, branding and workflows that no tool carries across.
Preparation usually runs 20 to 30 percent of a project calendar, and that is the part worth protecting. A SharePoint migration date set before discovery finishes is a date that moves.
What makes a SharePoint migration faster?
Four of these cost nothing and work on any SharePoint migration. Run them in this order.
- Move the batches to off peak. Evenings and weekends in the region doing the writes. Same job, several times the rate, nothing else changed.
- Add agents rather than threads. Microsoft states throughput scales linearly with the number of agents until bandwidth saturates, that an agent handles 5 to 10 tasks at once, and that there is no limit on how many agents you install. Customers run 20 or more.
- Cut the item count before the volume. Archive sites nobody opened in a year and cap version history where it earns nothing. Fewer objects beats fewer gigabytes every time.
- Flatten permission scopes at the source. Replace per item sharing with group membership and both the call count and the cost per call fall.
- Right size the packages. Microsoft recommends at least 250 files per transfer and 100 MB to 250 MB per package, so thousands of tiny transfers waste the run on overhead.
- Split the move, do not freeze the estate. Long batch during the week, short delta pass on the day. The freeze only has to span the delta.
- Stop competing jobs. OneDrive sync, backup and DLP tools running against the same content during a SharePoint migration all draw on the same budget.
Get the three numbers before you promise a date
Discovery and read only scanning run without volume limits in trial, so you can count items, average file size and permission scopes across the estate before spending anything.
No credit card, no sign-up. Runs on Windows 11, 10 and Windows Server.
Our RecoveryTools SharePoint Migrator reports item counts and sizes per site before anything transfers, and a delta pass re-runs only what changed. Sizing several workloads at once is the Tenant to Tenant Migration Tool, and the storage picture per site comes from the SharePoint Storage Analysis Tool.
What makes a SharePoint migration run long?
Every overrun I have seen traces back to something on this list, and all of it is visible during discovery.
- Millions of tiny files. The heavy metadata row of the table, found after the date was announced.
- Identities not precreated. Content lands with nothing attached, so the migration gets re-run rather than fixed.
- Custom work that no tool carries. InfoPath forms, master pages and custom workflows become a rebuild project living inside your SharePoint migration.
- A route that has no delta pass. Without one the estate freezes for the full transfer instead of a few hours.
- Long paths and oversized files. Items that fail quietly and get discovered during verification.
- Daytime batches. Weeks of running at a fraction of the published rate because nobody moved the schedule.
Pick the route before the date, because routes differ on exactly these points. They are compared in how to migrate a SharePoint site to another tenant, and Microsoft's free option has boundaries worth reading in SharePoint Migration Tool limitations.
How do you turn a pilot into a real estimate?
A SharePoint migration pilot that only proves the content arrives has wasted most of its value. Measure it instead.
Pick a site that looks like the rest of the estate rather than the easiest one. Run it at the hour you intend to run production, record items per minute instead of gigabytes per hour, then divide your total item count by that rate.
That number beats every published benchmark, because it was measured on your tenant, your licence count, your content and your network. Published maximums tell you the ceiling. A pilot tells you the floor.
Fold the result into the wider Microsoft 365 migration planning checklist rather than keeping it on a separate sheet. Then add a contingency you can defend. Double the measured transfer time and you have covered a throttled week, a failed batch and a verification pass that finds something.
Frequently asked questions
How long does a SharePoint migration take?
Transfer runs from hours to days and the project runs from weeks to months. Microsoft publishes maximum throughput of 10 TB a day for light metadata content, around 1 TB a day for Office files near 1.5 MB and about 250 GB a day for small files or list items with custom columns. Average file size decides which figure applies to you.
Why does item count matter more than total size?
Because the service meters requests rather than gigabytes. Overhead per object dominates, so 2 TB held in 400 video files can move in under five hours while 2 TB held in tens of millions of small files takes around eight days at the published rate.
Does a faster internet connection speed up a SharePoint migration?
Only once you have stopped hitting service limits. Published throughput figures are set by API budgets and overhead per object, not bandwidth. Bandwidth matters for the agent reading a local file share, and barely at all for a tenant to tenant move.
When should batches be scheduled?
Evenings and weekends in the region doing the writes. Microsoft applies tighter limits to background apps, migration tools included, during weekday daytime hours and states those apps should expect limited throughput then.
How much contingency should a migration plan carry?
Double your measured pilot transfer time, then protect the preparation phase separately. Preparation typically runs 20 to 30 percent of the project calendar, and dates announced before discovery finishes are the ones that move.
Can more agents make the transfer faster?
Yes. Microsoft states that throughput scales linearly with the number of agents until network bandwidth is saturated, that an agent runs 5 to 10 tasks at once, and that there is no limit on how many agents you install. Several agents reading one source path work against one another, so spread them across sources.
Where to start this week
Run a discovery scan and write down three figures. Total gigabytes, total items and the average file size you get by dividing one into the other.
That third number places you on Microsoft's throughput table, and the table gives you a transfer estimate in minutes rather than a meeting. Everything else about how long a SharePoint migration takes is preparation you control.
Keep a readable copy outside both tenants while the waves run. Our SharePoint Backup Tool writes one to local or network storage, and teams short on hours for a long project hand the work to our cloud migration service.
Then say the honest version out loud. Two days of transfer inside an eight week project, with the eight weeks being the part that needs defending.
Jamie blends strategic marketing insight with technical writing, turning migration and recovery topics into guidance that works for technical and general readers alike.
Published 7 October 2026. Throughput and agent figures quoted above come from the migration performance guide for SharePoint and OneDrive and the Migration Manager FAQs.