We just got back from an on-site meeting with marketing leaders who were paying enterprise DXP prices for what had effectively become a brochureware website.
This is the story of how we moved one organization off Sitecore XP 10.3, what they actually saved, and why we did not recommend the obvious upgrade path.
The Client We Inherited
The setup was familiar before we even looked under the hood. A mid-market organization running Sitecore XP 10.3, roughly 100,000 pages of content (most of it long-tail and rarely touched), about a million page views per year, and two content authors who used the editor on a typical week.
There was no personalization in production. No A/B testing. No marketing automation flows running through EXM. No commerce. No xDB segmentation strategy that anyone could point to. The site was, in every meaningful sense, brochureware: corporate pages, services, locations, leadership, news, and resources.
But they were paying for the full Sitecore Experience Platform. License, hosting, a Sitecore managed services retainer, premium support, and a partner agency that was billing them more than the platform itself. The annual run-rate was nearly $500,000 before we counted internal staff time spent on upgrades and patching.
Where the Money Was Actually Going
When we broke down the spend, it followed a pattern we see often:
Sitecore licensing. XP enterprise licensing typically begins at $100,000 to $150,000 per year and scales from there based on number of instances (CMs and CDs) and authors.
Managed services and hosting. Sitecore XP is not a platform you run casually. SQL Server, Solr, dedicated content delivery and content management roles, xDB infrastructure if you keep it enabled, plus the managed cloud or partner-hosted environment to run it all. The recurring infrastructure and managed services bill was roughly equivalent to the license.
The implementation partner. This was the line item that made everyone in the room quiet when we showed them the math. The client was paying their Sitecore partner over $300,000 a year on a standing retainer. For that money they were getting an offshore team that was perpetually rotating, a slide deck full of Sitecore MVP logos, and a backlog of small change requests that never seemed to close. They had a monthly burn of hours, but never got anything actually done.
The MVP credentials were real on paper and largely irrelevant in practice. The actual day-to-day work was being done by junior developers who had not built on Sitecore before, were learning on the client's dime, and were rotating off the account as fast as they were onboarded. Every reasonable request became a multi-week ticket. Simple content model changes turned into change orders. Bugs introduced in one sprint were reintroduced two sprints later because nobody on the team had been there long enough to remember the fix.
This is a pattern we see often enough that it deserves to be named. There is a category of Sitecore partner whose primary product is the logo on the homepage, not the work that gets delivered. The MVPs exist; they sit in pre-sales, on conference panels, and on the partner portal. The delivery team is somewhere else entirely. The client is paying premium-partner rates for what amounts to a learning environment for someone else's offshore bench.
Platforms get blamed for this. Sitecore, in particular, gets a worse reputation than it deserves because of how it is often delivered. The product is genuinely capable. The implementation pattern around it, in too many cases, is not.
Hidden cost: upgrade tax. XP 10.3 was already a known migration target. Mainstream support for the XP line is winding down toward 2028, and the major XP upgrades are widely documented as one to three months of effort for any non-trivial implementation. That cost wasn't on this year's invoice, but it was on the horizon every year, and the partner above was going to bill for it.
The honest summary: they were paying premium-platform prices for less than twenty percent of what they had licensed, and paying premium-partner prices for delivery that would have embarrassed a competent in-house team of two.
Why We Looked at SitecoreAI and Said No
The default recommendation in this scenario, from most Sitecore partners, would be SitecoreAI. We took it seriously. The platform itself is genuinely impressive, the architecture is cloud-native, the unified roadmap finally answers the "what is Sitecore in five years" question, and we generally like where it's going.
In our defense, we tried to push SitecoreAI. However, this client had such a bad taste in their mouth about Sitecore because of their bad implementation partner that they said it was a non-starter. This is one of the big "partners" too. Some of these partners in the highest tier are Sitecore's own worst enemy.
Don't blame us, seriously. Blame... well, we all know who. This partner has that reputation of winning the work at all costs and just in it for short term money grabs. Yup, them.
Other than the bad partner and poor implementation, we kept coming back to the same problem: the economics did not change. And the partner economics, in particular, were going to follow the client to the new platform if they were not careful.
SitecoreAI is still priced as enterprise DXP. The migration from XP to the SaaS platform is, in Sitecore's own framing, not an upgrade but a re-implementation. Content has to be re-modeled, custom .NET renderings rewritten as ContentSDK components, presentation details rebuilt in the new editor, and the content itself extracted from a proprietary SQL schema with no native portable export.
Now, a bunch of partners have all these gimmicky AI accelerators but Caveat Emptor. If it sounds too good to be true, it is. We wrote about some of the horror stories of these here
For an organization actually using personalization, xDB, EXM, and the broader marketing stack, that re-implementation cost has a clear ROI story. For a brochureware site with two authors and no personalization, we would have been moving the client to a more modern version of the same overbuilt cost structure, and likely the same kind of partner economics.
The question we kept asking ourselves was simple: what does this client need their CMS to actually do? Hold content, let two people edit it, render fast pages, and stay out of the way.
What We Built Instead
We moved them to Sanity for content and Cloudflare for delivery.
Sanity for the content backend. Two authors fit comfortably within the platform's standard team pricing, the Studio is genuinely usable without weeks of training, and the schema-as-code approach let us model their content types in days rather than months. Public pricing for the Growth plan is $15 per seat per month, and viewer seats are free for stakeholders who only need to review. Their entire content operation lives well within reasonable usage limits.
Cloudflare for hosting and delivery. A static site generated from Sanity content, deployed to Cloudflare Pages, served globally from the edge. Pages serves the static build at no cost for the traffic volumes this client sees, and the bandwidth, caching, security, and DDoS protection that come with Cloudflare's network would have been a separate line item on the old stack.
The architecture is boring on purpose. Content lives in Sanity. A build runs when content changes. Cloudflare serves the static output. There is no application server to patch, no database to upgrade, no Solr cluster to babysit, and no rendering pipeline that breaks when a NuGet package shifts.
There is also nothing here that requires a $300,000 retainer to maintain, but they do keep us around for enhancements and new features and pages.
The Migration: Under 90 Days
The full migration ran twelve weeks from kickoff to go-live, which surprised the client more than anything else we did.
A few things made that timeline possible:
The content was extractable. We pulled the existing pages from Sitecore via the item API, mapped them to a clean Sanity schema we designed for the new structure, and ran the import as NDJSON. Most of the work was deciding what to leave behind. Roughly thirty percent of the 100,000 pages were either duplicates, expired campaigns, or content the team admitted they had not touched in years.
The frontend was a rebuild, not a port. We did not try to recreate the old templates one-for-one. We designed a clean component set in the new stack, mapped the content model to it, and let the old presentation details stay in the past where they belonged.
There was no marketing automation, personalization, or commerce to migrate. This is the part that lets brochureware migrations move fast. When the platform is doing one job, replacing it is a small project. When it is doing twelve, it is not.
We trained the two authors in a single afternoon. They were productive in the new Studio by the end of the day. That is a real fact about Sanity that does not get said enough, and it is the answer to the question "what does our content team actually need to be effective."
The New Annual Run-Rate
The before-and-after numbers are the kind that change boardroom conversations:
- Sanity: under $400 per year at their current seat count and usage
- Cloudflare Pages: effectively free at this traffic volume; under $300 per year even with the paid Workers tier for some dynamic features
- Hosting infrastructure: eliminated
- Sitecore managed services retainer: eliminated
- Premium platform support: eliminated
- $300,000+ partner retainer: eliminated
- Future upgrade tax: eliminated
Annual savings, conservatively: in the range of $480,000 to $500,000, and the partner retainer alone accounted for more than sixty percent of it. The migration itself paid for itself in the first quarter after go-live.
When This Story Does Not Apply
So their are limits of this case study, because the wrong takeaway would be that every Sitecore client should do what this one did.
If you are actually using xDB personalization, running EXM campaigns, or have a marketing team that depends on Sitecore's segmentation and rules engine, the migration math looks completely different. Those capabilities have real value, and replacing them piecemeal across multiple SaaS tools can erase the savings. Good news is 99% of our Sitecore clients... don't.
If you have hundreds of authors, complex approval workflows, or multi-brand portfolios sharing a content backbone, the equation shifts again. Sanity scales there, but the planning is more involved than a brochureware project. We could also look at other platforms.
If you have a strong, working Sitecore practice in-house and a partner who is actually delivering against the retainer they bill for, stay where you are. The economics in this case study come from two gaps: the gap between what was licensed and what was being used, and the gap between what the partner was charging and what the partner was delivering. Close either of those and the story is different.
The Real Question to Ask
If you are running a brochureware site on an enterprise DXP, the question is not "which platform should we migrate to." The question is "what are we actually using, and who is actually doing the work." We have done enough of these reviews to know how often the answer is uncomfortable on both counts.
We are happy to do that review. It does not take long, and the conversation is more useful than another platform pitch or another MVP logo wall. If your annual platform spend has crept past what your content operation actually needs, or if your partner retainer has crept past what your partner is actually delivering, that gap is recoverable revenue. It is worth a real look.
For organizations evaluating their current platform against alternatives, the independent DXP Scorecard provides side-by-side platform scoring across hundreds of criteria, including total cost of ownership analysis for Sitecore XP, SitecoreAI, and Sanity. Scores are dynamic and date-stamped, and they reflect platform realities as of the most recent evaluation.
