SharePoint articles

What actually drives the cost of a SharePoint migration for a small business

SharePoint migration cost for small business teams is set by scope, not by headcount: how much content genuinely moves, how tangled its permissions are, how much version history travels with it, and how many custom workflows and forms have to be rebuilt rather than copied. Microsoft’s migration tooling is free. This guide breaks down the drivers that set the number so you can read any proposal — ours or anyone else’s — against the same checklist.

The copying is free; the decisions are not

Moving bytes is the cheapest part of the project. Microsoft ships the SharePoint Migration Tool (opens in new tab) and Migration Manager with the subscription you already pay for, and both handle file shares, preserve timestamps where accounts resolve, and support incremental passes. If a proposal is mostly about tooling, it is pricing the easy half.

What a real quote is pricing is judgement and elapsed care: inventorying the shares, deciding what should not move at all, designing target sites and libraries, mapping a decade of ad-hoc permissions onto clean groups, validating each wave against the source, and getting people through cutover without losing a day’s work. Those hours do not shrink because the company is small. They shrink when the decisions are made before the first pass runs.

The drivers that move the number

Five or six variables explain nearly all of the spread between a lean migration and a heavy one. The table below is the checklist we take into a scoping call, written so you can use it against anybody’s proposal. Each row is a question the person quoting you should already have asked.

Driver Keeps the number down Pushes the number up
Volume and file count A defined set of active shares, with an archive decision already made Everything moves “just in case”; millions of tiny files; long paths and unsupported characters found mid-run
Source system A single Windows file share, or one cloud service with a supported connector A SharePoint Server farm, a records system with its own metadata model, or several sources at once
Permissions Access already follows departments and maps onto existing Microsoft 365 groups Years of per-person grants, Deny entries, orphaned accounts and folders shared with outsiders
Version history A written version policy: recent versions for active content, current-only for archives Every version of everything, on libraries where history was never capped
Structure and metadata Folders carried across largely as-is, with light tidying Deep folder trees redesigned into libraries, content types and metadata columns
Workflows, forms and custom code Nothing custom — files and folders only Designer workflows, InfoPath forms and custom web parts, each needing a rebuild-or-retire decision
Cutover and training Waves by department, a read-only source left in place, one training session A single big-bang weekend, multiple sites, role-based training and change management

Permissions, versions and workflows surprise people the most

Permissions are the line item that most often doubles an estimate, because the work is archaeology rather than configuration. Someone has to establish who should see what today, not who was granted access in 2017, and get an owner to sign off on the mapping. Deny entries and unresolvable local accounts do not come across on their own, so a migration that “kept permissions” can still hand you a library nobody can open on Monday morning.

Version history is the quiet multiplier. Every retained version is data that has to move, be validated and then be stored, so a library whose folder size looks modest can carry many times that volume once history is included. Microsoft’s document library version history limits (opens in new tab) documentation explains the settings that cap it; agreeing a version policy before the first pass is usually an afternoon that pays for itself.

Anything custom is a rebuild, not a copy. Classic SharePoint Designer workflows and InfoPath forms have no home in SharePoint Online, and Microsoft’s guidance on migrating classic workflows to Power Automate flows (opens in new tab) is the reference for what that involves. The saving grace is that most inventories find a majority of workflows nobody has triggered in years — which is why the inventory belongs before the quote, not after it.

Where a small-business migration differs from an enterprise one

The data is smaller; the decisions are not proportionally simpler. A 40-person company usually has one or two shares rather than forty, but it rarely has a records manager, an owner per department, or documentation of who granted what. So the fixed cost of good decisions — inventory, archive boundary, permission design, version policy — makes up a larger share of a small-business migration than it does of an enterprise programme, while the transfer time itself barely registers.

That shapes what is worth paying for. Bigger budgets buy parallel waves and dedicated change management. A smaller one is better spent on the design week and on a wave plan that keeps people working, with the old share left read-only for an agreed window rather than deleted at cutover. The step-by-step mechanics are covered in our file server to SharePoint migration playbook, which is the companion to this page for anyone who wants the how rather than the what-it-costs.

Moving content you already have is a different budget from building something new

Two projects get confused at budget time. This page is about relocating content that already exists — shares, libraries, permissions, history. Designing and building a new intranet on top of SharePoint is separate work with its own drivers, priced by sites, hubs, branding and page content; our guide to what a SharePoint intranet costs covers that side. Plenty of teams do both in sequence, and keeping the two scopes distinct is the easiest way to stop one absorbing the other.

Where your content lives now also changes the shape of the work. An on-premises SharePoint farm brings site collections, content databases and custom code into the picture — the assessment our SharePoint Server to SharePoint Online migration service runs before quoting. Cloud sources such as Dropbox or Box have supported connectors but their own quirks around shared links and external collaborators, and a records system like Laserfiche has to have its metadata and retention rebuilt rather than copied.

What a written scope should name before you agree a fee

We publish no rate card for this work, because a number produced before anyone has seen your shares is a placeholder rather than a price. What we can publish is the structure: the phases below are what a typical migration looks like, and the scope column is what should be written down before the fee is agreed. Duration is a separate question from fee — a project can run long because one approval took a fortnight without a single extra hour being worked — and our guide to how long a SharePoint migration takes walks these same phases as a calendar instead of a budget. How our fixed-fee process works explains the same shape across every engagement.

Phase What the scope should name Typical timeline Fee
Phase 1 — Inventory and design The shares in scope, the archive boundary, the target site and library structure, the permission model, the version policy, and the list of workflows and forms with a rebuild-or-retire decision against each About 1 week Fixed fee — scoped after your free consultation
Phase 2 — Pilot and waves Destination sites built, groups created, one pilot department moved end to end, then remaining waves with validation counts and spot checks against the source at each step 1–2 weeks Fixed fee — scoped after your free consultation
Phase 3 — Cutover, training, hypercare The incremental final pass, the read-only period for the old source and when it ends, sync setup for teams that live in File Explorer, training, documentation handed over, then 30 days of included hypercare About 1 week, plus 30 days of hypercare Fixed fee — scoped after your free consultation

Three habits protect a migration budget more than any negotiation. Insist the scope names the shares, the archive boundary and the version policy in writing, so overruns belong to the vendor rather than to you. Compare deliverable lists instead of headline numbers, because the cheapest proposal is usually the one that quietly excluded permission work. And confirm everything is built in your own tenant and stays yours at handover.

Three things to do before anyone quotes

Preparation reliably shrinks the effort a consultant has to price. Run a size-and-age report on each share and make the keep, archive or delete call per top-level folder — deciding what does not move is cheaper than moving it. Name one person per department who can approve a permission mapping inside a day. And agree how much version history you actually need, in writing, before anyone opens a migration tool.

The usual fit for this work is an organization of roughly 20 to 500 people already paying for Microsoft 365, with content on an ageing server or a cloud service it has outgrown, and a cutover date it needs to commit to. We deliver it 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. Send us the shape of your content and we will scope it.

FAQ

Budget questions, answered plainly

Because they are usually pricing different projects. One quotes a straight copy of current folders into new libraries. The other includes an inventory, an archive decision, a rebuilt permission model and validated waves. Compare the deliverable lists rather than the headline numbers and the gap normally explains itself.

Not for the common paths. Microsoft supplies the SharePoint Migration Tool and Migration Manager at no extra charge with your existing subscription, and both handle file shares plus incremental passes. Paid tools earn their licence on heavy restructuring and reporting, not on moving files, so budget the decisions rather than the software.

Permissions, followed closely by anything custom. Years of one-off grants and folders shared with individuals have to be read, redesigned as groups and approved by an owner before content lands. That is judgement work nobody can automate, and it is why identical data volumes can carry very different fees.

No, and that decision is worth making early. Every retained version is data to move, validate and store, so a library with deep history can dwarf what the folder size suggests. Most teams keep recent versions for active content and take current-only copies of archives, which shrinks the job.

They are rebuilt, not copied. Classic SharePoint Designer workflows and InfoPath forms have no destination in SharePoint Online, so each one is inventoried, confirmed as still used, then rebuilt in Power Automate or Power Apps — or retired deliberately. That inventory belongs in the scope before anyone quotes a fee.

Agree a written scope that names the shares in the migration, the archive boundary, the permission model, the version policy and the training, then hold the fee to it. Work inside that scope is covered however long it takes. Genuinely new work is quoted separately and starts only once you approve it.

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.

All fields are required.

We reply within one business day. No newsletters, no drip campaigns.

Book a Free Consultation