How Long a SharePoint Move Takes

How Long does a SharePoint Move Take?

Every SharePoint move 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 move rather than yours. The money follows the same pattern, broken down in SharePoint move cost.

Your SharePoint move 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.

What SharePoint Move Throughput should You Plan for?

Microsoft publishes maximum throughput for a SharePoint move by content type, and the spread between the top and bottom figure is forty to one.

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.

Published rates are maximums, not averages. Microsoft applies tighter throttling to migration, DLP and backup apps during weekday daytime hours, so a Tuesday afternoon batch will not reach the published rate.

What is the SharePoint Move Timeline Formula?

A SharePoint move estimate needs three numbers, then one division. Pull them from a discovery scan rather than the admin center.

• 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.

Files near 1.5 MB put you in the medium band, and files near 50 KB put you in the heavy band. Divide volume by the daily rate for best case transfer days, then double that figure to get a number you can say out loud to a business owner.

Why does 2 TB Take Five Hours or Eight Days?

Same storage figure, three different answers. Agencies skip this calculation.

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 Graph prices every permission operation at 5 resource units against 1 for a single item query, so a job that carries 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 Move Calendar Go?

If 2 TB transfers in two days, why do SharePoint move projects last eight weeks? Because transfer is the shortest phase of a SharePoint move project.

• Discovery and assessment. Count sites, items and permission scopes. Old farms with custom work take longer.
• Cleanup at the source. Dead accounts, per item sharing and abandoned sites. Unglamorous, and it shortens everything after it.
• Destination build. Domains verified, licenses 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 need a rebuild after the move.

Preparation fills most of the project calendar, and that is the part worth protecting. A SharePoint move date set before discovery finishes is a date that moves.

What Makes a SharePoint Move Faster?

Every step here costs nothing and works on any SharePoint move. Take them in this order.

1. Move the batches to off peak. Evenings and weekends in the region doing the writes. Microsoft says migration data throughput is highest during off peak hours.
2. Add agents rather than threads. For file share moves with Migration Manager, Microsoft states speed scales linearly with the number of agents until bandwidth is the limit, that an agent handles 5 to 10 tasks at once, and that there is no limit on how many agents you install. Microsoft says many customers move with 20 or more agents.
3. 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.
4. Flatten permission scopes at the source. Replace per item sharing with group membership and the job makes fewer permission calls.
5. Right size the packages. Microsoft recommends at least 250 files per transfer and between 100 MB and 250 MB per package, so thousands of tiny transfers waste time on overhead.
6. Split the move, do not freeze the estate. Copy the bulk early, then finish with a short delta pass on cutover day. The freeze only has to span the delta.
7. Stop competing jobs. Backup and DLP apps that touch the same content during a SharePoint move draw on the same throttling budget.

What Makes a SharePoint Move Take Longer?

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 move gets repeated rather than fixed.
• Custom work that does not carry across. InfoPath forms, master pages and custom workflows become a rebuild project living inside your SharePoint move.
• 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 limited throughput because nobody moved the schedule.

Choose 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.

How do You Build a Real Estimate From a Pilot?

Pilots that only prove the content arrives waste most of their value. Measure the rate instead.

Choose a site that looks like the rest of the estate rather than the easiest one. Start the pilot at the hour you plan to use for production, record items per minute instead of gigabytes per hour, then divide your total item count by that rate.

Your pilot number beats every published benchmark, because it comes from your tenant, your licenses, your content and your network. Published maximums set the ceiling, and the pilot shows where you really stand.

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. I double the measured transfer time to allow for a throttled week, a failed batch and a verification pass that finds something.

Frequently Asked Questions

Where to Start This Week

Start with 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 move takes is preparation you control.

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.

Published 7 October 2026. Throughput and agent figures quoted above come from the migration performance guide for SharePoint and OneDrive , the Migration Manager FAQs and the SharePoint Online throttling guide.