Sitecore XP Technical Debt Scorecard
A working spreadsheet that scores six domains of Sitecore XP technical debt out of 120, bands the result, and calculates what the debt adds to a migration estimate.
What this is
A working spreadsheet that turns a Sitecore XP installation into one number leadership can act on. Six domains, scored zero to twenty each, totalling out of 120, with a readiness band and a migration cost range that calculate themselves.
It exists because most Sitecore audits are general best-practice checklists. They tell you what is not ideal. They do not tell you what modernization will cost, what blocks migration outright, and which domain to fund first. This scorecard is built around measurement instead: every domain is scored the same way every time, so results are comparable across sites, across brands, and across the two years between when you first asked the question and when you finally get budget.
If you are still on XP, the platform is not your biggest problem. The debt piled on top of it is what decides whether modernization is a project or an ordeal.
What it scores
Six domains, each zero (clean) to twenty (severe).
1. Content Architecture. How far the content model sits from something a headless front end can consume. Deeply nested trees that no longer match how the business is organized, page-centric templates instead of component-centric models, presentation details hard-coded into templates, no separation between content and layout. This is the number one driver of migration cost, because every item that has to be restructured rather than lifted and shifted is billable work.
2. Personalization and xDB. How much of the site depends on xDB, which does not exist in XM Cloud. Unused personalization rules, custom facets nobody can explain, legacy engagement plans, marketing automation that stopped running years ago. Every live dependency here is a migration blocker rather than a migration inconvenience.
3. Search and Indexing. How tightly search is coupled to Solr specifically, rather than to search in the abstract. Custom schema modifications, computed fields, search logic embedded directly in controllers, no abstraction layer. Solr is not part of XM Cloud, and rework scales directly with that coupling.
4. Custom Code and Pipelines. Whether the migration is a refactor or a full rebuild. Pipeline overrides on core Sitecore behavior, processors with no documentation and no owner, hard-coded server paths, no dependency injection. This is the domain that quietly turns a fixed-bid proposal into a change order three months in.
5. Multi-Site and Multi-Tenancy. How much has to be untangled before one brand can move without the others. Shared content trees, shared templates across unrelated sites, no tenant isolation, one deployment pipeline forcing every site to release together. The costliest single domain, and the one where estimates go furthest off track, because the coupling is invisible until somebody tries to move one site.
6. DevOps and Infrastructure. Whether your team can safely test the fixes the other five domains require. Manual deployments, no CI/CD, outdated Windows or SQL Server, no containerization, no environment parity. This one does not block migration the way xDB and Solr do. It does something arguably worse, which is slow every other fix down.
How to use it
The workbook has four tabs and expects you to work right to left through the middle two.
Domain Detail is where the audit actually happens. Every indicator from the framework is a row with an observed rating (0 clean, 1 partial, 2 severe) and an evidence column. Fill in the evidence. Six months later the notes are the only part anybody can defend in a budget meeting. Each domain block calculates a suggested zero to twenty score from your ratings.
Scorecard is the summary a stakeholder reads. Enter your own zero to twenty score per domain. The suggested score from Domain Detail sits in the next column as a reference, not a verdict, because one load-bearing indicator can justify a higher score than the arithmetic gives you. The total, the readiness band, and the cost uplift range all calculate from there.
How to Use carries the band table, the cost multipliers, the seven-question readiness check, and a note on what this audit deliberately ignores.
Worked Example is a filled installation scoring 70 out of 120, so you can see what a real result looks like before you produce your own.
Every cell you are expected to touch is blue text on a yellow fill. Nothing else expects your typing.
Budget roughly half a day per domain on a mid-size installation, and more on domains four and five, which are the hardest to assess from the outside.
How to read the bands
The total out of 120 lands in one of five bands:
| Total | Band | What it means |
|---|---|---|
| 0 to 24 | Low | Modernization is a project, not a rescue. Fund the roadmap and move. |
| 25 to 48 | Moderate | Fixable inside a normal delivery cycle. Address the top two domains first. |
| 49 to 72 | High | Estimates will move once engineering starts. Remediate before you scope a migration. |
| 73 to 96 | Critical | Expect the migration to cost close to double a clean-site estimate. |
| 97 to 120 | Migration-blocking | Do not scope a migration yet. Reduce debt first or the project stalls mid-flight. |
The band is the headline, but the per-domain scores are what you act on. A site at 60 with all six domains sitting around 10 is a very different remediation plan from a site at 60 that is clean everywhere except multi-site at 19.
How the cost range works
Each domain carries an observed cost impact, drawn from real enterprise modernization projects rather than published industry benchmarks:
| Domain | Adds at full debt |
|---|---|
| Content modeling | +30% to +50% |
| xDB dependencies | +20% to +40% |
| Custom pipelines | +15% to +25% |
| Solr customizations | +10% to +20% |
| Multi-site complexity | +40% to +80% |
| DevOps debt | +20% to +30% |
These are additive. They stack rather than being a menu you pick one item from, and that is the single most common way people misread this framework. The workbook applies each range in proportion to the score you gave the domain, so a 10 out of 20 on content modeling applies half of its 30 to 50 percent range, then sums the six.
A site carrying heavy multi-site, content modeling, and pipeline debt at the same time can land at roughly double a clean-site estimate, occasionally worse. That is the worst case rather than the median. Use the range to size the conversation, then re-estimate properly once remediation scope is known. It is also why two XP sites of similar page count quote very differently, which is usually the question that prompted the audit in the first place.
Where to start once you have a score
Fund the highest-scoring domain first, with one exception. If DevOps and Infrastructure scores above moderate, start there regardless of rank. A team without CI/CD or environment parity cannot safely test the content model changes, the search abstraction, or the code refactors that the other five domains require, so remediation stalls across the board rather than in one place. It is also the domain you can start fixing today without touching xDB, Solr, or a single pipeline, and without committing to a migration at all.
What this deliberately does not score
GlassMapper, TDS, Unicorn, and custom MVC frameworks are absent on purpose. They are implementation choices rather than parts of the XP platform, and none of them survive a migration to XM Cloud, which replaces all server-side code and MVC patterns with a new headless front end. Scoring them would inflate the total without changing a single decision.
Companion reading
This scorecard is the instrument behind The Sitecore XP Technical Debt Audit: Six Domains That Decide Your Migration Cost, which walks through each domain with examples from real audits. If you are still deciding whether to move at all, Enterprise CMS in 2026: How to Choose the Platform and the Partner covers the platform and partner decision behind every modernization call, and Enterprise Headless CMS, Explained breaks down what "enterprise" adds on top of "headless" for teams evaluating XM Cloud.