The SharePoint Server-Side Object Model, and Where It Applies

The Server-Side Object Model is the original way to program SharePoint: a .NET API that runs inside the SharePoint process, on the server, with direct access to the content database through the platform's own layer.

It is also the API most likely to appear in guidance that no longer applies to you. SSOM exists only on SharePoint Server. There is no version of it for SharePoint Online, and there never will be — you cannot run code inside Microsoft's servers.

If you are working on-premises, SSOM remains the most capable option available. If you are working in Microsoft 365, everything below is context for reading old code rather than instructions for writing new code.

What makes SSOM different

Client APIs talk to SharePoint over HTTP and are therefore bounded by what the service chooses to expose. SSOM runs inside the farm, so it reaches things no remote API can:

• Farm and service application configuration — the topology itself, not just content within it
• Timer jobs — defining scheduled work that runs in the SharePoint timer service
• Event receivers running in-process — synchronous handlers that can cancel an operation before it completes
• Elevated privilege — running a block of code under the application pool identity
• Direct object access with no round trip and no load-and-execute ceremony

The cost of that reach is that the code must be deployed to the servers and runs in a process shared with everything else the farm is doing. A leak or an unhandled exception is a farm-level problem, not an application-level one.

The disposal rule that matters most

If you take one thing from SSOM, take this. SPSite and SPWeb hold unmanaged resources, and failing to dispose them leaks memory in the worker process. This is the single most common cause of SharePoint Server farms that degrade over hours and recover on a recycle.

// Objects you create, you dispose.
using (SPSite site = new SPSite("https://intranet.contoso.com/sites/finance"))
using (SPWeb web = site.OpenWeb())
{
    SPList list = web.Lists["Invoices"];
    Console.WriteLine(list.ItemCount);
}

The subtlety is knowing what you own. Objects you construct or open, you dispose. Objects handed to you by the context, you must not:

// WRONG inside a web part or event receiver — you did not create these,
// and disposing them breaks the request that owns them.
using (SPWeb web = SPContext.Current.Web) { /* ... */ }

// Correct: use it, leave it alone.
SPWeb web = SPContext.Current.Web;
SPList list = web.Lists["Invoices"];

Disposing a context object is worse than leaking one. It breaks the request currently in flight and produces errors that appear unrelated to your code.

Elevated privilege, used sparingly

RunWithElevatedPrivileges executes a block as the application pool account, which is how you let a user trigger something they could not do directly.

SPSecurity.RunWithElevatedPrivileges(() =>
{
    // New objects are required inside the block. Reusing objects created
    // outside it keeps the original user's token, so the elevation silently
    // does nothing — a bug that only shows up for non-privileged users.
    using (SPSite elevatedSite = new SPSite(siteUrl))
    using (SPWeb elevatedWeb = elevatedSite.OpenWeb())
    {
        SPList log = elevatedWeb.Lists["Audit Log"];
        SPListItem entry = log.AddItem();
        entry["Title"] = "Request submitted";
        entry.Update();
    }
});

Two disciplines apply. Create fresh objects inside the block, or the elevation has no effect. And keep the block as small as possible — every line inside it runs with more authority than the user has.

Queries and the threshold

The list view threshold exists on SharePoint Server too, but unlike SharePoint Online it is configurable at the web application level, and there is a separate higher limit for auditors and administrators.

Raising it is possible and usually the wrong instinct. The threshold protects the SQL layer from queries that escalate to table-level locks; a farm where it has been raised to avoid indexing work tends to develop performance problems that are much harder to diagnose than the original error. Index the column and filter the view.

Common mistakes and better practice

• Not disposing objects you created. The classic SSOM memory leak.
• Disposing objects you did not create. Breaks the current request. Never dispose SPContext.Current.Web.
• Reusing outer objects inside RunWithElevatedPrivileges. The elevation silently does nothing.
• Long-running work in a synchronous event receiver. Blocks the user's request. Queue it, or use an asynchronous receiver.
• Raising the threshold instead of indexing. Moves the problem into SQL, where it is harder to see.
• Applying SSOM guidance to SharePoint Online. SSOM does not exist there. This is the most common source of wasted effort.
• Deploying full-trust solutions casually. Farm solutions run in-process; a fault affects everything on the farm.

Troubleshooting

Symptom	Likely cause	What to check
Worker process memory climbing over hours	Undisposed SPSite or SPWeb	Audit every construction for a matching dispose
Unrelated errors after your code runs	A context object was disposed	Remove using around SPContext.Current objects
Elevation works for admins, fails for users	Objects created outside the elevated block	Create fresh objects inside it
Threshold error despite a configured limit	Limit applies per web application, not per list	Index the filter column instead
Slow page loads after deployment	Synchronous receiver doing heavy work	Move it to asynchronous or a timer job

Frequently asked questions

Can SSOM be used with SharePoint Online?

No, and it cannot be made to. SSOM requires code running on the SharePoint server, which is not possible in a hosted service. Use CSOM, REST or Microsoft Graph.

Is SSOM deprecated?

It is not deprecated for SharePoint Server, where it remains the most capable API. It is simply unavailable in Microsoft 365. Check the lifecycle documentation for your specific server version for support dates.

Which is faster, SSOM or CSOM?

On-premises, SSOM avoids the network entirely and is faster for server-side work. That advantage is irrelevant to SharePoint Online, where SSOM cannot run at all.

What replaces a farm solution?

For SharePoint Online, the SharePoint Framework for front-end work and Entra-authenticated applications calling Graph or REST for back-end work. On-premises, farm solutions remain supported, though SPFx is available on modern versions.

Do I still need to worry about disposal?

On SharePoint Server, absolutely. It remains the most common cause of gradual farm degradation.

Reading old code with the right expectations

SSOM is worth understanding even if you will never write it, because a great deal of SharePoint material online assumes it. Recognising SSOM in a sample tells you immediately that the guidance is on-premises only, which saves considerable time when the sample does not compile against a Microsoft 365 project.

Where you are maintaining a farm, the disposal rules are the thing worth auditing first. They are simple, they are mechanical, and getting them wrong degrades a whole farm rather than one feature.