[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"blog-site-config":3,"$fKO4dpEwyRvq5BY0MXlApz_K0mdRE8coapkP2fLXZlFY":6,"mdc-g4uon-key":156},{"gaMeasurementId":4,"bookingUrl":5},"G-7BYTDCVDDR","https:\u002F\u002Ftidycal.com\u002Fcmdcntr\u002F30-minute-meeting",{"post":7,"related":105},{"id":8,"slug":9,"title":10,"description":11,"summary":12,"content":13,"coverImageUrl":14,"coverImageAlt":15,"tags":16,"targetKeywords":23,"faq":27,"howTo":43,"demo":65,"featured":66,"tool":65,"status":67,"reviewNote":65,"metaTitle":68,"metaDescription":69,"canonicalUrl":65,"sourceTicketId":65,"agentGenerated":66,"publishedAt":70,"publishedBy":71,"createdAt":72,"updatedAt":70,"authorId":73,"clusterId":74,"ctaId":75,"author":76,"cluster":87,"cta":91,"tools":97},"726f58e8-0510-43de-bf8f-6d22126fed97","sitecore-xp-technical-debt-audit","The Sitecore XP Technical Debt Audit: Six Domains That Decide Your Migration Cost","A clear, practical audit that exposes the real technical debt holding XP back and shows enterprises how to fix it before migration becomes painful.","Sitecore XP technical debt, not XP itself, is what makes modernization slow and expensive. This audit scores six domains: content architecture, personalization and xDB, search and indexing, custom code and pipelines, multi-site complexity, and DevOps maturity. Multi-site is the costliest, adding 40 to 80 percent to migration. Score each domain and you have a defensible readiness number for leadership.","## XP Isn't Dead, But Your Technical Debt Might Be Killing You\n\nMost Sitecore audits I encounter are general best-practice checklists. This one is\nXP-specific and built around measurement: what increases modernization cost, what\nblocks migration, and what creates lasting risk. I built it from real enterprise XP\naudits, and I score every domain the same way each time so the results are\ncomparable across engagements.\n\nI spend a lot of time inside legacy Sitecore XP installations. Some still run\nsurprisingly well. Others look stable on the surface but are quietly drowning in\ntechnical debt, built up over years of rushed releases, staff turnover, and\narchitectural shortcuts.\n\nIf you are still on XP, the platform is not your biggest problem. The real threat is\nthe debt around it, which determines whether modernization is smooth or a\nbudget-breaking ordeal.\n\nAcross the XP audits I have run, organizations that addressed debt early cut their\nprojected migration cost by roughly thirty to sixty percent. A structured audit gives\nleadership a clear picture of readiness and extends the life of existing\ninstallations.\n\nBefore the audit itself, it's worth understanding the pressures that make XP harder\nto maintain today than when most of these platforms were built.\n\n## Key Takeaways\n\n- Technical debt, not XP itself, is what makes modernization slow and expensive.\n\n- Six domains drive most XP migration risk: content architecture, personalization\n  and xDB, search, custom code, multi-site complexity, and DevOps maturity.\n\n- Multi-site complexity is the costliest single domain, adding forty to eighty\n  percent, and it stacks with the others rather than replacing them.\n\n- A zero to twenty scorecard per domain, totaling out of 120, gives leadership a\n  shared and quantifiable view of readiness.\n\n- Enterprises can cut debt now, short of migrating to an\n  [enterprise headless CMS](\u002Fblog\u002Fenterprise-cms\u002Fenterprise-headless-cms-explained),\n  using the roadmap below.\n\n- Teams without in-house XP expertise close these gaps faster by bringing in\n  [Sitecore upgrade services](\u002Fservices\u002Fsitecore) that have run the migration before.\n\n## What Changed Around XP\n\n### Infrastructure cost on self-managed hosting\n\nIn every XP audit I run, infrastructure cost is one of the first red flags. XP\nrequires a heavy footprint: CM, CD, SQL, Solr, xConnect, and Identity servers, all of\nwhich must be patched, monitored, scaled, and secured.\n\nCloud providers have shifted pricing toward consumption billing, and long-running\nWindows VMs, SQL licensing, storage, and bandwidth have all become significantly more\nexpensive. I have seen XP customers spend more on infrastructure in a single year\nthan XM Cloud would cost over three.\n\nOne client had a Solr cluster that required manual failover. Another had SQL servers\ntwo versions behind, because upgrading them would break custom pipelines. These are\nnot theoretical; I see them in audits every month.\n\nXP's cost curve goes up. XM Cloud's goes down. Staying on XP is a financial\nliability, not just a technical decision.\n\n### The talent pool moved to headless and SaaS\n\nThe XP talent pool is shrinking, not because developers cannot work on XP, but\nbecause the ecosystem has moved on. Sitecore's roadmap prioritizes XM Cloud, headless\nSXA, Next.js, TypeScript, GraphQL, and SaaS-native services.\n\nIn my audits, I often meet teams who inherited XP from developers who left years ago.\nThe people maintaining the platform today are working with legacy MVC controllers and\n.NET Framework, paired with Solr and xDB patterns that modern Sitecore work no longer\nrequires.\n\nThis is an economic and ecosystem shift, not a capability gap. If your team lacks\ndeep XP experience, bringing in a partner who has already run an XP to XM Cloud\nmigration usually closes the gap faster than training up on a shrinking skill set.\n\n### Zero Trust expectations XP was never built to meet\n\nSecurity expectations have changed dramatically. Enterprises now operate under Zero\nTrust models with continuous compliance, automated patching, container isolation,\nsecret rotation, cloud-native identity, and real-time threat detection as baseline\nexpectations, not extras. XP was not built for any of this.\n\nIn one audit, I found an Identity Server instance that had not been patched in four\nyears, because updating it would break a custom login flow. In another, xConnect ran\non an outdated Windows Server version no longer receiving security updates.\n\nOrganizations end up bolting on compensating controls and manual patch cycles just to\nmeet baseline expectations, and every year the gap widens. XM Cloud offloads nearly\nall of this to Sitecore's managed SaaS environment.\n\n### The pressures every XP team already knows about\n\nThese issues are familiar to every XP team I work with:\n\n- Solr overhead: custom schemas, computed fields, fragile indexing dependencies\n\n- Legacy personalization tied to xDB: years of accumulated rules and custom facets\n\n- Custom pipelines that introduce unpredictable behavior and resist refactoring\n\n- Multi-site architectures with shared templates that are hard to separate\n\nXP can still run well. It's the debt built up over years of rushed deployments that\nmakes modernization difficult.\n\n## What This Audit Deliberately Ignores\n\nSome items commonly mentioned in agency XP audits do not need to be covered here:\nGlassMapper, TDS, Unicorn, and custom MVC frameworks. These are\nimplementation-specific choices, not part of the XP platform itself, and none of them\nsurvive migration to XM Cloud, which replaces all server-side code and MVC patterns\nwith a new headless front end.\n\nBecause they do not influence cost, complexity, or architectural risk, they are not\nrelevant here.\n\n## The Six Domains\n\nThis audit framework breaks XP technical debt into six domains. Each domain contains\nspecific indicators that reveal modernization risk and migration cost. This is the\nsame structure I use in real enterprise audits.\n\n![The six domains of Sitecore XP technical debt arranged around the platform core: content architecture, personalization and xDB, search and indexing, custom code and pipelines, multi-site complexity, and DevOps maturity, each carrying its own risk score](\u002Fcovers\u002Fenterprise-cms\u002Fvisuals\u002Fxp-debt-six-domains.webp)\n\nTwo of the six block a migration outright, because XM Cloud has no xDB and no Solr.\nThe other four decide what it costs. Each one closes with the signal that pushes it\ninto high-risk territory, so you can score your own installation as you read.\n\n### Domain 1: Content Architecture\n\nContent modeling is the number one driver of migration cost, and it is the domain\nwhere I see the widest gap between what a site looks like on the surface and what it\nactually costs to move. In my audits, I often find:\n\n- Deeply nested content trees that no longer map to how the business is organized\n\n- Page-centric templates instead of component-centric models\n\n- Presentation details hard-coded into templates\n\n- Lack of reusable components\n\n- No separation between content and layout\n\n- Content structures not ready for headless delivery\n\nThis debt accumulates quietly. A site launches with a clean structure, then years of\ncampaigns and one-off landing pages get bolted on wherever there was room in the\ntree. Nobody sets out to build a content model this way; it happens one urgent\nrequest at a time.\n\n**Why it matters:** Poor content architecture multiplies migration cost because every\ncontent item must be restructured, remapped, or rebuilt rather than lifted and\nshifted. A headless front end expects components with well-defined fields, not\ntemplates that mix layout markup into the content model. When I score this domain\nhigh risk, the fix is rarely a quick cleanup: it is a content model redesign, a\nmigration script, and author retraining, three workstreams hiding inside what looks\nlike one line item on a project plan.\n\n**What I look for in an audit:** I sample content across every site section, not just\nthe homepage tree, because debt concentrates where leadership stops paying attention\nafter launch. Campaign landing pages, legacy microsites, and anything built under\ndeadline pressure are the first places I check. Those areas usually account for a\ndisproportionate share of the migration estimate.\n\n> **Scores 15 or higher when:** templates carry presentation markup, the same\n> component is rebuilt per section, and no one can point to a reusable field model.\n\n### Domain 2: Personalization and xDB\n\nMany XP implementations have personalization rules that were created years ago and\nnever revisited. I often find:\n\n- Hundreds of unused or outdated personalization rules\n\n- Custom xDB facets that nobody currently maintaining the site can fully explain\n\n- Legacy engagement plans\n\n- Marketing automation that no longer runs\n\n- Goals, campaigns, and outcomes that are unused or misconfigured\n\nI have audited installations where fewer than ten percent of the active\npersonalization rules were still doing anything measurable. The rest were dead\nweight, left in place because nobody wanted to be the one who deleted a rule that\nmight matter. That instinct is understandable, and it is exactly how xDB debt\ncompounds over a decade.\n\n**Why it matters:** xDB is not part of XM Cloud. Any dependency on xDB becomes a\nmigration blocker, not a migration inconvenience. Before you can move, someone has to\ninventory every rule, facet, and engagement plan, decide what still reflects current\nbusiness goals, and rebuild the ones worth keeping on a modern personalization layer.\nSkipping that inventory does not make the debt disappear. It just moves the discovery\nto the middle of the migration, where it is far more expensive to deal with.\n\n**What I look for in an audit:** ownership is the real signal here. For every active\nrule, I ask who owns it on the marketing side and whether that person could explain\nwhat it does without looking it up. Rules nobody can explain are candidates for\nretirement, not migration, and retiring them before the audit closes shrinks the\npersonalization rebuild considerably.\n\n> **Scores 15 or higher when:** custom xDB facets are in play, engagement plans still\n> run, and no marketer can name the owner of an active rule.\n\n### Domain 3: Search and Indexing\n\nSearch is one of the most fragile parts of XP. I regularly encounter:\n\n- Custom Solr schema modifications\n\n- Multiple index rebuild dependencies that no one wants to touch\n\n- Custom computed fields\n\n- Search logic embedded directly in controllers\n\n- No abstraction layer between the application and the search engine\n\nSearch debt tends to be invisible until something breaks: a schema change in one part\nof the site cascades into a rebuild that takes down search elsewhere, because the two\nwere never meant to be independent.\n\n**Why it matters:** Solr is not part of XM Cloud. Custom search logic must be\nrewritten or replaced, and the amount of rework scales directly with how tightly\nsearch was coupled to the rest of the application. A site with a clean abstraction\nlayer over search can usually swap in a cloud search provider with moderate effort. A\nsite with search logic scattered across controllers and computed fields requires a\nmuch closer audit, because nobody can say with confidence what will break when the\nunderlying engine changes.\n\n**What I look for in an audit:** I trace a handful of real search queries end to end,\nfrom the search box to the index to the result. That trace usually reveals how many\nlayers a query passes through and how many of those layers assume Solr specifically,\nrather than search in the abstract. The more Solr-specific assumptions I find baked\ninto the request path, the higher this domain scores, and the more time I budget for\nthe search rewrite in any migration plan.\n\n> **Scores 15 or higher when:** controllers query Solr directly, computed fields carry\n> business logic, and a schema change forces a full rebuild.\n\n### Domain 4: Custom Code and Pipelines\n\nCustom code is often the largest source of XP technical debt. I frequently see:\n\n- Custom pipelines overriding core Sitecore behavior\n\n- Processors with no documentation and no clear owner\n\n- Legacy MVC controllers doing work that belongs in services\n\n- Hard-coded dependencies on specific server paths or configuration values\n\n- No dependency injection\n\n- No abstraction for external services\n\nThis is the domain where I spend the most audit time, because it is the hardest to\nassess from the outside. A pipeline override might be a two-line tweak or it might be\nload-bearing for half the site's functionality, and you often cannot tell which until\nyou try to remove it.\n\n**Why it matters:** Custom code determines whether migration is a refactor or a full\nrebuild. Well-documented, cleanly separated custom code can often be ported with real\neffort but a clear path. Undocumented pipeline overrides and processors with no owner\nhave to be reverse-engineered before anyone can safely decide whether to keep,\nrewrite, or drop them. That reverse-engineering work is what quietly turns a\nfixed-bid migration proposal into a change order three months in.\n\n**What I look for in an audit:** I ask for the pipeline configuration files first,\nbefore touching any code, and compare them against out-of-the-box Sitecore to see how\nmuch has been overridden. A handful of documented overrides is a very different\nmigration than a pipeline rewritten with no record of why, and that difference is\noften the single biggest swing factor in a migration estimate, since it decides\nwhether the custom code domain scores as a refactor or a rebuild.\n\n> **Scores 15 or higher when:** pipeline overrides are undocumented, no dependency\n> injection exists, and removing a processor is something nobody will risk.\n\n### Domain 5: Multi-Site and Multi-Tenancy\n\nMany XP installations have grown organically into multi-site platforms. Common issues\ninclude:\n\n- Shared content trees across brands\n\n- Shared templates across unrelated sites\n\n- No tenant isolation\n\n- Cross-site dependencies in rendering code\n\n- Shared media libraries with no ownership boundaries\n\n- Shared deployment pipelines that force every site to release together\n\nMulti-site debt is different from the other five domains, because it is architectural\nrather than purely technical. You cannot fix it with a refactor. You have to decide,\nas an organization, which sites actually need to be independent and which ones were\nonly sharing infrastructure because it was convenient at the time, often years before\nanyone currently on the team was involved in the decision.\n\n**Why it matters:** Multi-site complexity adds forty to eighty percent to migration\ncost and timeline on its own, more than any other single domain, and it stacks on top\nof content and pipeline debt rather than replacing them. Separating tightly\ncoupled sites means untangling shared templates, splitting media libraries, and\nrebuilding deployment pipelines so that one brand's release no longer depends on\nanother's. This is consistently the domain where initial migration estimates go\nfurthest off track, because the coupling is invisible until someone tries to move one\nsite without the other four.\n\n**What I look for in an audit:** I ask each brand or site owner, separately, which\nother sites they believe depend on theirs. The gap between what they think is shared\nand what is actually shared in code is usually significant, and that gap is a good\npredictor of how much the migration estimate will move once engineering starts\nuntangling it. When three site owners give three different answers to the same\nquestion, that alone is a high-risk signal.\n\n> **Scores 15 or higher when:** brands share templates and media libraries, and one\n> site cannot ship a release without the others going with it.\n\n### Domain 6: DevOps and Infrastructure\n\nXP's infrastructure footprint is often outdated. I regularly find:\n\n- Manual deployments run by a specific person who knows the steps\n\n- No CI\u002FCD pipeline\n\n- On-prem hosting with no path to cloud\n\n- Outdated Windows Server or SQL Server versions\n\n- No containerization\n\n- No automated testing\n\n- No environment parity between staging and production\n\nDevOps debt does not directly block migration the way xDB or Solr dependencies do. It\ndoes something arguably worse: it slows down every other fix on this list. Teams\nwithout CI\u002FCD or environment parity cannot safely test the content model changes,\nsearch abstraction, or code refactors that the other five domains require, so\nremediation stalls across the board rather than in one place.\n\n**Why it matters:** Infrastructure debt is the silent killer of XP longevity. It is\nalso the domain most enterprises can start fixing immediately, independent of any\nmigration decision. Standing up CI\u002FCD, containerizing the application, and getting\nstaging and production into parity does not require touching xDB, Solr, or custom\npipelines at all. It just requires deciding to do it, which is why I recommend most\norganizations start their remediation here.\n\n**What I look for in an audit:** the fastest signal is asking how a deployment\nactually happens today. If the honest answer involves a specific person, a checklist\nin a shared document, and a maintenance window, that tells me more about overall\nmodernization readiness than almost anything else in the audit, because it usually\npredicts the maturity of every other domain too.\n\n> **Scores 15 or higher when:** deployment depends on one person, staging and\n> production have drifted, and there is no automated test to catch the difference.\n\n## Scoring It: 120 Points Across Six Domains\n\nScore each of the six domains from zero to twenty, where zero is clean and twenty is\nsevere. Add the six scores for a total out of 120.\n\n| Total | Band | What it means for the business |\n|---|---|---|\n| 0 to 24 | Low | Modernize on your own schedule |\n| 25 to 48 | Moderate | Remediate the top two domains before scoping a migration |\n| 49 to 72 | High | Budget for remediation as its own project, not a migration line item |\n| 73 to 96 | Critical | Any fixed-bid migration quote at this level will move |\n| 97 to 120 | Migration-blocking | Remediate first. Migrating now converts debt into overrun |\n\nThis scorecard gives leadership a clear, quantifiable view of XP posture, and because\nevery domain uses the same scale, it also shows which domain to fund first.\n\nYou do not have to build the sheet yourself. The\n[Sitecore XP Technical Debt Scorecard](\u002Ftools\u002Fsitecore-xp-technical-debt-scorecard) is\nthe working version of this framework: every indicator below as a scored row, the\ntotal and band calculated for you, and a worked example of a real installation so you\ncan see what a finished audit looks like before you start your own.\n\n## What Each Domain Adds to the Migration Bill\n\nThese are the ranges I have observed across enterprise modernization projects, not\npublished industry benchmarks. Each figure is what that domain adds on its own, so\nread them as additive multipliers rather than a menu to pick from:\n\n| Debt source | Adds on its own | Why it lands there |\n|---|---|---|\n| Content modeling | **+30 to 50%** | Every item is restructured, not moved |\n| Multi-site complexity | **+40 to 80%** | Untangling shared templates, media, pipelines |\n| xDB dependencies | **+20 to 40%** | Rules and facets rebuilt on a new layer |\n| DevOps debt | **+20 to 30%** | Slows every other remediation stream |\n| Custom pipelines | **+15 to 25%** | Reverse-engineering before any decision |\n| Solr customizations | **+10 to 20%** | Search rewritten against a new engine |\n\n![How Sitecore XP debt compounds: individual domain multipliers stacking on a baseline migration estimate until a site carrying several at once reaches roughly double the clean-site cost](\u002Fcovers\u002Fenterprise-cms\u002Fvisuals\u002Fxp-debt-compounding.webp)\n\nThey also compound. A site carrying heavy multi-site, content modeling, and pipeline\ndebt at the same time can land at roughly double a clean-site estimate, occasionally\nworse. That is the worst case rather than the median, and it is why two XP sites of\nsimilar size can quote very differently.\n\n## Cutting Debt Without Committing to a Migration\n\nEnterprises can reduce technical debt today without committing to migration. In my\naudits, I often recommend:\n\n- Introducing headless front ends such as Next.js and Vercel (see this\n  [headless vs. traditional CMS breakdown](\u002Fblog\u002Fenterprise-cms\u002Fheadless-cms-vs-traditional-cms)\n  if you haven't settled on the architecture)\n\n- Externalizing personalization and replacing Solr with cloud search\n\n- Introducing dependency injection and abstraction layers\n\n- Cleaning up content models and removing unused xDB features\n\n- Introducing CI\u002FCD and containerizing XP\n\n- Documenting pipelines and processors\n\nThis roadmap extends XP's life while preparing for future modernization. If the\nremediation list runs longer than your team can absorb alongside its normal roadmap,\nour [Sitecore services](\u002Fservices\u002Fsitecore) cover the audit and the remediation work\nitself.\n\n## The Seven-Question Readiness Check\n\nIf you do nothing else from this article, answer these seven questions with your\nengineering lead in the room. Every \"no\" is a number on your migration invoice.\n\n| # | Ask your team | A \"no\" means |\n|---|---|---|\n| 1 | Is content headless-ready? | Content model redesign, migration scripts, author retraining |\n| 2 | Are personalization rules documented? | An inventory project before anyone can scope the rebuild |\n| 3 | Is xDB usage minimal? | A migration blocker, not an inconvenience |\n| 4 | Are pipelines documented? | Reverse-engineering, and a fixed bid that will not hold |\n| 5 | Is search abstracted? | A search rewrite scoped blind |\n| 6 | Is multi-site isolated? | The single largest swing factor in the estimate |\n| 7 | Is DevOps automated? | Every other fix on this list gets slower |\n\n> **How to read your answers:** one or two \"no\" answers is a normal, healthy backlog.\n> Four or more, and remediation is its own project with its own budget, not a\n> workstream you can hide inside a migration. Score the six domains properly before\n> anyone commits to a date.\n\n## XP Isn't the Problem, Technical Debt Is\n\nXP remains a powerful platform, and a well-run installation can still serve an\nenterprise well. What determines whether modernization is smooth or painful is\ntechnical debt, not the platform. A structured audit gives organizations clarity,\nreduces migration cost, and ensures future modernization, to an enterprise headless\nCMS like XM Cloud or elsewhere, is strategic rather than reactive.\n\nThe organizations that succeed over the next few years will be the ones that\nunderstand their debt now and reduce it before migration turns urgent.\n\n## Further reading\n\nThis piece is adapted, with permission, from David Walker's\n[The Sitecore XP Technical Debt Audit](https:\u002F\u002Fradicaldave.com\u002Fblog\u002Fsitecore-xp-technical-debt-audit),\nwhich goes deeper into the audit framework. If you're weighing whether to migrate at\nall, [Enterprise CMS in 2026: How to Choose the Platform and the Partner](\u002Fblog\u002Fenterprise-cms\u002Fenterprise-cms-2026-platform-and-partner)\ncovers the platform-and-partner decision behind every modernization call. Custom\npipeline debt is what shows up when a Sitecore build's delivery goes wrong, and the\n[Figma-to-Sitecore component library rebuild playbook](\u002Fblog\u002Fenterprise-cms\u002Ffigma-developer-handoff-sitecore-component-library)\nwalks through fixing it after the fact. For teams evaluating XM Cloud,\n[Enterprise Headless CMS, Explained](\u002Fblog\u002Fenterprise-cms\u002Fenterprise-headless-cms-explained)\nbreaks down what \"enterprise\" adds on top of \"headless.\"","https:\u002F\u002Fcmdcntr.io\u002Fcovers\u002Fenterprise-cms\u002Fsitecore-xp-debt.webp","A polished chrome block split apart by glowing electric-violet seams into separate segments, each face marked with a small violet gauge dial",[17,18,19,20,21,22],"sitecore","sitecore xp","technical debt","cms migration","xm cloud","enterprise cms",[24,18,25,26],"sitecore audit","sitecore technical debt audit","sitecore xp migration cost",[28,31,34,37,40],{"answer":29,"question":30},"It is a structured review that scores six domains of a Sitecore XP installation: content architecture, personalization and xDB, search and indexing, custom code and pipelines, multi-site complexity, and DevOps maturity. Each domain scores zero to twenty, for a total out of 120. The result tells leadership how ready the platform is to modernize and which domain to fund first.","What is a Sitecore XP technical debt audit?",{"answer":32,"question":33},"There is no single number, because technical debt drives the estimate more than the platform does. Across the audits behind this framework, content modeling debt added thirty to fifty percent on its own, multi-site complexity forty to eighty percent, and xDB dependencies twenty to forty percent. Those are additive and they stack, so a site carrying several at once can reach roughly double a clean-site estimate in the worst cases.","How much does a Sitecore XP to XM Cloud migration cost?",{"answer":35,"question":36},"XM Cloud is Sitecore's SaaS content management platform, built for headless delivery. XP is the self-hosted Experience Platform, which you run and patch yourself across CM, CD, SQL, Solr, xConnect, and Identity servers. The practical difference for a migration is that XM Cloud has no xDB and no Solr, so any dependency on either has to be rebuilt rather than moved.","What is Sitecore XM Cloud, and how is it different from XP?",{"answer":38,"question":39},"Most of the highest-value remediation does not require a migration decision at all. Stand up CI\u002FCD, containerize the application, get staging and production into parity, document your pipelines and processors, and retire personalization rules nobody can explain. That work reduces debt, extends the life of the current installation, and shrinks the migration when you do commit to one.","How do I upgrade Sitecore without migrating to XM Cloud?",{"answer":41,"question":42},"Not immediately. A well-run XP installation can still serve an enterprise well. What forces the decision is the cost curve: infrastructure spend, a shrinking XP talent pool, and security expectations XP was never designed to meet. Auditing your debt now means the move happens on your schedule rather than during an outage or a failed compliance review.","Do I have to leave Sitecore XP?",{"name":44,"steps":45,"totalTime":64},"How to run a Sitecore XP technical debt audit",[46,49,52,55,58,61],{"name":47,"text":48},"Score content architecture debt","Sample content across every site section, not just the homepage tree. Campaign landing pages, legacy microsites, and anything built under deadline pressure carry the most debt. Score zero to twenty on how far the model is from component-centric, headless-ready content.",{"name":50,"text":51},"Score personalization and xDB debt","Inventory every active personalization rule, custom facet, and engagement plan. For each one, identify the marketing owner and whether they can explain it without looking it up. Rules nobody can explain are retirement candidates, not migration candidates.",{"name":53,"text":54},"Score search and indexing debt","Trace several real search queries end to end, from the search box to the index to the result. Count how many layers assume Solr specifically rather than search in the abstract. The more Solr-specific assumptions in the request path, the higher the score.",{"name":56,"text":57},"Score custom code and pipeline debt","Ask for the pipeline configuration files before touching any code, and compare them against out-of-the-box Sitecore. A handful of documented overrides scores as a refactor. A pipeline rewritten with no record of why scores as a rebuild.",{"name":59,"text":60},"Score multi-site and multi-tenant debt","Ask each brand or site owner, separately, which other sites they believe depend on theirs. The gap between believed and actual coupling predicts how far the migration estimate will move. Three different answers to the same question is a high-risk signal.",{"name":62,"text":63},"Score DevOps and infrastructure debt","Ask how a deployment actually happens today. If the answer involves a specific person, a checklist in a shared document, and a maintenance window, that predicts the maturity of every other domain. Total the six scores out of 120 to get the readiness band.","P10D",null,false,"published","Sitecore XP Technical Debt Audit: A Six-Domain Framework","A six-domain audit for Sitecore XP: content architecture, xDB, search, custom code, multi-site, and DevOps. Score your debt and see what migration will really cost.","2026-08-16T21:56:05.134Z","fb696ca1-7851-4fc7-bb8d-0b897916e799","2026-08-10T05:27:15.133Z","a57e6019-7239-484e-b112-598be43b2669","23d49753-baf2-4629-b6fc-df27c558f48d","00000000-0000-4000-e610-000000000003",{"slug":77,"name":78,"avatarUrl":79,"role":80,"bio":81,"isPublic":82,"expertiseSummary":83,"linkedin":84,"github":85,"twitter":65,"website":86},"david-walker","David Walker","\u002Fapi\u002Fpublic\u002Favatar\u002F9258f644-ea21-48be-9653-20951286aab0","Proven Builder, Director, Leader and Manager of Practices, Products, Programs, Software, Solutions, and Teams","30 years experience as a Software Engineer\u002FLead\u002FArchitect with diverse industry experience: Banking, eCommerce, Healthcare, and SaaS\u002Fstartups. As a former Senior Application Development Manager at Microsoft for 3 1\u002F2 years with numerous hands-on Manager and Director level roles, I know I can solve any devops, software, automation, or organization challenge.",true,"Senior Architect\u002FFull Stack Engineer, Sitecore, .NET, Angular, React, NextJs, DevOps, CloudOps","https:\u002F\u002Fwww.linkedin.com\u002Fin\u002Fdavidwalker","https:\u002F\u002Fgithub.com\u002Fradical-dave","https:\u002F\u002Fradicaldave.com",{"slug":88,"name":89,"color":90},"enterprise-cms","Enterprise CMS Delivery","#0EA5E9",{"id":75,"name":92,"ctaType":93,"heading":94,"description":95,"buttonText":96,"url":5,"leadMagnetUrl":65},"Sitecore Modernization Audit","book_call","Still on Sitecore XP and unsure what migration will cost?","We run the six-domain technical debt audit and hand you a scored readiness report you can take to leadership.","Book a call",[98],{"id":99,"slug":100,"name":101,"kind":102,"summary":103,"version":104,"coverImageUrl":65},"f6f66b87-b242-4a57-a705-3cd81a84b328","sitecore-xp-technical-debt-scorecard","Sitecore XP Technical Debt Scorecard","file","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.","1.0",[106,128,142],{"id":107,"slug":108,"title":109,"description":110,"coverImageUrl":111,"coverImageAlt":112,"tags":113,"featured":66,"tool":65,"publishedAt":120,"author":121,"cluster":127},"bf3284f2-bdb2-4d08-b24b-870960743091","headless-cms-seo-complete-guide","Headless CMS SEO: The Complete Guide","The SEO concerns that genuinely change in a headless architecture, and the server-rendered Nuxt patterns we use to get metadata, canonicals, redirects, structured data, sitemaps, and Core Web Vitals right.","https:\u002F\u002Fcmdcntr.io\u002Fcovers\u002Fenterprise-cms\u002Fheadless-seo.webp","Chrome and electric-violet diagram of a headless CMS feeding content through an API into a server-rendered front end, with SEO tags and structured data in the HTML response.",[114,115,116,117,118,119],"headless cms","seo","nuxt","core web vitals","structured data","ssr","2026-07-14T14:00:00.000Z",{"slug":122,"name":123,"avatarUrl":124,"role":125,"bio":126,"isPublic":82},"michael-graham","Michael Graham","\u002Fapi\u002Fpublic\u002Favatar\u002F7452d3cc-b0aa-46e4-96e6-da9c0225c471","Founder & Software Engineer","Obsessed with building top-tier web software and crafting unique, polished user experiences.",{"slug":88,"name":89,"color":90},{"id":129,"slug":130,"title":131,"description":132,"coverImageUrl":133,"coverImageAlt":134,"tags":135,"featured":66,"tool":65,"publishedAt":139,"author":140,"cluster":141},"69f3e275-8bdb-40dc-ac93-b0e87af05d2f","headless-cms-localization","Headless CMS Localization: Patterns That Scale","How localization actually works in a headless CMS: field-level vs entry-level vs space-level translation, locale URL structure and hreflang, fallbacks, RTL, and keeping Nuxt i18n in sync with the CMS, with first-hand Storyblok and Sitecore notes.","https:\u002F\u002Fcmdcntr.io\u002Fcovers\u002Fenterprise-cms\u002Fheadless-localization.webp","A polished chrome globe wrapped in glowing purple circuitry branching into multiple language routes",[114,136,137,138,17,116],"localization","i18n","storyblok","2026-07-12T14:00:00.000Z",{"slug":122,"name":123,"avatarUrl":124,"role":125,"bio":126,"isPublic":82},{"slug":88,"name":89,"color":90},{"id":143,"slug":144,"title":145,"description":146,"coverImageUrl":147,"coverImageAlt":148,"tags":149,"featured":66,"tool":65,"publishedAt":153,"author":154,"cluster":155},"eb994797-29e0-4ad6-8aaf-01f353cd8410","headless-cms-security","Headless CMS Security: The Real Attack Surface","A headless CMS is secure when you treat it as one, but decoupling moves the attack surface to the seams: API tokens, preview endpoints, webhooks, edge caching, rich-text XSS, RBAC, and front-end secrets. Here is the real surface and a hardening checklist.","https:\u002F\u002Fcmdcntr.io\u002Fcovers\u002Fenterprise-cms\u002Fheadless-security.webp","A polished chrome content block splitting apart with glowing electric-violet API connections and a lock symbol at each exposed seam",[114,150,151,152,22],"cms security","api security","web security","2026-07-11T14:00:00.000Z",{"slug":122,"name":123,"avatarUrl":124,"role":125,"bio":126,"isPublic":82},{"slug":88,"name":89,"color":90},{"data":157,"body":158},{},{"type":159,"children":160},"root",[161,170,176,181,186,191,196,202,254,260,267,272,277,282,287,293,298,303,308,314,319,324,329,335,340,363,368,374,379,384,390,395,404,409,415,420,453,458,469,479,493,499,504,532,537,546,555,567,573,578,606,611,620,629,641,647,652,685,690,699,708,720,726,731,764,769,778,787,799,805,810,848,853,862,871,883,889,894,1017,1022,1034,1040,1045,1198,1206,1211,1217,1222,1263,1275,1281,1286,1439,1452,1458,1463,1468,1474],{"type":162,"tag":163,"props":164,"children":166},"element","h2",{"id":165},"xp-isnt-dead-but-your-technical-debt-might-be-killing-you",[167],{"type":168,"value":169},"text","XP Isn't Dead, But Your Technical Debt Might Be Killing You",{"type":162,"tag":171,"props":172,"children":173},"p",{},[174],{"type":168,"value":175},"Most Sitecore audits I encounter are general best-practice checklists. This one is\nXP-specific and built around measurement: what increases modernization cost, what\nblocks migration, and what creates lasting risk. I built it from real enterprise XP\naudits, and I score every domain the same way each time so the results are\ncomparable across engagements.",{"type":162,"tag":171,"props":177,"children":178},{},[179],{"type":168,"value":180},"I spend a lot of time inside legacy Sitecore XP installations. Some still run\nsurprisingly well. Others look stable on the surface but are quietly drowning in\ntechnical debt, built up over years of rushed releases, staff turnover, and\narchitectural shortcuts.",{"type":162,"tag":171,"props":182,"children":183},{},[184],{"type":168,"value":185},"If you are still on XP, the platform is not your biggest problem. The real threat is\nthe debt around it, which determines whether modernization is smooth or a\nbudget-breaking ordeal.",{"type":162,"tag":171,"props":187,"children":188},{},[189],{"type":168,"value":190},"Across the XP audits I have run, organizations that addressed debt early cut their\nprojected migration cost by roughly thirty to sixty percent. A structured audit gives\nleadership a clear picture of readiness and extends the life of existing\ninstallations.",{"type":162,"tag":171,"props":192,"children":193},{},[194],{"type":168,"value":195},"Before the audit itself, it's worth understanding the pressures that make XP harder\nto maintain today than when most of these platforms were built.",{"type":162,"tag":163,"props":197,"children":199},{"id":198},"key-takeaways",[200],{"type":168,"value":201},"Key Takeaways",{"type":162,"tag":203,"props":204,"children":205},"ul",{},[206,212,217,222,227,241],{"type":162,"tag":207,"props":208,"children":209},"li",{},[210],{"type":168,"value":211},"Technical debt, not XP itself, is what makes modernization slow and expensive.",{"type":162,"tag":207,"props":213,"children":214},{},[215],{"type":168,"value":216},"Six domains drive most XP migration risk: content architecture, personalization\nand xDB, search, custom code, multi-site complexity, and DevOps maturity.",{"type":162,"tag":207,"props":218,"children":219},{},[220],{"type":168,"value":221},"Multi-site complexity is the costliest single domain, adding forty to eighty\npercent, and it stacks with the others rather than replacing them.",{"type":162,"tag":207,"props":223,"children":224},{},[225],{"type":168,"value":226},"A zero to twenty scorecard per domain, totaling out of 120, gives leadership a\nshared and quantifiable view of readiness.",{"type":162,"tag":207,"props":228,"children":229},{},[230,232,239],{"type":168,"value":231},"Enterprises can cut debt now, short of migrating to an\n",{"type":162,"tag":233,"props":234,"children":236},"a",{"href":235},"\u002Fblog\u002Fenterprise-cms\u002Fenterprise-headless-cms-explained",[237],{"type":168,"value":238},"enterprise headless CMS",{"type":168,"value":240},",\nusing the roadmap below.",{"type":162,"tag":207,"props":242,"children":243},{},[244,246,252],{"type":168,"value":245},"Teams without in-house XP expertise close these gaps faster by bringing in\n",{"type":162,"tag":233,"props":247,"children":249},{"href":248},"\u002Fservices\u002Fsitecore",[250],{"type":168,"value":251},"Sitecore upgrade services",{"type":168,"value":253}," that have run the migration before.",{"type":162,"tag":163,"props":255,"children":257},{"id":256},"what-changed-around-xp",[258],{"type":168,"value":259},"What Changed Around XP",{"type":162,"tag":261,"props":262,"children":264},"h3",{"id":263},"infrastructure-cost-on-self-managed-hosting",[265],{"type":168,"value":266},"Infrastructure cost on self-managed hosting",{"type":162,"tag":171,"props":268,"children":269},{},[270],{"type":168,"value":271},"In every XP audit I run, infrastructure cost is one of the first red flags. XP\nrequires a heavy footprint: CM, CD, SQL, Solr, xConnect, and Identity servers, all of\nwhich must be patched, monitored, scaled, and secured.",{"type":162,"tag":171,"props":273,"children":274},{},[275],{"type":168,"value":276},"Cloud providers have shifted pricing toward consumption billing, and long-running\nWindows VMs, SQL licensing, storage, and bandwidth have all become significantly more\nexpensive. I have seen XP customers spend more on infrastructure in a single year\nthan XM Cloud would cost over three.",{"type":162,"tag":171,"props":278,"children":279},{},[280],{"type":168,"value":281},"One client had a Solr cluster that required manual failover. Another had SQL servers\ntwo versions behind, because upgrading them would break custom pipelines. These are\nnot theoretical; I see them in audits every month.",{"type":162,"tag":171,"props":283,"children":284},{},[285],{"type":168,"value":286},"XP's cost curve goes up. XM Cloud's goes down. Staying on XP is a financial\nliability, not just a technical decision.",{"type":162,"tag":261,"props":288,"children":290},{"id":289},"the-talent-pool-moved-to-headless-and-saas",[291],{"type":168,"value":292},"The talent pool moved to headless and SaaS",{"type":162,"tag":171,"props":294,"children":295},{},[296],{"type":168,"value":297},"The XP talent pool is shrinking, not because developers cannot work on XP, but\nbecause the ecosystem has moved on. Sitecore's roadmap prioritizes XM Cloud, headless\nSXA, Next.js, TypeScript, GraphQL, and SaaS-native services.",{"type":162,"tag":171,"props":299,"children":300},{},[301],{"type":168,"value":302},"In my audits, I often meet teams who inherited XP from developers who left years ago.\nThe people maintaining the platform today are working with legacy MVC controllers and\n.NET Framework, paired with Solr and xDB patterns that modern Sitecore work no longer\nrequires.",{"type":162,"tag":171,"props":304,"children":305},{},[306],{"type":168,"value":307},"This is an economic and ecosystem shift, not a capability gap. If your team lacks\ndeep XP experience, bringing in a partner who has already run an XP to XM Cloud\nmigration usually closes the gap faster than training up on a shrinking skill set.",{"type":162,"tag":261,"props":309,"children":311},{"id":310},"zero-trust-expectations-xp-was-never-built-to-meet",[312],{"type":168,"value":313},"Zero Trust expectations XP was never built to meet",{"type":162,"tag":171,"props":315,"children":316},{},[317],{"type":168,"value":318},"Security expectations have changed dramatically. Enterprises now operate under Zero\nTrust models with continuous compliance, automated patching, container isolation,\nsecret rotation, cloud-native identity, and real-time threat detection as baseline\nexpectations, not extras. XP was not built for any of this.",{"type":162,"tag":171,"props":320,"children":321},{},[322],{"type":168,"value":323},"In one audit, I found an Identity Server instance that had not been patched in four\nyears, because updating it would break a custom login flow. In another, xConnect ran\non an outdated Windows Server version no longer receiving security updates.",{"type":162,"tag":171,"props":325,"children":326},{},[327],{"type":168,"value":328},"Organizations end up bolting on compensating controls and manual patch cycles just to\nmeet baseline expectations, and every year the gap widens. XM Cloud offloads nearly\nall of this to Sitecore's managed SaaS environment.",{"type":162,"tag":261,"props":330,"children":332},{"id":331},"the-pressures-every-xp-team-already-knows-about",[333],{"type":168,"value":334},"The pressures every XP team already knows about",{"type":162,"tag":171,"props":336,"children":337},{},[338],{"type":168,"value":339},"These issues are familiar to every XP team I work with:",{"type":162,"tag":203,"props":341,"children":342},{},[343,348,353,358],{"type":162,"tag":207,"props":344,"children":345},{},[346],{"type":168,"value":347},"Solr overhead: custom schemas, computed fields, fragile indexing dependencies",{"type":162,"tag":207,"props":349,"children":350},{},[351],{"type":168,"value":352},"Legacy personalization tied to xDB: years of accumulated rules and custom facets",{"type":162,"tag":207,"props":354,"children":355},{},[356],{"type":168,"value":357},"Custom pipelines that introduce unpredictable behavior and resist refactoring",{"type":162,"tag":207,"props":359,"children":360},{},[361],{"type":168,"value":362},"Multi-site architectures with shared templates that are hard to separate",{"type":162,"tag":171,"props":364,"children":365},{},[366],{"type":168,"value":367},"XP can still run well. It's the debt built up over years of rushed deployments that\nmakes modernization difficult.",{"type":162,"tag":163,"props":369,"children":371},{"id":370},"what-this-audit-deliberately-ignores",[372],{"type":168,"value":373},"What This Audit Deliberately Ignores",{"type":162,"tag":171,"props":375,"children":376},{},[377],{"type":168,"value":378},"Some items commonly mentioned in agency XP audits do not need to be covered here:\nGlassMapper, TDS, Unicorn, and custom MVC frameworks. These are\nimplementation-specific choices, not part of the XP platform itself, and none of them\nsurvive migration to XM Cloud, which replaces all server-side code and MVC patterns\nwith a new headless front end.",{"type":162,"tag":171,"props":380,"children":381},{},[382],{"type":168,"value":383},"Because they do not influence cost, complexity, or architectural risk, they are not\nrelevant here.",{"type":162,"tag":163,"props":385,"children":387},{"id":386},"the-six-domains",[388],{"type":168,"value":389},"The Six Domains",{"type":162,"tag":171,"props":391,"children":392},{},[393],{"type":168,"value":394},"This audit framework breaks XP technical debt into six domains. Each domain contains\nspecific indicators that reveal modernization risk and migration cost. This is the\nsame structure I use in real enterprise audits.",{"type":162,"tag":171,"props":396,"children":397},{},[398],{"type":162,"tag":399,"props":400,"children":403},"img",{"alt":401,"src":402},"The six domains of Sitecore XP technical debt arranged around the platform core: content architecture, personalization and xDB, search and indexing, custom code and pipelines, multi-site complexity, and DevOps maturity, each carrying its own risk score","\u002Fcovers\u002Fenterprise-cms\u002Fvisuals\u002Fxp-debt-six-domains.webp",[],{"type":162,"tag":171,"props":405,"children":406},{},[407],{"type":168,"value":408},"Two of the six block a migration outright, because XM Cloud has no xDB and no Solr.\nThe other four decide what it costs. Each one closes with the signal that pushes it\ninto high-risk territory, so you can score your own installation as you read.",{"type":162,"tag":261,"props":410,"children":412},{"id":411},"domain-1-content-architecture",[413],{"type":168,"value":414},"Domain 1: Content Architecture",{"type":162,"tag":171,"props":416,"children":417},{},[418],{"type":168,"value":419},"Content modeling is the number one driver of migration cost, and it is the domain\nwhere I see the widest gap between what a site looks like on the surface and what it\nactually costs to move. In my audits, I often find:",{"type":162,"tag":203,"props":421,"children":422},{},[423,428,433,438,443,448],{"type":162,"tag":207,"props":424,"children":425},{},[426],{"type":168,"value":427},"Deeply nested content trees that no longer map to how the business is organized",{"type":162,"tag":207,"props":429,"children":430},{},[431],{"type":168,"value":432},"Page-centric templates instead of component-centric models",{"type":162,"tag":207,"props":434,"children":435},{},[436],{"type":168,"value":437},"Presentation details hard-coded into templates",{"type":162,"tag":207,"props":439,"children":440},{},[441],{"type":168,"value":442},"Lack of reusable components",{"type":162,"tag":207,"props":444,"children":445},{},[446],{"type":168,"value":447},"No separation between content and layout",{"type":162,"tag":207,"props":449,"children":450},{},[451],{"type":168,"value":452},"Content structures not ready for headless delivery",{"type":162,"tag":171,"props":454,"children":455},{},[456],{"type":168,"value":457},"This debt accumulates quietly. A site launches with a clean structure, then years of\ncampaigns and one-off landing pages get bolted on wherever there was room in the\ntree. Nobody sets out to build a content model this way; it happens one urgent\nrequest at a time.",{"type":162,"tag":171,"props":459,"children":460},{},[461,467],{"type":162,"tag":462,"props":463,"children":464},"strong",{},[465],{"type":168,"value":466},"Why it matters:",{"type":168,"value":468}," Poor content architecture multiplies migration cost because every\ncontent item must be restructured, remapped, or rebuilt rather than lifted and\nshifted. A headless front end expects components with well-defined fields, not\ntemplates that mix layout markup into the content model. When I score this domain\nhigh risk, the fix is rarely a quick cleanup: it is a content model redesign, a\nmigration script, and author retraining, three workstreams hiding inside what looks\nlike one line item on a project plan.",{"type":162,"tag":171,"props":470,"children":471},{},[472,477],{"type":162,"tag":462,"props":473,"children":474},{},[475],{"type":168,"value":476},"What I look for in an audit:",{"type":168,"value":478}," I sample content across every site section, not just\nthe homepage tree, because debt concentrates where leadership stops paying attention\nafter launch. Campaign landing pages, legacy microsites, and anything built under\ndeadline pressure are the first places I check. Those areas usually account for a\ndisproportionate share of the migration estimate.",{"type":162,"tag":480,"props":481,"children":482},"blockquote",{},[483],{"type":162,"tag":171,"props":484,"children":485},{},[486,491],{"type":162,"tag":462,"props":487,"children":488},{},[489],{"type":168,"value":490},"Scores 15 or higher when:",{"type":168,"value":492}," templates carry presentation markup, the same\ncomponent is rebuilt per section, and no one can point to a reusable field model.",{"type":162,"tag":261,"props":494,"children":496},{"id":495},"domain-2-personalization-and-xdb",[497],{"type":168,"value":498},"Domain 2: Personalization and xDB",{"type":162,"tag":171,"props":500,"children":501},{},[502],{"type":168,"value":503},"Many XP implementations have personalization rules that were created years ago and\nnever revisited. I often find:",{"type":162,"tag":203,"props":505,"children":506},{},[507,512,517,522,527],{"type":162,"tag":207,"props":508,"children":509},{},[510],{"type":168,"value":511},"Hundreds of unused or outdated personalization rules",{"type":162,"tag":207,"props":513,"children":514},{},[515],{"type":168,"value":516},"Custom xDB facets that nobody currently maintaining the site can fully explain",{"type":162,"tag":207,"props":518,"children":519},{},[520],{"type":168,"value":521},"Legacy engagement plans",{"type":162,"tag":207,"props":523,"children":524},{},[525],{"type":168,"value":526},"Marketing automation that no longer runs",{"type":162,"tag":207,"props":528,"children":529},{},[530],{"type":168,"value":531},"Goals, campaigns, and outcomes that are unused or misconfigured",{"type":162,"tag":171,"props":533,"children":534},{},[535],{"type":168,"value":536},"I have audited installations where fewer than ten percent of the active\npersonalization rules were still doing anything measurable. The rest were dead\nweight, left in place because nobody wanted to be the one who deleted a rule that\nmight matter. That instinct is understandable, and it is exactly how xDB debt\ncompounds over a decade.",{"type":162,"tag":171,"props":538,"children":539},{},[540,544],{"type":162,"tag":462,"props":541,"children":542},{},[543],{"type":168,"value":466},{"type":168,"value":545}," xDB is not part of XM Cloud. Any dependency on xDB becomes a\nmigration blocker, not a migration inconvenience. Before you can move, someone has to\ninventory every rule, facet, and engagement plan, decide what still reflects current\nbusiness goals, and rebuild the ones worth keeping on a modern personalization layer.\nSkipping that inventory does not make the debt disappear. It just moves the discovery\nto the middle of the migration, where it is far more expensive to deal with.",{"type":162,"tag":171,"props":547,"children":548},{},[549,553],{"type":162,"tag":462,"props":550,"children":551},{},[552],{"type":168,"value":476},{"type":168,"value":554}," ownership is the real signal here. For every active\nrule, I ask who owns it on the marketing side and whether that person could explain\nwhat it does without looking it up. Rules nobody can explain are candidates for\nretirement, not migration, and retiring them before the audit closes shrinks the\npersonalization rebuild considerably.",{"type":162,"tag":480,"props":556,"children":557},{},[558],{"type":162,"tag":171,"props":559,"children":560},{},[561,565],{"type":162,"tag":462,"props":562,"children":563},{},[564],{"type":168,"value":490},{"type":168,"value":566}," custom xDB facets are in play, engagement plans still\nrun, and no marketer can name the owner of an active rule.",{"type":162,"tag":261,"props":568,"children":570},{"id":569},"domain-3-search-and-indexing",[571],{"type":168,"value":572},"Domain 3: Search and Indexing",{"type":162,"tag":171,"props":574,"children":575},{},[576],{"type":168,"value":577},"Search is one of the most fragile parts of XP. I regularly encounter:",{"type":162,"tag":203,"props":579,"children":580},{},[581,586,591,596,601],{"type":162,"tag":207,"props":582,"children":583},{},[584],{"type":168,"value":585},"Custom Solr schema modifications",{"type":162,"tag":207,"props":587,"children":588},{},[589],{"type":168,"value":590},"Multiple index rebuild dependencies that no one wants to touch",{"type":162,"tag":207,"props":592,"children":593},{},[594],{"type":168,"value":595},"Custom computed fields",{"type":162,"tag":207,"props":597,"children":598},{},[599],{"type":168,"value":600},"Search logic embedded directly in controllers",{"type":162,"tag":207,"props":602,"children":603},{},[604],{"type":168,"value":605},"No abstraction layer between the application and the search engine",{"type":162,"tag":171,"props":607,"children":608},{},[609],{"type":168,"value":610},"Search debt tends to be invisible until something breaks: a schema change in one part\nof the site cascades into a rebuild that takes down search elsewhere, because the two\nwere never meant to be independent.",{"type":162,"tag":171,"props":612,"children":613},{},[614,618],{"type":162,"tag":462,"props":615,"children":616},{},[617],{"type":168,"value":466},{"type":168,"value":619}," Solr is not part of XM Cloud. Custom search logic must be\nrewritten or replaced, and the amount of rework scales directly with how tightly\nsearch was coupled to the rest of the application. A site with a clean abstraction\nlayer over search can usually swap in a cloud search provider with moderate effort. A\nsite with search logic scattered across controllers and computed fields requires a\nmuch closer audit, because nobody can say with confidence what will break when the\nunderlying engine changes.",{"type":162,"tag":171,"props":621,"children":622},{},[623,627],{"type":162,"tag":462,"props":624,"children":625},{},[626],{"type":168,"value":476},{"type":168,"value":628}," I trace a handful of real search queries end to end,\nfrom the search box to the index to the result. That trace usually reveals how many\nlayers a query passes through and how many of those layers assume Solr specifically,\nrather than search in the abstract. The more Solr-specific assumptions I find baked\ninto the request path, the higher this domain scores, and the more time I budget for\nthe search rewrite in any migration plan.",{"type":162,"tag":480,"props":630,"children":631},{},[632],{"type":162,"tag":171,"props":633,"children":634},{},[635,639],{"type":162,"tag":462,"props":636,"children":637},{},[638],{"type":168,"value":490},{"type":168,"value":640}," controllers query Solr directly, computed fields carry\nbusiness logic, and a schema change forces a full rebuild.",{"type":162,"tag":261,"props":642,"children":644},{"id":643},"domain-4-custom-code-and-pipelines",[645],{"type":168,"value":646},"Domain 4: Custom Code and Pipelines",{"type":162,"tag":171,"props":648,"children":649},{},[650],{"type":168,"value":651},"Custom code is often the largest source of XP technical debt. I frequently see:",{"type":162,"tag":203,"props":653,"children":654},{},[655,660,665,670,675,680],{"type":162,"tag":207,"props":656,"children":657},{},[658],{"type":168,"value":659},"Custom pipelines overriding core Sitecore behavior",{"type":162,"tag":207,"props":661,"children":662},{},[663],{"type":168,"value":664},"Processors with no documentation and no clear owner",{"type":162,"tag":207,"props":666,"children":667},{},[668],{"type":168,"value":669},"Legacy MVC controllers doing work that belongs in services",{"type":162,"tag":207,"props":671,"children":672},{},[673],{"type":168,"value":674},"Hard-coded dependencies on specific server paths or configuration values",{"type":162,"tag":207,"props":676,"children":677},{},[678],{"type":168,"value":679},"No dependency injection",{"type":162,"tag":207,"props":681,"children":682},{},[683],{"type":168,"value":684},"No abstraction for external services",{"type":162,"tag":171,"props":686,"children":687},{},[688],{"type":168,"value":689},"This is the domain where I spend the most audit time, because it is the hardest to\nassess from the outside. A pipeline override might be a two-line tweak or it might be\nload-bearing for half the site's functionality, and you often cannot tell which until\nyou try to remove it.",{"type":162,"tag":171,"props":691,"children":692},{},[693,697],{"type":162,"tag":462,"props":694,"children":695},{},[696],{"type":168,"value":466},{"type":168,"value":698}," Custom code determines whether migration is a refactor or a full\nrebuild. Well-documented, cleanly separated custom code can often be ported with real\neffort but a clear path. Undocumented pipeline overrides and processors with no owner\nhave to be reverse-engineered before anyone can safely decide whether to keep,\nrewrite, or drop them. That reverse-engineering work is what quietly turns a\nfixed-bid migration proposal into a change order three months in.",{"type":162,"tag":171,"props":700,"children":701},{},[702,706],{"type":162,"tag":462,"props":703,"children":704},{},[705],{"type":168,"value":476},{"type":168,"value":707}," I ask for the pipeline configuration files first,\nbefore touching any code, and compare them against out-of-the-box Sitecore to see how\nmuch has been overridden. A handful of documented overrides is a very different\nmigration than a pipeline rewritten with no record of why, and that difference is\noften the single biggest swing factor in a migration estimate, since it decides\nwhether the custom code domain scores as a refactor or a rebuild.",{"type":162,"tag":480,"props":709,"children":710},{},[711],{"type":162,"tag":171,"props":712,"children":713},{},[714,718],{"type":162,"tag":462,"props":715,"children":716},{},[717],{"type":168,"value":490},{"type":168,"value":719}," pipeline overrides are undocumented, no dependency\ninjection exists, and removing a processor is something nobody will risk.",{"type":162,"tag":261,"props":721,"children":723},{"id":722},"domain-5-multi-site-and-multi-tenancy",[724],{"type":168,"value":725},"Domain 5: Multi-Site and Multi-Tenancy",{"type":162,"tag":171,"props":727,"children":728},{},[729],{"type":168,"value":730},"Many XP installations have grown organically into multi-site platforms. Common issues\ninclude:",{"type":162,"tag":203,"props":732,"children":733},{},[734,739,744,749,754,759],{"type":162,"tag":207,"props":735,"children":736},{},[737],{"type":168,"value":738},"Shared content trees across brands",{"type":162,"tag":207,"props":740,"children":741},{},[742],{"type":168,"value":743},"Shared templates across unrelated sites",{"type":162,"tag":207,"props":745,"children":746},{},[747],{"type":168,"value":748},"No tenant isolation",{"type":162,"tag":207,"props":750,"children":751},{},[752],{"type":168,"value":753},"Cross-site dependencies in rendering code",{"type":162,"tag":207,"props":755,"children":756},{},[757],{"type":168,"value":758},"Shared media libraries with no ownership boundaries",{"type":162,"tag":207,"props":760,"children":761},{},[762],{"type":168,"value":763},"Shared deployment pipelines that force every site to release together",{"type":162,"tag":171,"props":765,"children":766},{},[767],{"type":168,"value":768},"Multi-site debt is different from the other five domains, because it is architectural\nrather than purely technical. You cannot fix it with a refactor. You have to decide,\nas an organization, which sites actually need to be independent and which ones were\nonly sharing infrastructure because it was convenient at the time, often years before\nanyone currently on the team was involved in the decision.",{"type":162,"tag":171,"props":770,"children":771},{},[772,776],{"type":162,"tag":462,"props":773,"children":774},{},[775],{"type":168,"value":466},{"type":168,"value":777}," Multi-site complexity adds forty to eighty percent to migration\ncost and timeline on its own, more than any other single domain, and it stacks on top\nof content and pipeline debt rather than replacing them. Separating tightly\ncoupled sites means untangling shared templates, splitting media libraries, and\nrebuilding deployment pipelines so that one brand's release no longer depends on\nanother's. This is consistently the domain where initial migration estimates go\nfurthest off track, because the coupling is invisible until someone tries to move one\nsite without the other four.",{"type":162,"tag":171,"props":779,"children":780},{},[781,785],{"type":162,"tag":462,"props":782,"children":783},{},[784],{"type":168,"value":476},{"type":168,"value":786}," I ask each brand or site owner, separately, which\nother sites they believe depend on theirs. The gap between what they think is shared\nand what is actually shared in code is usually significant, and that gap is a good\npredictor of how much the migration estimate will move once engineering starts\nuntangling it. When three site owners give three different answers to the same\nquestion, that alone is a high-risk signal.",{"type":162,"tag":480,"props":788,"children":789},{},[790],{"type":162,"tag":171,"props":791,"children":792},{},[793,797],{"type":162,"tag":462,"props":794,"children":795},{},[796],{"type":168,"value":490},{"type":168,"value":798}," brands share templates and media libraries, and one\nsite cannot ship a release without the others going with it.",{"type":162,"tag":261,"props":800,"children":802},{"id":801},"domain-6-devops-and-infrastructure",[803],{"type":168,"value":804},"Domain 6: DevOps and Infrastructure",{"type":162,"tag":171,"props":806,"children":807},{},[808],{"type":168,"value":809},"XP's infrastructure footprint is often outdated. I regularly find:",{"type":162,"tag":203,"props":811,"children":812},{},[813,818,823,828,833,838,843],{"type":162,"tag":207,"props":814,"children":815},{},[816],{"type":168,"value":817},"Manual deployments run by a specific person who knows the steps",{"type":162,"tag":207,"props":819,"children":820},{},[821],{"type":168,"value":822},"No CI\u002FCD pipeline",{"type":162,"tag":207,"props":824,"children":825},{},[826],{"type":168,"value":827},"On-prem hosting with no path to cloud",{"type":162,"tag":207,"props":829,"children":830},{},[831],{"type":168,"value":832},"Outdated Windows Server or SQL Server versions",{"type":162,"tag":207,"props":834,"children":835},{},[836],{"type":168,"value":837},"No containerization",{"type":162,"tag":207,"props":839,"children":840},{},[841],{"type":168,"value":842},"No automated testing",{"type":162,"tag":207,"props":844,"children":845},{},[846],{"type":168,"value":847},"No environment parity between staging and production",{"type":162,"tag":171,"props":849,"children":850},{},[851],{"type":168,"value":852},"DevOps debt does not directly block migration the way xDB or Solr dependencies do. It\ndoes something arguably worse: it slows down every other fix on this list. Teams\nwithout CI\u002FCD or environment parity cannot safely test the content model changes,\nsearch abstraction, or code refactors that the other five domains require, so\nremediation stalls across the board rather than in one place.",{"type":162,"tag":171,"props":854,"children":855},{},[856,860],{"type":162,"tag":462,"props":857,"children":858},{},[859],{"type":168,"value":466},{"type":168,"value":861}," Infrastructure debt is the silent killer of XP longevity. It is\nalso the domain most enterprises can start fixing immediately, independent of any\nmigration decision. Standing up CI\u002FCD, containerizing the application, and getting\nstaging and production into parity does not require touching xDB, Solr, or custom\npipelines at all. It just requires deciding to do it, which is why I recommend most\norganizations start their remediation here.",{"type":162,"tag":171,"props":863,"children":864},{},[865,869],{"type":162,"tag":462,"props":866,"children":867},{},[868],{"type":168,"value":476},{"type":168,"value":870}," the fastest signal is asking how a deployment\nactually happens today. If the honest answer involves a specific person, a checklist\nin a shared document, and a maintenance window, that tells me more about overall\nmodernization readiness than almost anything else in the audit, because it usually\npredicts the maturity of every other domain too.",{"type":162,"tag":480,"props":872,"children":873},{},[874],{"type":162,"tag":171,"props":875,"children":876},{},[877,881],{"type":162,"tag":462,"props":878,"children":879},{},[880],{"type":168,"value":490},{"type":168,"value":882}," deployment depends on one person, staging and\nproduction have drifted, and there is no automated test to catch the difference.",{"type":162,"tag":163,"props":884,"children":886},{"id":885},"scoring-it-120-points-across-six-domains",[887],{"type":168,"value":888},"Scoring It: 120 Points Across Six Domains",{"type":162,"tag":171,"props":890,"children":891},{},[892],{"type":168,"value":893},"Score each of the six domains from zero to twenty, where zero is clean and twenty is\nsevere. Add the six scores for a total out of 120.",{"type":162,"tag":895,"props":896,"children":897},"table",{},[898,922],{"type":162,"tag":899,"props":900,"children":901},"thead",{},[902],{"type":162,"tag":903,"props":904,"children":905},"tr",{},[906,912,917],{"type":162,"tag":907,"props":908,"children":909},"th",{},[910],{"type":168,"value":911},"Total",{"type":162,"tag":907,"props":913,"children":914},{},[915],{"type":168,"value":916},"Band",{"type":162,"tag":907,"props":918,"children":919},{},[920],{"type":168,"value":921},"What it means for the business",{"type":162,"tag":923,"props":924,"children":925},"tbody",{},[926,945,963,981,999],{"type":162,"tag":903,"props":927,"children":928},{},[929,935,940],{"type":162,"tag":930,"props":931,"children":932},"td",{},[933],{"type":168,"value":934},"0 to 24",{"type":162,"tag":930,"props":936,"children":937},{},[938],{"type":168,"value":939},"Low",{"type":162,"tag":930,"props":941,"children":942},{},[943],{"type":168,"value":944},"Modernize on your own schedule",{"type":162,"tag":903,"props":946,"children":947},{},[948,953,958],{"type":162,"tag":930,"props":949,"children":950},{},[951],{"type":168,"value":952},"25 to 48",{"type":162,"tag":930,"props":954,"children":955},{},[956],{"type":168,"value":957},"Moderate",{"type":162,"tag":930,"props":959,"children":960},{},[961],{"type":168,"value":962},"Remediate the top two domains before scoping a migration",{"type":162,"tag":903,"props":964,"children":965},{},[966,971,976],{"type":162,"tag":930,"props":967,"children":968},{},[969],{"type":168,"value":970},"49 to 72",{"type":162,"tag":930,"props":972,"children":973},{},[974],{"type":168,"value":975},"High",{"type":162,"tag":930,"props":977,"children":978},{},[979],{"type":168,"value":980},"Budget for remediation as its own project, not a migration line item",{"type":162,"tag":903,"props":982,"children":983},{},[984,989,994],{"type":162,"tag":930,"props":985,"children":986},{},[987],{"type":168,"value":988},"73 to 96",{"type":162,"tag":930,"props":990,"children":991},{},[992],{"type":168,"value":993},"Critical",{"type":162,"tag":930,"props":995,"children":996},{},[997],{"type":168,"value":998},"Any fixed-bid migration quote at this level will move",{"type":162,"tag":903,"props":1000,"children":1001},{},[1002,1007,1012],{"type":162,"tag":930,"props":1003,"children":1004},{},[1005],{"type":168,"value":1006},"97 to 120",{"type":162,"tag":930,"props":1008,"children":1009},{},[1010],{"type":168,"value":1011},"Migration-blocking",{"type":162,"tag":930,"props":1013,"children":1014},{},[1015],{"type":168,"value":1016},"Remediate first. Migrating now converts debt into overrun",{"type":162,"tag":171,"props":1018,"children":1019},{},[1020],{"type":168,"value":1021},"This scorecard gives leadership a clear, quantifiable view of XP posture, and because\nevery domain uses the same scale, it also shows which domain to fund first.",{"type":162,"tag":171,"props":1023,"children":1024},{},[1025,1027,1032],{"type":168,"value":1026},"You do not have to build the sheet yourself. The\n",{"type":162,"tag":233,"props":1028,"children":1030},{"href":1029},"\u002Ftools\u002Fsitecore-xp-technical-debt-scorecard",[1031],{"type":168,"value":101},{"type":168,"value":1033}," is\nthe working version of this framework: every indicator below as a scored row, the\ntotal and band calculated for you, and a worked example of a real installation so you\ncan see what a finished audit looks like before you start your own.",{"type":162,"tag":163,"props":1035,"children":1037},{"id":1036},"what-each-domain-adds-to-the-migration-bill",[1038],{"type":168,"value":1039},"What Each Domain Adds to the Migration Bill",{"type":162,"tag":171,"props":1041,"children":1042},{},[1043],{"type":168,"value":1044},"These are the ranges I have observed across enterprise modernization projects, not\npublished industry benchmarks. Each figure is what that domain adds on its own, so\nread them as additive multipliers rather than a menu to pick from:",{"type":162,"tag":895,"props":1046,"children":1047},{},[1048,1069],{"type":162,"tag":899,"props":1049,"children":1050},{},[1051],{"type":162,"tag":903,"props":1052,"children":1053},{},[1054,1059,1064],{"type":162,"tag":907,"props":1055,"children":1056},{},[1057],{"type":168,"value":1058},"Debt source",{"type":162,"tag":907,"props":1060,"children":1061},{},[1062],{"type":168,"value":1063},"Adds on its own",{"type":162,"tag":907,"props":1065,"children":1066},{},[1067],{"type":168,"value":1068},"Why it lands there",{"type":162,"tag":923,"props":1070,"children":1071},{},[1072,1093,1114,1135,1156,1177],{"type":162,"tag":903,"props":1073,"children":1074},{},[1075,1080,1088],{"type":162,"tag":930,"props":1076,"children":1077},{},[1078],{"type":168,"value":1079},"Content modeling",{"type":162,"tag":930,"props":1081,"children":1082},{},[1083],{"type":162,"tag":462,"props":1084,"children":1085},{},[1086],{"type":168,"value":1087},"+30 to 50%",{"type":162,"tag":930,"props":1089,"children":1090},{},[1091],{"type":168,"value":1092},"Every item is restructured, not moved",{"type":162,"tag":903,"props":1094,"children":1095},{},[1096,1101,1109],{"type":162,"tag":930,"props":1097,"children":1098},{},[1099],{"type":168,"value":1100},"Multi-site complexity",{"type":162,"tag":930,"props":1102,"children":1103},{},[1104],{"type":162,"tag":462,"props":1105,"children":1106},{},[1107],{"type":168,"value":1108},"+40 to 80%",{"type":162,"tag":930,"props":1110,"children":1111},{},[1112],{"type":168,"value":1113},"Untangling shared templates, media, pipelines",{"type":162,"tag":903,"props":1115,"children":1116},{},[1117,1122,1130],{"type":162,"tag":930,"props":1118,"children":1119},{},[1120],{"type":168,"value":1121},"xDB dependencies",{"type":162,"tag":930,"props":1123,"children":1124},{},[1125],{"type":162,"tag":462,"props":1126,"children":1127},{},[1128],{"type":168,"value":1129},"+20 to 40%",{"type":162,"tag":930,"props":1131,"children":1132},{},[1133],{"type":168,"value":1134},"Rules and facets rebuilt on a new layer",{"type":162,"tag":903,"props":1136,"children":1137},{},[1138,1143,1151],{"type":162,"tag":930,"props":1139,"children":1140},{},[1141],{"type":168,"value":1142},"DevOps debt",{"type":162,"tag":930,"props":1144,"children":1145},{},[1146],{"type":162,"tag":462,"props":1147,"children":1148},{},[1149],{"type":168,"value":1150},"+20 to 30%",{"type":162,"tag":930,"props":1152,"children":1153},{},[1154],{"type":168,"value":1155},"Slows every other remediation stream",{"type":162,"tag":903,"props":1157,"children":1158},{},[1159,1164,1172],{"type":162,"tag":930,"props":1160,"children":1161},{},[1162],{"type":168,"value":1163},"Custom pipelines",{"type":162,"tag":930,"props":1165,"children":1166},{},[1167],{"type":162,"tag":462,"props":1168,"children":1169},{},[1170],{"type":168,"value":1171},"+15 to 25%",{"type":162,"tag":930,"props":1173,"children":1174},{},[1175],{"type":168,"value":1176},"Reverse-engineering before any decision",{"type":162,"tag":903,"props":1178,"children":1179},{},[1180,1185,1193],{"type":162,"tag":930,"props":1181,"children":1182},{},[1183],{"type":168,"value":1184},"Solr customizations",{"type":162,"tag":930,"props":1186,"children":1187},{},[1188],{"type":162,"tag":462,"props":1189,"children":1190},{},[1191],{"type":168,"value":1192},"+10 to 20%",{"type":162,"tag":930,"props":1194,"children":1195},{},[1196],{"type":168,"value":1197},"Search rewritten against a new engine",{"type":162,"tag":171,"props":1199,"children":1200},{},[1201],{"type":162,"tag":399,"props":1202,"children":1205},{"alt":1203,"src":1204},"How Sitecore XP debt compounds: individual domain multipliers stacking on a baseline migration estimate until a site carrying several at once reaches roughly double the clean-site cost","\u002Fcovers\u002Fenterprise-cms\u002Fvisuals\u002Fxp-debt-compounding.webp",[],{"type":162,"tag":171,"props":1207,"children":1208},{},[1209],{"type":168,"value":1210},"They also compound. A site carrying heavy multi-site, content modeling, and pipeline\ndebt at the same time can land at roughly double a clean-site estimate, occasionally\nworse. That is the worst case rather than the median, and it is why two XP sites of\nsimilar size can quote very differently.",{"type":162,"tag":163,"props":1212,"children":1214},{"id":1213},"cutting-debt-without-committing-to-a-migration",[1215],{"type":168,"value":1216},"Cutting Debt Without Committing to a Migration",{"type":162,"tag":171,"props":1218,"children":1219},{},[1220],{"type":168,"value":1221},"Enterprises can reduce technical debt today without committing to migration. In my\naudits, I often recommend:",{"type":162,"tag":203,"props":1223,"children":1224},{},[1225,1238,1243,1248,1253,1258],{"type":162,"tag":207,"props":1226,"children":1227},{},[1228,1230,1236],{"type":168,"value":1229},"Introducing headless front ends such as Next.js and Vercel (see this\n",{"type":162,"tag":233,"props":1231,"children":1233},{"href":1232},"\u002Fblog\u002Fenterprise-cms\u002Fheadless-cms-vs-traditional-cms",[1234],{"type":168,"value":1235},"headless vs. traditional CMS breakdown",{"type":168,"value":1237},"\nif you haven't settled on the architecture)",{"type":162,"tag":207,"props":1239,"children":1240},{},[1241],{"type":168,"value":1242},"Externalizing personalization and replacing Solr with cloud search",{"type":162,"tag":207,"props":1244,"children":1245},{},[1246],{"type":168,"value":1247},"Introducing dependency injection and abstraction layers",{"type":162,"tag":207,"props":1249,"children":1250},{},[1251],{"type":168,"value":1252},"Cleaning up content models and removing unused xDB features",{"type":162,"tag":207,"props":1254,"children":1255},{},[1256],{"type":168,"value":1257},"Introducing CI\u002FCD and containerizing XP",{"type":162,"tag":207,"props":1259,"children":1260},{},[1261],{"type":168,"value":1262},"Documenting pipelines and processors",{"type":162,"tag":171,"props":1264,"children":1265},{},[1266,1268,1273],{"type":168,"value":1267},"This roadmap extends XP's life while preparing for future modernization. If the\nremediation list runs longer than your team can absorb alongside its normal roadmap,\nour ",{"type":162,"tag":233,"props":1269,"children":1270},{"href":248},[1271],{"type":168,"value":1272},"Sitecore services",{"type":168,"value":1274}," cover the audit and the remediation work\nitself.",{"type":162,"tag":163,"props":1276,"children":1278},{"id":1277},"the-seven-question-readiness-check",[1279],{"type":168,"value":1280},"The Seven-Question Readiness Check",{"type":162,"tag":171,"props":1282,"children":1283},{},[1284],{"type":168,"value":1285},"If you do nothing else from this article, answer these seven questions with your\nengineering lead in the room. Every \"no\" is a number on your migration invoice.",{"type":162,"tag":895,"props":1287,"children":1288},{},[1289,1310],{"type":162,"tag":899,"props":1290,"children":1291},{},[1292],{"type":162,"tag":903,"props":1293,"children":1294},{},[1295,1300,1305],{"type":162,"tag":907,"props":1296,"children":1297},{},[1298],{"type":168,"value":1299},"#",{"type":162,"tag":907,"props":1301,"children":1302},{},[1303],{"type":168,"value":1304},"Ask your team",{"type":162,"tag":907,"props":1306,"children":1307},{},[1308],{"type":168,"value":1309},"A \"no\" means",{"type":162,"tag":923,"props":1311,"children":1312},{},[1313,1331,1349,1367,1385,1403,1421],{"type":162,"tag":903,"props":1314,"children":1315},{},[1316,1321,1326],{"type":162,"tag":930,"props":1317,"children":1318},{},[1319],{"type":168,"value":1320},"1",{"type":162,"tag":930,"props":1322,"children":1323},{},[1324],{"type":168,"value":1325},"Is content headless-ready?",{"type":162,"tag":930,"props":1327,"children":1328},{},[1329],{"type":168,"value":1330},"Content model redesign, migration scripts, author retraining",{"type":162,"tag":903,"props":1332,"children":1333},{},[1334,1339,1344],{"type":162,"tag":930,"props":1335,"children":1336},{},[1337],{"type":168,"value":1338},"2",{"type":162,"tag":930,"props":1340,"children":1341},{},[1342],{"type":168,"value":1343},"Are personalization rules documented?",{"type":162,"tag":930,"props":1345,"children":1346},{},[1347],{"type":168,"value":1348},"An inventory project before anyone can scope the rebuild",{"type":162,"tag":903,"props":1350,"children":1351},{},[1352,1357,1362],{"type":162,"tag":930,"props":1353,"children":1354},{},[1355],{"type":168,"value":1356},"3",{"type":162,"tag":930,"props":1358,"children":1359},{},[1360],{"type":168,"value":1361},"Is xDB usage minimal?",{"type":162,"tag":930,"props":1363,"children":1364},{},[1365],{"type":168,"value":1366},"A migration blocker, not an inconvenience",{"type":162,"tag":903,"props":1368,"children":1369},{},[1370,1375,1380],{"type":162,"tag":930,"props":1371,"children":1372},{},[1373],{"type":168,"value":1374},"4",{"type":162,"tag":930,"props":1376,"children":1377},{},[1378],{"type":168,"value":1379},"Are pipelines documented?",{"type":162,"tag":930,"props":1381,"children":1382},{},[1383],{"type":168,"value":1384},"Reverse-engineering, and a fixed bid that will not hold",{"type":162,"tag":903,"props":1386,"children":1387},{},[1388,1393,1398],{"type":162,"tag":930,"props":1389,"children":1390},{},[1391],{"type":168,"value":1392},"5",{"type":162,"tag":930,"props":1394,"children":1395},{},[1396],{"type":168,"value":1397},"Is search abstracted?",{"type":162,"tag":930,"props":1399,"children":1400},{},[1401],{"type":168,"value":1402},"A search rewrite scoped blind",{"type":162,"tag":903,"props":1404,"children":1405},{},[1406,1411,1416],{"type":162,"tag":930,"props":1407,"children":1408},{},[1409],{"type":168,"value":1410},"6",{"type":162,"tag":930,"props":1412,"children":1413},{},[1414],{"type":168,"value":1415},"Is multi-site isolated?",{"type":162,"tag":930,"props":1417,"children":1418},{},[1419],{"type":168,"value":1420},"The single largest swing factor in the estimate",{"type":162,"tag":903,"props":1422,"children":1423},{},[1424,1429,1434],{"type":162,"tag":930,"props":1425,"children":1426},{},[1427],{"type":168,"value":1428},"7",{"type":162,"tag":930,"props":1430,"children":1431},{},[1432],{"type":168,"value":1433},"Is DevOps automated?",{"type":162,"tag":930,"props":1435,"children":1436},{},[1437],{"type":168,"value":1438},"Every other fix on this list gets slower",{"type":162,"tag":480,"props":1440,"children":1441},{},[1442],{"type":162,"tag":171,"props":1443,"children":1444},{},[1445,1450],{"type":162,"tag":462,"props":1446,"children":1447},{},[1448],{"type":168,"value":1449},"How to read your answers:",{"type":168,"value":1451}," one or two \"no\" answers is a normal, healthy backlog.\nFour or more, and remediation is its own project with its own budget, not a\nworkstream you can hide inside a migration. Score the six domains properly before\nanyone commits to a date.",{"type":162,"tag":163,"props":1453,"children":1455},{"id":1454},"xp-isnt-the-problem-technical-debt-is",[1456],{"type":168,"value":1457},"XP Isn't the Problem, Technical Debt Is",{"type":162,"tag":171,"props":1459,"children":1460},{},[1461],{"type":168,"value":1462},"XP remains a powerful platform, and a well-run installation can still serve an\nenterprise well. What determines whether modernization is smooth or painful is\ntechnical debt, not the platform. A structured audit gives organizations clarity,\nreduces migration cost, and ensures future modernization, to an enterprise headless\nCMS like XM Cloud or elsewhere, is strategic rather than reactive.",{"type":162,"tag":171,"props":1464,"children":1465},{},[1466],{"type":168,"value":1467},"The organizations that succeed over the next few years will be the ones that\nunderstand their debt now and reduce it before migration turns urgent.",{"type":162,"tag":163,"props":1469,"children":1471},{"id":1470},"further-reading",[1472],{"type":168,"value":1473},"Further reading",{"type":162,"tag":171,"props":1475,"children":1476},{},[1477,1479,1487,1489,1495,1497,1503,1505,1510],{"type":168,"value":1478},"This piece is adapted, with permission, from David Walker's\n",{"type":162,"tag":233,"props":1480,"children":1484},{"href":1481,"rel":1482},"https:\u002F\u002Fradicaldave.com\u002Fblog\u002Fsitecore-xp-technical-debt-audit",[1483],"nofollow",[1485],{"type":168,"value":1486},"The Sitecore XP Technical Debt Audit",{"type":168,"value":1488},",\nwhich goes deeper into the audit framework. If you're weighing whether to migrate at\nall, ",{"type":162,"tag":233,"props":1490,"children":1492},{"href":1491},"\u002Fblog\u002Fenterprise-cms\u002Fenterprise-cms-2026-platform-and-partner",[1493],{"type":168,"value":1494},"Enterprise CMS in 2026: How to Choose the Platform and the Partner",{"type":168,"value":1496},"\ncovers the platform-and-partner decision behind every modernization call. Custom\npipeline debt is what shows up when a Sitecore build's delivery goes wrong, and the\n",{"type":162,"tag":233,"props":1498,"children":1500},{"href":1499},"\u002Fblog\u002Fenterprise-cms\u002Ffigma-developer-handoff-sitecore-component-library",[1501],{"type":168,"value":1502},"Figma-to-Sitecore component library rebuild playbook",{"type":168,"value":1504},"\nwalks through fixing it after the fact. For teams evaluating XM Cloud,\n",{"type":162,"tag":233,"props":1506,"children":1507},{"href":235},[1508],{"type":168,"value":1509},"Enterprise Headless CMS, Explained",{"type":168,"value":1511},"\nbreaks down what \"enterprise\" adds on top of \"headless.\""]