A SharePoint consulting service should include four things in writing: a discovery phase that inventories what you actually store and who touches it, an information architecture designed before any data moves, a migration plan with a rollback point and a defined cutover window, and named ownership of permissions and user adoption for a period after go-live. Most proposals we are asked to review cover the third item in detail and treat the other three as assumptions. That imbalance is why so many firms pay twice. The files arrive intact, the folder mess arrives with them, and six months later nobody can answer who has access to the contracts library.
Five Things We Assume About Your Situation
We wrote this for IT directors, operations leads, and owners at firms between roughly 10 and 500 people who are buying this work for the first or second time. Five assumptions shape everything below:
- You are not buying software, you are buying decisions. Your Microsoft 365 subscription already includes SharePoint. What you are paying a consultant for is structure, and structure is a series of judgment calls about how your business is organized.
- Your real problem is probably the file server, not SharePoint. Twenty years of nested folders and a permissions model built by whoever was available that week does not improve by being copied somewhere newer.
- The proposal you can compare is not always the proposal you want. Per-gigabyte migration pricing is easy to line up side by side, which is precisely why vendors lead with it.
- Adoption is a cost, not a courtesy. Staff who keep saving to the old mapped drive turn a finished project into two systems of record and a compliance problem.
- Somebody has to own permissions on day 91. If the contract does not name that person, the answer is nobody, and oversharing accumulates quietly from there.
Why a SharePoint Consulting Service Gets Bought Too Late
Most firms hire a SharePoint consulting service after a migration has already gone sideways, which doubles the cost of the same work. We get the call when search returns nothing useful, when a client asks for an access review that takes three weeks to assemble by hand, or when a departing employee’s OneDrive turns out to have been the home of a working project. The pattern is consistent: the platform was treated as a storage destination rather than a design problem.
Is a consultant necessary if the migration tool does the work?
There is a real argument that it is not. Microsoft’s own migration tooling handles file shares competently, the throughput is fine, and a capable internal admin can move a few terabytes over a weekend without outside help. For a firm with a clean, shallow folder structure and fewer than fifty staff, that position holds up, and we have told prospects exactly that rather than sell them a project.
Where it stops holding is complexity that lives outside the file count. Retention obligations, client confidentiality walls, external sharing with partners, and content that has to stay discoverable years later are design questions the tool does not ask. The tool copies whatever you point it at, faithfully, including the twelve folders named “Final.” The honest framing is that migration is a solved technical problem and an unsolved organizational one, and the second half is what a consultant is for.
Does an in-house admin cost less than a consulting engagement?
On the invoice, usually yes. An internal administrator already carries your context, knows which department manufactured which folder, and does not bill hourly for discovery. Plenty of firms in this size range genuinely do not need outside help for the build itself, and we would rather hand over a design than sell perpetual dependency.
The counterweight is opportunity cost and pattern exposure. Your admin has seen your one environment; a team doing this work continuously has seen dozens fail, which is a different kind of knowledge. There is also the succession risk of a single internal owner, since a design that exists only in one person’s head is a liability the day they take another job. The honest read is that in-house delivery is often cheaper and outside design is often safer, and the mix depends on how much of your revenue depends on finding documents fast.
What actually breaks first after a rushed cutover?
Permissions, almost every time. A lift-and-shift carries the old NTFS model into a system that manages access differently, and what emerges is a mesh of broken inheritance and individually shared links that no report can summarize cleanly. The second failure is search, because search quality depends on metadata that a folder copy does not create.
The opposing case deserves airtime: a rushed cutover that gets everyone off a failing on-premises server has removed a bigger risk than the one it created, and we have run exactly that play during hardware emergencies. That is a defensible trade as long as somebody schedules the cleanup. What makes it expensive is calling the emergency move a finished project. We wrote up the recurring version of this in our field notes on costly SharePoint consulting traps, and rushed cutover with no remediation phase leads that list.
What Belongs in a SharePoint Consulting Service Statement of Work
A SharePoint consulting service statement of work should name deliverables, owners, and dates for four phases rather than describing capabilities. Capability lists are marketing. Phases with an owner beside each one are a contract. Here is the shape we would want to see if we were the buyer.
Phase one: discovery that produces an inventory, not a meeting
Ask for a written inventory as the deliverable. That means a report of what you store, how much of it has not been opened in three years, where the duplicates are, which shares have permissions that cannot be cleanly translated, and which content carries a retention obligation. A discovery phase that ends in a slide deck and a price has not given you an asset you own.
The pushback we hear is that discovery inflates the invoice before anything visible happens, and for a small, tidy environment that criticism lands. Our counter is arithmetic: the inventory is what lets you decide not to migrate half your data, and archiving rather than moving stale content is usually the single biggest cost reduction in the whole project.
Phase two: information architecture on paper before anything moves
The design document is the deliverable that outlives the engagement. It should specify your site structure, which content lives in a team site versus a communication site, the metadata columns that replace folder depth, naming conventions, and the sharing model for external parties. Ask to see it as a document you can hand to a different vendor next year.
Some clients tell us they would rather iterate live than approve a design in the abstract, and for a small pilot that is reasonable. The reason we still push for paper is reversibility. Restructuring a live site that three hundred people have bookmarked is a change-management project, while redlining a diagram is a Tuesday. Getting this phase right is the same discipline we apply in broader IT consulting work: decide on paper where a decision is cheap.
Phase three: migration with a rollback point and a named cutover window
The migration section should state the tool, the batching order, how permissions are mapped, what happens to version history, the validation method, and the date the old file server becomes read-only. That last item is the one buyers forget to ask for, and it is the difference between a cutover and a permanent second copy of everything.
A counter-position worth respecting: some firms need the old share writable for months because a line-of-business application still writes to a UNC path. Fine, as long as that exception is written down with an owner and an end date instead of drifting. Undated exceptions are how firms end up running two systems of record for years.
Phase four: governance and adoption with an owner and a review date
This is the phase that gets cut when a proposal needs to look cheaper, and it is the one that decides whether you buy this project again. It should include a permissions review cadence, a policy for external sharing links with expiry, a named internal owner for site requests, training that is role-based rather than a single all-hands session, and a check-in at 30, 60, and 90 days after go-live.
The argument against paying a consultant for this is that governance is your business’s job, not a vendor’s, and philosophically we agree. Where we disagree is the handover. Somebody has to build the first review process and train the person who inherits it, and firms without an internal technology leader often route that ownership through virtual CIO consulting rather than leaving it unassigned.
How SMBs Compare SharePoint Consulting Service Proposals
Comparing SharePoint consulting service proposals works better when you normalize them on scope boundaries rather than price, because the cheapest bid is usually the one that stops at data movement. Line the bids up and mark where each one ends. If one includes a design document and 90 days of governance support and another includes neither, you are not looking at two prices for the same thing.
Four questions separate proposals quickly. Ask what the deliverable of discovery is, as a document. Ask who owns permissions on day 91, by role. Ask what happens to the old file server and on what date. Ask for a reference in your own industry at your own headcount, then ask that reference how the 90-day period went rather than how the migration went. Our walkthrough on how firms vet SharePoint consulting companies without overpaying covers the pricing side of that conversation in more detail.
Geography matters less than it used to for delivery and more than people expect for the discovery phase, since walking a floor and watching how staff actually save files surfaces things no questionnaire catches. That is part of why we still run this work locally, including our SharePoint consulting service in New Jersey engagements. If your firm bills its time, the evaluation criteria overlap heavily with what we describe in what to look for in IT consulting for professional services firms, because the underlying risk is the same: documents are the product.
Frequently Asked Questions
How much does a SharePoint consulting service cost?
Pricing usually arrives in one of three shapes: a fixed-fee discovery and design package, a per-gigabyte or per-user migration rate, and a monthly retainer for governance after go-live. The variable that moves the total most is not data volume, it is how much of your permissions model has to be redesigned rather than translated. Firms that archive stale content during discovery routinely cut the migration portion of the bill.
How long does a SharePoint migration take for a small business?
For a firm under 100 staff with a reasonably clean file share, plan on four to eight weeks from discovery to cutover, with most of that time spent on design and validation rather than data transfer. Environments with heavy external sharing, retention obligations, or a line-of-business application writing to a file path run longer. The transfer itself is often a single weekend.
Do we need a consultant if we already pay for Microsoft 365?
Your subscription gives you the platform, not the design. The work a consultant does is deciding your site structure, metadata, and sharing model, then moving content into it without carrying the old mess along. A firm with a shallow folder structure, a capable admin, and no regulatory obligations can reasonably do this internally.
What is the difference between a SharePoint migration and a SharePoint intranet project?
A migration moves existing content into a structure you design. An intranet project builds a communication layer on top, with news, policy pages, and search aimed at helping staff find information rather than files. They are frequently sold together, and we would rather see the migration land first, because an intranet built over an unstructured document estate inherits the same search problem.
Who should own SharePoint permissions after the project ends?
A named internal person, with a written review cadence and an escalation path to whoever handles your technology decisions. The common failure is assigning it to a group rather than a person, which produces the same result as assigning it to nobody. If no internal candidate exists, contract that ownership deliberately rather than leaving it implied.
Get a Second Opinion on Your SharePoint Scope
Take whatever proposal is on your desk and mark the four boundaries from the comparison section above: the deliverable of discovery, the owner of permissions at day 91, the date the old file server goes read-only, and whether a design document is something you keep. If two or more of those are missing, the price you are looking at is a deposit rather than a total. That is not a claim about the vendor’s competence, it is a claim about what happens to scope that nobody wrote down.
Our team does this review with firms in your size range regularly, including for people who end up doing the build in-house afterward with a design we handed them. We look at what you store, what has to stay discoverable and for how long, how your staff actually save files today, and where your current proposal ends. Then we tell you what the missing phases would cost, so the comparison you make is between two complete pictures. Book a free strategy call and bring the proposal you already have, including the parts of it that look right to you.
