SharePoint articles
How long does a SharePoint migration really take, and where the weeks go
How long does a SharePoint migration take? For most small-business tenants the calendar is set by decisions and approvals rather than by the copy. The transfer runs in the background while people keep working; the elapsed weeks go on discovery, structure and permission design, a pilot, a cutover window everyone can live with, and hypercare afterwards. This guide breaks the project into phases, names the conditions that stretch each one, and flags the quiet delays that never make it onto a plan.
The transfer is not the thing you are waiting for
Two clocks run during a migration and only one of them is visible. The first is machine time: packaging content, pushing it through Microsoft’s migration service, writing it into libraries. The second is human time: someone deciding what does not move, someone confirming who should have access, someone choosing a weekend when the finance team is not closing the month. Machine time is measured in hours and largely runs unattended. Human time is measured in weeks and is what your date actually depends on.
That is why two projects with identical data volumes can finish a month apart. It is also why “how big is the share?” is a poor opening question and “who can approve a permission model by Friday?” is a good one. The mechanics of the passes themselves — tools, waves, validation — are covered in our file server to SharePoint migration playbook; this page is about the calendar those mechanics sit inside, whatever the source system happens to be.
The phases, and what sets the clock in each one
Almost every migration moves through the same five phases, in the same order, regardless of where the content lives today. Microsoft’s own migration guidance for file shares (opens in new tab) describes the same shape — plan, assess and remediate, prepare the destination, migrate, onboard users — and recommends a pilot group before the rest of the organization follows. The table below is that sequence with the question that actually ends each phase, because a phase ends when a decision is signed off, not when an hour is logged.
| Phase | What has to be true before it ends | Short when… | Long when… |
|---|---|---|---|
| Discovery and assessment | Every source is scanned, and each top-level folder has a keep, archive or delete decision against it | One or two sources, one person who knows the content, and permission to archive without a committee | Several sources, nobody willing to call anything obsolete, or a scan that surfaces blocked file types and over-long paths to remediate first |
| Design and permission mapping | Target sites and libraries are agreed, and the access model is approved by someone who can say no | Access already follows departments and maps onto existing Microsoft 365 groups | Years of per-person grants, folders shared with outsiders, or three departments that each want to be the exception |
| Pilot | One department is fully moved, working in the destination, and its problems are written down | The pilot group is picked in advance and is willing to report friction | The pilot is chosen for being quiet rather than representative, so nothing useful is learned and the issues arrive later at full scale |
| Waves and cutover | Each wave is validated against the source, and the final incremental pass lands in the agreed window | Waves by department, the old source left read-only, and a cutover window outside a busy period | A single big-bang weekend, a freeze period nobody mentioned, or checked-out and open files still locked at the last pass |
| Hypercare and onboarding | People can find their work, sync is set up, and the “where did it go?” questions have stopped | Training happened before cutover, not after, and the read-only source is still reachable | No training, no documentation, and the old source deleted on cutover night so there is nothing to compare against |
For a small business with a defined content set and a named decision-maker per department, we deliver this shape as a fixed-fee project inside our typical two-to-four-week window, with 30 days of hypercare after cutover. That figure describes projects we have scoped, not a promise about a tenant we have not seen — and the honest version of any duration quoted before discovery is that it is a guess dressed as a commitment.
What quietly adds weeks
Delay in a migration is rarely one dramatic failure. It is a handful of items that each look like an afternoon on the plan and each turn out to need somebody else’s attention. These are the ones that recur, with the question that defuses each before it reaches the critical path.
| What adds the time | Why it costs calendar, not just effort | The question that settles it early |
|---|---|---|
| Permission remediation | Reconstructing who should have access is archaeology, and it stalls every time it needs an approval that only one person can give | Who signs off access for each department, and can they do it within a day? |
| Version history | Retained versions multiply what has to be packaged, transferred and validated, well beyond what the folder size suggests | How much history do we genuinely need, and for which libraries? |
| Checked-out and locked files | Files open in an application or left checked out do not settle on their own, and they resurface at the final pass when there is no slack | Who chases the owners of open documents, and by when? |
| Custom web parts, workflows and forms | Anything custom is rebuilt rather than copied, and each rebuild needs a business owner to confirm it is still used | Which of these has actually run this year? |
| User and account cleanup | Leavers, duplicates and unresolvable local accounts break the mapping between source identities and destination users | Is the user list current, and who owns the content of people who have left? |
| Blocked names, paths and file types | Remediation is a bulk edit, but only after someone has agreed the renaming and restructuring rules | Who approves renaming folders that people have used for a decade? |
| Service throttling and transfer windows | Heavy passes belong in evenings and weekends, which caps how much ground a single working week can cover | Which nights and weekends are available before the deadline? |
Microsoft’s published ceilings, and the throttle you cannot negotiate
Transfer speed is one of the few parts of this with real published numbers, and they are worth knowing so you can stop worrying about them. Microsoft’s migration performance guide for SharePoint and OneDrive (opens in new tab) gives maximum daily throughput by content profile, and the pattern is consistent: large files move fast, many small files and list items move slowly, and metadata is the tax.
| Content profile | Microsoft’s published maximum | What it means for your calendar |
|---|---|---|
| Light metadata — ISO images, video files | Up to 10 TB per day | Transfer is effectively never the constraint; the constraint is what you decided to bring |
| Medium — Office documents around 1.5 MB, list items | Up to 1 TB per day | A typical small-business content set clears comfortably inside an overnight or weekend window |
| Heavy — small files around 50 KB, list items with custom columns | Up to 250 GB per day | Millions of tiny files are the one genuine transfer-time risk, and the scan is where you find out |
Two caveats matter more than the headline figures. These are ceilings under good conditions, not forecasts — Microsoft notes that its own telemetry usually finds the bottleneck at the source end, in disk performance, agent hardware and the network, rather than in the service. And the service deliberately throttles background applications such as migration tools harder during weekday daytime hours, with more headroom in the evenings and at weekends. Microsoft is explicit that these rules cannot be disabled or suspended and that raising a support ticket does not lift them, so a schedule that assumes full daytime throughput is planning against a documented constraint.
Where small-business projects lose time that never appears in the plan
Smaller organizations have less data and, counter-intuitively, not much less calendar. The reason is that the fixed decisions do not scale down: a 40-person company still needs an archive boundary, a permission model and a cutover window, but it usually has no records manager, no per-department content owner, and one IT generalist who is also fixing laptops. The work does not take longer; it waits longer between steps.
Three patterns cost the most. The first is single-person dependency — one person knows what is on the shares, and the project pauses whenever they are unavailable. The second is a busy season nobody mentioned at kickoff: a month-end close, an audit, a seasonal peak, and suddenly the only safe cutover weekend is six weeks out. The third is assuming external help fills the gap automatically; Microsoft’s FastTrack benefit performs data migration activities on behalf of customers with 500 or more licenses, which is above where most small businesses sit, so the execution stays with you or with a partner you engage.
It is also worth separating this from a build. Moving content you already own is a different project from designing something new on top of SharePoint, and the two timelines get conflated constantly. Our account of what a SharePoint intranet in 30 days really looks like is a delivery plan for building an intranet, not for migrating a decade of files — running them back to back is sensible, treating one duration as the other is not.
How to compress the calendar before anyone starts
Most of the available time savings are claimed in the first week, and none of them require a bigger budget. Name one decision-maker per department who can approve an access mapping inside a day, because that single step removes most of the waiting from the longest phase. Run the source scan early and treat its exception list — long paths, blocked types, open files — as remediation work that starts immediately rather than findings to read later. Agree the archive boundary and the version policy in writing before anything is packaged, since both change the size of every pass that follows.
Then protect two things people cut when they feel behind. Keep the pilot: one department moved end to end tells you what your wave plan is wrong about while the cost of being wrong is still small. And keep the old source read-only for an agreed window after cutover instead of deleting it, because the ability to check the previous state is what turns a panicked escalation into a two-minute answer. If the environment still needs attention once the project closes, that is ongoing work rather than a longer migration — the shape our SharePoint support and maintenance page describes.
Duration and price are different questions
A longer project is not automatically a more expensive one, and a short one is not automatically cheap. Elapsed time is mostly a function of how quickly your organization makes decisions; the fee is a function of scope — how many sources, how much remediation, how much has to be rebuilt rather than copied. A project can sit at four weeks because one approval takes a fortnight, without a single extra hour being worked. If you are at the budgeting stage rather than the scheduling stage, our guide to SharePoint migration cost for a small business covers the drivers that move the number, and this page deliberately stops at the calendar.
Where your content lives now changes both answers. A tidy file share is the fastest path. Cloud services have supported connectors but their own quirks around shared links and external collaborators. An on-premises farm is the longest case by some distance, because site collections, classic workflows and custom code each need an assessment before anything moves — the work our SharePoint Server to SharePoint Online migration service front-loads for exactly that reason.
What we will commit to, and what we will not guess
We deliver migrations as fixed-fee SharePoint consulting: senior US-based engineers, scope and price agreed before work starts, typical 2–4 week delivery, and 30 days of hypercare after cutover. What we will not do is put a duration on a tenant we have not looked at, because the honest version of that number depends on your sources, your permissions and how fast your organization can approve things. How the fixed-fee process works sets out the sequence, and scoping starts with a free consultation. Tell us the shape of your content and the date you are working towards, and we will tell you what fits.
FAQ
Timing questions, answered plainly
Less time than people expect, and it rarely blocks anything. Microsoft publishes daily ceilings by content type, and passes run in the background while everyone keeps working. A small-business content set usually clears overnight or over a weekend. The calendar goes on decisions before the pass and validation after it.
The cutover can. The project cannot. A weekend switch works when discovery, structure design, permission mapping and a pilot are already finished, because the final pass then only carries what changed since the last one. Compressing the decisions into the same weekend is what turns a switch into an incident.
Waiting for a human decision. Permission mapping needs someone with the authority to say who should see what, and archive boundaries need someone willing to delete. When no owner is named per department, each question waits for a meeting, and a week of work spreads across a month of calendar.
Yes, in both directions. Every retained version is data to package, transfer and validate, so libraries with uncapped history can carry many times the volume the folder size suggests. Agreeing a version policy early shrinks the transfer, the validation pass and the argument about what counts as complete.
No. Microsoft states that throttling protects service reliability, that the rules cannot be disabled or suspended, and that opening a support ticket does not lift them. Background migration traffic is throttled harder during weekday daytime hours, so schedule heavy passes for evenings and weekends in your region.
Work backwards from cutover and add the approval time, not just the work time. Name the decision-maker per department first, because that single step removes most of the waiting. Then protect the pilot: skipping it saves a few days and routinely costs more than that after the switch.
Related reading
Plan the move, the budget and the source
File Server to SharePoint
The step-by-step playbook: inventory, structure design, tool choice, waves, and the traps that stall cutover.
What a Migration Costs
The scope drivers behind the fee — data volume, permission rebuilds, version history and custom workflows.
SharePoint Server to Online
The longest case: an out-of-support farm, where site collections and custom code stretch the assessment phase.
Book a free consultation
Get more from the Microsoft tools you already pay for
Tell us what you’re trying to fix — a report, an approval process, an intranet, a Copilot rollout. We scope it as a fixed-fee project, you approve, and a senior engineer delivers in 2–4 weeks.
- Fixed-fee scope agreed before any work starts
- Senior, US-based Microsoft engineers — no handoffs
- Typical 2–4 week delivery
- 30 days of post-delivery hypercare included
The fastest way to reach us is the form — tell us the task and we’ll reply within one business day.