Sitecore Support: What Good Looks Like and How to Buy It

If you came here looking for Sitecore's own support portal, that is at support.sitecore.com and it needs a customer login. This article is about the other thing people mean by Sitecore support: getting help keeping your Sitecore implementation running, from someone who is not Sitecore.

Those two are different products solving different problems, and confusing them is how organizations end up with an active support contract and nobody to call when the thing that broke is theirs.

What does Sitecore support actually mean?

Sitecore support comes in two forms. Vendor support, included with your license, covers defects and questions about the Sitecore product itself. Partner support covers your implementation: the custom code, integrations, content model, and front end that your organization built on top of Sitecore. Most production incidents fall in the second category, which vendor support does not cover.

That split is the whole subject. Everything below is about the second one.

What does Sitecore's own support cover?

Product-level issues. If a documented Sitecore feature does not behave as documented, that is a vendor support case, and the process works reasonably well. You raise a ticket, you get a response inside your contracted severity window, and if it is a genuine product defect you may get a patch.

What it does not cover is anything specific to you. Your custom pipeline processor throwing on publish. Your integration to a customer relationship management system timing out. A rendering that fails only on one template. A page that got slower after a release. Performance tuning for your traffic pattern. Any of the front end, if you are headless.

That is not Sitecore being difficult. It is the correct boundary for a software vendor. The problem is that in a mature enterprise implementation, the overwhelming majority of production incidents are on your side of it. When we get called into a Sitecore emergency, it is almost never a Sitecore product defect. It is custom code, an integration, an environment difference, or a change nobody expected to have that effect.

So the practical question is not whether you have Sitecore support. It is who handles the incidents Sitecore support will correctly decline.

What should partner support actually cover?

Six things. A contract that omits any of them has a gap you will discover during an incident.

Incident response with a real severity model. Defined severities, response times per severity, and a named escalation path. "We will get back to you promptly" is not a service level. Also check what counts as response: acknowledgement is not the same as an engineer working the problem, and some contracts quietly mean the first one.

Root cause analysis, not just restoration. Restarting the service fixes the symptom. If the same incident recurs monthly and each occurrence is billed as a new ticket, your support partner has a business model rather than a practice. Insist on written root cause for anything above the lowest severity.

Small enhancements. Real support is not only incidents. It is the steady stream of small changes: a new template, a field added, a rendering tweak, a redirect. If your contract covers only incidents, every small change becomes a change request with its own commercial conversation, and the friction means your team stops asking and starts working around the platform.

Platform maintenance. Patches, module updates, certificate renewals, search index health, environment hygiene. This is the work that prevents incidents, and it is the first thing to disappear from an underfunded support arrangement. When we take over a neglected estate, the backlog of unapplied maintenance is usually the largest single risk we find.

Monitoring that someone reads. Alerts arriving in an unread mailbox are not monitoring. Somebody has to own thresholds and act on them.

Knowledge continuity. Your partner should maintain documentation of your implementation that survives their own staff turnover. Ask to see what they hold for an existing client, with names removed.

How are Sitecore support contracts usually structured?

Three models. Each fails in a specific way, and knowing which failure you are buying is most of the decision.

We sell the third one, and the fix for its failure mode is straightforward: our hours do not expire. That is worth stating plainly as a disclosure and as a recommendation, because expiry is the single most common complaint we hear about pre-paid arrangements, and it is entirely a vendor choice rather than an economic necessity.

The reason it matters for Sitecore specifically is that enterprise CMS demand is genuinely lumpy. A build, then months of quiet, then a spike for a rebrand, an acquisition, a compliance deadline, or an upgrade. A retainer sized for the spike wastes money for three quarters. A retainer sized for the quiet period leaves you renegotiating during the emergency, which is the worst possible time to be discussing commercial terms. Any structure that lets unused capacity carry forward solves this. Ask for it whoever you buy from.

How much Sitecore support do you actually need?

Four inputs, and this is more tractable than vendors make it sound.

Implementation complexity. Count custom modules, integrations, and sites. A single-site implementation with light customization needs a fraction of what a fifteen-site estate with six integrations needs.

Internal capability. Do you have engineers who can triage, or does everything escalate? A team that can diagnose and fix routine problems needs a partner for depth and surge. A team without Sitecore skills needs a partner for everything, and should price accordingly rather than hoping.

Change rate. A site under active development generates far more support demand than a stable one. Support and development are not separate demand curves.

Risk tolerance. What does an hour of downtime cost, in revenue and in regulatory exposure? That number sets your severity requirements, and it is worth calculating rather than asserting.

A practical starting point: look at the last twelve months of tickets and changes, whoever handled them. Historical demand is a far better predictor than any sizing model, and most organizations have the data and have never looked at it.

What should stay in-house?

The best arrangements we work in are not full outsourcing. They are a deliberate split, and getting the split right lowers cost more than negotiating the rate.

Keep triage in-house if you can. Someone who can look at an incident and tell whether it is content, code, integration, or infrastructure saves an enormous amount of billable diagnosis. This does not require a Sitecore specialist, just someone who knows your system.

Keep content operations in-house. Authoring, workflow administration, and day-to-day content changes should not be a support ticket. If they are, your authors are not trained or your workflow is wrong, and both are cheaper to fix than to outsource permanently.

Buy depth, not coverage. Use a partner for the things that genuinely need a specialist: platform upgrades, performance problems, integration failures, architecture decisions, and surge capacity. That is where an expensive specialist earns their rate.

Buy continuity for the things you cannot cover. Holidays, departures, and the two weeks when your one Sitecore-literate engineer is on another project. This is the quiet, unglamorous value of a support relationship, and it is the reason arrangements with a small ongoing commitment beat purely reactive ones.

The anti-pattern is buying broad shallow coverage: a partner handling everything at a level your own team could have handled, while the genuinely hard problems still get escalated somewhere else.

What should you ask a Sitecore support partner?

"Who will actually work my tickets, and what else are they on?" Named people, with their Sitecore depth. The pattern where senior engineers appear in the pitch and junior ones do the work is well established in this industry.

"What is your response time by severity, and what counts as a response?" Get the definition, not just the number.

"What happens to unused hours?" If they expire, you are buying a forfeiture. Ask directly.

"Do small enhancements come out of support, or are they change requests?" This determines whether your team will actually use the contract.

"Show me a root cause analysis you wrote." Redacted is fine. If they cannot produce one, they restore service and move on.

"How do you handle the parts of my stack that are not Sitecore?" In a headless build, most incidents are in your front end, your build pipeline, or your hosting. A partner who supports only the Sitecore layer covers a shrinking share of your actual surface. This gets more true every year and is the question most often forgotten.

"What do you do in the quiet months?" The good answer is maintenance, monitoring review, documentation, and small improvements. The bad answer is nothing, which means you are paying for standby.

Red flags

No severity model. Support without defined severities is best effort with an invoice.

Support priced with no discovery. A partner quoting a monthly figure without examining your implementation is quoting a guess and will manage the gap by rationing.

Expiring hours with no carryover. Structurally rewards the vendor when you need less help, which is exactly backwards.

No named engineers. Continuity is most of the value in support. A pool model means re-explaining your architecture on every ticket.

Sitecore-only scope on a headless build. Half your incident surface sits outside Sitecore.

Restoration culture with no root cause. Recurring incidents billed as new tickets is a revenue model, and it is common enough to check for specifically.

The thing that matters more than the contract

Support quality tracks implementation quality more than it tracks the contract. An implementation with a governed content model, documented integrations, and a working deployment pipeline generates few incidents and cheap ones. An implementation with a decade of undocumented customization generates constant expensive ones, and no support contract fixes that. It only pays for the consequences.

So if support costs feel high, the useful question is usually not "can we get support cheaper" but "why does this implementation need so much support." That is a different investigation and it is the one that actually reduces the bill. Our Sitecore XP technical debt audit is the version of that we run for clients, and it exists because the answer is nearly always measurable and nearly always never measured.

If you are buying Sitecore support, unhappy with what you have, or suspect your support cost is really a technical debt symptom, that is our work. We staff senior Sitecore specialists, we cover the front end and pipeline as well as the platform, and our hours never expire, so quiet months carry rather than evaporate. Book a call, or read about our Sitecore development and support practice.

Read next

• Sitecore Upgrade Services: What You Are Actually Buying: when support demand is really an upgrade signal.
• The Sitecore XP Technical Debt Audit: why some implementations cost so much more to support than others.
• Is Sitecore a Headless CMS?: why headless builds move most of the support surface outside Sitecore.
• Enterprise CMS in 2026: How to Choose the Platform and the Partner: the cluster pillar, including choosing a partner.
• Work with us: Sitecore development and support, or our headless CMS agency practice.