Sitecore Upgrade Services: What You Are Actually Buying

Most Sitecore upgrade proposals are priced around the version jump. Move from this version to that version, migrate the databases, run the conversion scripts, regression test, go live. The version jump is real work, and it is also rarely where the budget goes.

The budget goes into custom code that assumed behavior the new version changed, integrations nobody documented, a content model that drifted for a decade, and the discovery, usually in month three, that a business-critical module has no supported equivalent. A quote that does not price those is not a cheaper quote. It is the same project with the expensive parts still ahead of you.

Here is what a Sitecore upgrade actually contains, and how to scope one so the number you approve resembles the number you spend.

What are Sitecore upgrade services?

Sitecore upgrade services move an existing Sitecore implementation from an older version to a supported current one, covering platform version migration, custom code remediation, module replacement, content and media migration, integration rework, and regression testing. In practice the platform migration is the smallest component. Custom code and integrations usually dominate.

That ratio is the single most useful thing to know before you read a proposal.

Should you upgrade or re-platform?

Ask this before anything else, because it changes the entire shape of the project and most organizations answer it by default rather than by decision.

Upgrade means staying on Sitecore Experience Platform and moving to a newer XP version. You keep your architecture, your rendering approach, and most of your code. You get supported software and a security posture your auditors will accept.

Re-platform means moving to XM Cloud, which is not a version upgrade at all. It is a move to a different product with a different delivery model, a headless front end, and the composable stack behind it. Your content moves. Most of your rendering code does not.

The fork usually resolves on three questions.

How far behind are you? Coming from a recent version, an upgrade is a contained project. Coming from an older architecture, where the analytics and data layer changed shape between major versions, you are doing so much reconstruction that you are effectively re-platforming anyway, and doing it onto architecture that is itself now a generation old. At that distance, going to XM Cloud is often the better value even though it looks like the bigger project.

Do you actually use the Experience Platform half? XP includes the analytics and personalization stack. Plenty of organizations run XP and use it purely as a content management system, having never operated the marketing capability at all. If that is you, you are carrying the operational weight of a platform you use a fraction of, and re-platforming to XM Cloud (or to XM rather than XP) removes cost rather than adding it. Check this honestly, because the answer is frequently "no" at organizations that believe the answer is "yes."

Who will run it in three years? An upgrade keeps you on infrastructure that needs Sitecore .NET specialists. A re-platform to XM Cloud moves most engineering into a mainstream front-end stack that you can hire for. Given how scarce senior Sitecore developers are, this is a strategic question rather than a technical one. We walked through the headless side of that trade in is Sitecore a headless CMS.

There is a fourth answer nobody sells you: do nothing, deliberately, with a date. If the platform is stable, supported, and serving the business, "not this year, revisited next January, with the security posture documented" is a legitimate position. What is not legitimate is drifting into it by never deciding, which is how organizations end up several versions behind on unsupported software with no plan.

What does an upgrade project actually contain?

Six phases. The proposals that overrun are almost always the ones that compress or skip the first.

1. Assessment. Inventory every customization, module, integration, and template. Establish what the current implementation actually does, which is never fully documented and is often surprising to the people who own it. This phase produces the estimate. Skipping it produces a guess.

2. Code remediation. Custom code updated for API changes, deprecated calls replaced, and anything relying on internal behavior that shifted between versions reworked. This is usually the largest single line item and the hardest to estimate without phase one.

3. Module and integration rework. Third-party modules need supported versions or replacements, and there is not always one. Custom integrations to CRM, commerce, search, or identity need retesting and often rework. This is where the unpleasant surprises live, because the module with no forward path is discovered here rather than in the proposal.

4. Content and media migration. Moving the content tree, media library, and version history. Mechanically well-trodden. The complication is scale and cleanliness, and this is the natural moment to drop the fifteen thousand unused media items nobody wants to be responsible for deleting.

5. Regression testing. Every template, rendering, workflow, and integration path exercised. The step most often cut when the timeline slips, and the one whose absence surfaces publicly.

6. Deployment and cutover. Environment builds, deployment pipeline updates, a rehearsed cutover, and a rollback plan you have actually tested rather than written.

What makes Sitecore upgrades overrun?

Four things, in our experience and in roughly this order of damage.

Undocumented customization. The implementation does something important that is not in any document, and the person who built it left in 2019. It surfaces during regression testing, at the worst possible moment. Only a genuine assessment phase catches this early, which is precisely why assessment is worth paying for separately and honestly.

Content model drift. Templates added over years without governance, inheritance chains nobody can explain, fields that exist because of a campaign that ended in 2021. Every one of those is upgrade surface area. This is the domain we built the Sitecore XP technical debt audit around, because it is measurable in advance and almost never measured.

A module with no forward path. Something load-bearing has no supported version. Now you are building a replacement inside an upgrade project that was not scoped to build anything.

Environment and pipeline debt. The upgrade is not just the application. It is the build pipeline, the environment topology, the search provider, the certificates, and the deployment process. Teams that have not touched their pipeline in five years are upgrading two things at once and usually priced one.

Notice that three of the four are knowable before the project starts. That is the argument for a paid assessment: not because assessment is valuable in itself, but because it converts the three knowable risks into line items instead of overruns.

What is worth fixing on the way through

An upgrade touches nearly everything, which makes it the cheapest moment for a set of improvements that are expensive as standalone projects. Five worth putting in scope deliberately, with the budget stated rather than smuggled in.

Content model consolidation. You are already regression testing every template. Retiring the ones nobody uses and merging near-duplicates costs a fraction of what it costs as its own initiative later.

Deployment pipeline modernisation. If deployments are partly manual, the upgrade is when you fix it, because you are going to exercise the pipeline repeatedly during rehearsals anyway.

Media library cleanup. Same logic. You are migrating the library regardless, so migrating less of it is free.

Documentation of what actually exists. The assessment phase produces this as a by-product. Capture it as a deliverable rather than letting it live in one consultant's head, and specify it in the contract.

Front-end metadata and redirect hygiene. If URLs move at all, this stops being optional. Even when they do not, an upgrade is a good moment to verify that titles, canonicals, and structured data are being emitted correctly, because nobody has checked in years.

What is not worth adding: new features. An upgrade that also delivers a redesign and three new integrations is two projects sharing one timeline and one risk register, and it is the single most reliable way to make an upgrade late.

How should you evaluate an upgrade partner?

Six questions. The answers separate partners quickly.

"What does your assessment phase produce, and can I buy it separately?" A partner confident in their assessment will sell it standalone. One who insists it is only available bundled with the delivery they also want to sell is protecting an estimate rather than an outcome. Being able to buy assessment alone is also how you take the resulting scope to a second bidder, which is the point.

"Show me the risk register from your last upgrade." Not a sanitized case study. Every real upgrade has a register full of unpleasant discoveries. A partner who cannot produce one either has not done many or is not tracking them.

"Who specifically is doing the work?" Enterprise consulting has a well-known pattern where the senior people appear at the pitch and disappear at delivery. Ask for named engineers and their availability, and put it in the contract.

"What happens after go-live?" Upgrades produce a tail of defects for weeks. A partner whose engagement ends at cutover is leaving you the hardest part.

"What is your position on re-platforming instead?" A partner who never recommends XM Cloud, or always recommends it, is selling their capability rather than assessing your situation. You want the one who asks what you actually use.

"How will we know it worked?" Agree acceptance criteria before the work starts: performance targets, functional coverage, and search visibility. Especially search visibility, because an upgrade that changes URL structure without a redirect map can cost more in lost organic traffic than the project cost, and it is invisible until it is not.

How should you scope and budget one?

Two practices matter more than any estimating technique.

Buy the assessment first, as its own engagement. It is a small fraction of the project and it converts the unknown into a scope. Then take that scope out to bid, including to the partner who produced it. Any partner who objects to that has told you something useful.

Budget the tail. Set aside meaningful contingency for the weeks after go-live, and name who spends it. Upgrades do not end at cutover, and a project with no post-launch budget will handle its first production defect as an emergency change request instead of as expected work.

The pattern we see most in how organizations get this wrong is not underestimating the work. It is structuring the engagement so that discovery, delivery, and support are one fixed price agreed before anyone looked properly. Split the assessment out, and the rest becomes a normal project instead of a bet.

If you are pricing an upgrade, deciding between upgrading and moving to XM Cloud, or holding a proposal that feels light on the parts described above, that is our work. We run assessments as standalone engagements precisely so the resulting scope is yours to take anywhere. Our support hours never expire, so the post-launch tail is covered without a retainer you stop using. Book a call, or read about our Sitecore development and support practice.

Read next

• The Sitecore XP Technical Debt Audit: the six domains that decide what your upgrade or migration will cost.
• Is Sitecore a Headless CMS?: the XM Cloud side of the upgrade-or-re-platform fork.
• Sitecore DXP: What Composable Changed: what you take on if you re-platform rather than upgrade.
• Enterprise CMS in 2026: How to Choose the Platform and the Partner: the cluster pillar, including how to pick a partner.
• Work with us: Sitecore development and support, or our headless CMS agency practice.