After go-live

SharePoint support and maintenance that starts the day after go-live

Projects end at launch; the tenant keeps running for years. SharePoint support and maintenance is the work that happens afterwards — permissions drifting as people change roles, libraries filling with versions nobody reads, search quietly missing documents, a flow that failed three weeks ago. We scope each of those as a fixed-fee piece of work with senior US-based engineers, not as a monthly monitoring contract.

  • Fixed fee agreed before any work starts
  • Senior US-based engineers
  • No retainer, no minimum term
  • Findings documented in your tenant
Revenue Overview Revenue$4.2M Margin38% Orders12.4k Churn2.1% Monthly performance By segment 64%

Representative dashboard — sample data

The usual damage

Six things that quietly degrade once people start using it

None of these announce themselves. They surface as “I can’t find the contract” or “why can the intern see that folder”, usually a year or two after launch.

Permission drift

People change roles, sharing links get created in a hurry, and inheritance gets broken on individual folders. Two years of small exceptions is how a tenant ends up with access nobody can explain.

Storage and version sprawl

Tenant storage is a pooled allowance, and versions, recycle bins and abandoned sites all draw from it. The bill for ignoring it arrives as a purchase order or, eventually, as read-only sites.

Search that stopped working

A renamed column, a changed managed property or a library excluded from search results in documents that exist but cannot be found. Staff stop trusting search long before anyone reports it.

Flows that failed silently

An approval routes to a person who left, a connection expires, a list column is renamed. The flow turns itself off, and the first sign is a process that everyone assumed was still running.

Offboarding leftovers

A departing employee owned three sites, two flows and a shared library. Removing the licence does not reassign any of that, and orphaned ownership is the most common cause of a site nobody can administer.

Small changes nobody owns

A new department needs a site, a library needs two more metadata columns, a retention rule needs adjusting. Each is an hour of work that waits six months because no one is responsible for it.

What this covers, and what it deliberately does not

Most pages selling ongoing care are vague about the edges, which is how a client ends up calling about a broken laptop. This is a fixed-fee project practice, not a managed service provider: there is no helpdesk queue, no 24/7 monitoring, no SLA and no device management here, and the only way to reach us is the form on this page. The table below is the boundary, written so you can check it before you get in touch.

The request Handled here? Notes
Audit and rebuild permissions across sites and libraries Yes Who can see what today, an agreed group-based model, then a staged rollout site by site
Reclaim tenant storage and set version-history limits Yes Version storage reported before anything is trimmed, recycle bins and dormant sites reviewed
Fix search that is missing or mis-ranking documents Yes Search schema and managed properties checked, site and library indexing settings corrected
Repair or rebuild a failed Power Automate flow Yes Connection ownership, expired credentials and renamed columns are the usual three causes
Reassign sites, flows and files left by a departing employee Yes Ownership moved before the account is removed, so nothing becomes unadministrable
Add a new site, hub, library or metadata column Yes Scoped as a small change against the existing structure, not a fresh build
24/7 monitoring, alerting or a guaranteed response time No We reply within one business day; overnight cover with an SLA belongs to a managed service provider
End-user helpdesk — passwords, mailboxes, “how do I” tickets No That is your internal IT or MSP; we train your site owners instead of taking their tickets
Laptops, patching and endpoint management No Device work is a separate project — see Intune deployment for small business
Building a new intranet or document-management structure No That is a build, not maintenance — see SharePoint consulting
Moving content in from a file server or another platform No Migrations are scoped and priced separately — see file server to SharePoint migration

No retainer, and nothing renews on its own

Care work is quoted the same way a build is: a written scope and one fixed fee, approved before anything starts. Book a single cleanup, or re-authorize a review whenever you want one. There is no minimum term, no monthly commitment, and nothing to cancel.

How it works

Three steps from “something is wrong” to a fixed quote

  1. 1

    Read-only review

    A senior engineer looks at sites, permissions, storage, indexing and flow-run history without changing anything. You get the findings in writing, in priority order, whether or not you go further.

  2. 2

    Written scope and one fee

    The findings turn into a list of specific fixes, each with what changes and what the user-visible effect is. You approve the list and the fixed fee before a single setting is touched.

  3. 3

    Fix, verify, document

    Changes are staged — one site, confirmed working, then the rest. What was changed and why is documented in your own tenant so your team, or anyone after us, can follow it.

Why a well-built tenant still drifts

Nothing in the list above is a defect in SharePoint or a sign the original project was done badly. They are the predictable consequence of people using a system: staff join and leave, someone shares a folder to hit a deadline, a library grows past the shape it was designed for, and a department invents a process the intranet was never told about. A site that was correct at handover is a site that was correct on one particular day.

What makes the drift expensive is that it compounds silently. Individual permission grants are the clearest example. SharePoint supports up to 50,000 unique permissions per list or library, but Microsoft's published SharePoint service limits (opens in new tab) put the recommended working limit at 5,000 — and note that once a list, library or folder passes 100,000 items you can no longer break or re-inherit permissions on it at all. Nobody crosses those lines deliberately. They arrive one “just give Dave access to this one folder” at a time.

The five failure modes, and what fixing each one involves

Support requests on a mature tenant cluster into a short list. The table below is the triage we run before quoting, and it is written so you can use it to diagnose your own environment before talking to anyone.

Symptom Usual cause What the fix involves
“The wrong people can see this” Broken inheritance, direct grants to individuals, and sharing links created ad hoc over several years Map current access, agree a group-based model, remove per-item exceptions, stage the change site by site
“We are out of storage” Version history with no limit, full recycle bins, dormant sites and duplicated migration content Report version storage first, set organization or site version limits, empty recycle bins, retire dead sites
“Search cannot find a document that exists” Managed property or schema changes, a library set to be excluded from search, or content never reindexed Check the search schema and site settings, correct the mapping, then request a reindex and verify results
“The approval stopped arriving” A flow owner who left, an expired connection, a renamed list column, or an unhandled error loop Read the run history, repair or rebuild the flow, move ownership to a service account or shared owner
“Nobody can administer this site” The only site owner left the company and the account was deleted before ownership was reassigned Restore administration, assign at least two owners per site, and fix the offboarding checklist that allowed it

Two of those deserve a caution. Version cleanup is genuinely destructive: Microsoft's guidance on version history limits for document libraries (opens in new tab) is explicit that versions removed by a limit or a trim job bypass the recycle bin and cannot be recovered, though content under a retention policy or eDiscovery hold is exempt. So the version storage report comes first and the trim job second, always. Search is the opposite problem — the risk is impatience. Microsoft's own note on manually requesting a reindex (opens in new tab) warns that reindexing a site puts heavy load on the search system and should not be used as a first response, which is exactly how most in-house attempts to fix search begin.

Support priced like a project, not like a subscription

The obvious commercial model for this work is a monthly fee for an agreed number of hours. We do not offer one, because it would be the wrong shape for the same reason our builds are fixed-fee: you would be paying a steady amount for work whose volume is lumpy, and we would be incentivised to make each request small. Instead a review produces a list of specific fixes, each one described by what changes, and the whole list carries a single fixed fee you approve in writing. How our fixed-fee process works is the same for a permission audit as it is for a build.

If you are still in a project rather than after one, the other SharePoint pages are the right starting point. An initial build — information architecture, libraries, permissions model, governance — is covered under SharePoint intranet and document management consulting, and the week-by-week version of that sprint is set out in what a SharePoint intranet in 30 days really looks like. If you are budgeting rather than buying, what drives SharePoint intranet cost breaks down the build side and SharePoint migration cost for a small business covers moving existing content in. All three of those end at go-live. This page begins there. And where the same faults keep coming back because no rule stops them — access granted person by person, sites created by anyone, links that never expire — the answer is policy rather than repair, which is what our SharePoint governance consulting services design and configure once rather than fixing each time.

Who this actually fits

The typical fit is an organization of roughly 20 to 200 people on Microsoft 365 with a SharePoint environment that already works, no dedicated SharePoint administrator, and an IT provider who keeps laptops and mailboxes running but does not go near information architecture or the search schema. Often the person calling inherited the tenant from whoever set it up and has no documentation of how it was meant to be organized.

It fits badly in two cases, and both are worth saying out loud. If what you need is someone on call overnight with a contractual response time, that is a managed service provider and not us — Microsoft 365 consultant vs MSP sets out where that line falls and what each kind of provider is actually selling. And if the tenant is so tangled that a rebuild is cheaper than a repair, we will say so during the review rather than sell a cleanup that will not hold — in which case the conversation moves to a build, or to Teams governance if the sprawl arrived through Teams rather than through SharePoint itself. The same boundary applies on the Power Platform side: this service keeps working things working, so a Power Apps or Power Automate build that never worked in the first place is a one-off intervention instead, scoped as our Power Platform project rescue services. Work is delivered remotely across all US states from our Orange County, CA base, by senior US-based engineers.

FAQ

Questions about ongoing care, answered plainly

Neither. Every piece of care work is scoped in writing and quoted as a fixed fee before it starts, exactly like a build. Some clients book one cleanup and never come back. Others re-authorize a review each quarter. Nothing recurs automatically, and there is no contract you have to cancel.

We are not a 24/7 operation and we will not pretend otherwise. There is no pager, no monitoring service and no response-time guarantee here. Contact is by web form and we reply within one business day. If you need overnight cover with an SLA, a managed service provider is the honest answer.

Yes, and most of this work is on tenants somebody else set up. The first step is a read-only review of sites, permissions, storage and failed flows, which is what makes a fixed quote possible. You get the findings in writing whether or not you hire us for the remediation.

By changing group membership rather than individual grants, and by staging it. We map who has access today, agree the intended model with you, apply it to one site first, and keep the old access in place until that site is confirmed working. Nothing is removed on the strength of an assumption.

It can, which is why limits are modelled before they are applied. Microsoft's version storage report shows what a proposed limit would remove, and versions deleted by a trim job bypass the recycle bin permanently. Content under a retention policy or eDiscovery hold is exempt and is not touched.

Hypercare covers the settling-in period after handover and is included in the build fee. After it ends, your team runs the site using the documentation you own. This page exists for later, when something has drifted and you want a senior engineer to fix it as a defined piece of work.

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