A Sitecore renewal can expose a widening gap between the platform a firm owns and the capabilities it actually uses. That gap is worth examining, but licence anxiety alone is a poor reason to replatform.

Sitecore products, versions and support phases differ. Existing XP or XM implementations, managed cloud arrangements and newer SaaS products cannot be treated as one architecture or commercial model. The decision must begin with the exact estate, contract and business need.

Migration may be justified. Staying, upgrading or simplifying may also be the stronger choice.

Identify the product and support position

Record the product, edition, version, topology, hosting, modules, licences, custom code and support agreement. Sitecore’s current Product Support Lifecycle lists separate mainstream, extended and sustaining support dates for product versions. Verify it at the decision date because support status changes.

For each environment, establish:

  • current support phase and required upgrades;
  • security and patch position;
  • infrastructure and deployment ownership;
  • disaster recovery and monitoring;
  • licensed features and actual use;
  • integrations and data flows;
  • customisation and third-party modules;
  • content, media and search dependencies;
  • internal and supplier skills;
  • renewal, notice and exit dates.

Do not let “Sitecore” stand in for several services with different risks. A content delivery environment, personalisation capability and custom integration may each need a separate retain, replace or retire decision.

Compare capability with evidence of use

Enterprise platforms can be valuable when advanced capability contributes to an outcome. They are wasteful when licensed features remain unused and still add operating complexity.

Audit real usage of personalisation, experimentation, analytics, workflow, automation, multilingual publishing and other relevant functions. Capture campaign evidence, user groups, frequency, dependencies and measurable results. Opening a feature once does not make it strategically necessary.

Also investigate why a feature is unused. The business may not need it. The implementation may be poor, data may be absent or the team may lack capacity. Migration will solve only some of those causes.

Avoid universal claims that mid-market organisations use a small percentage of Sitecore. The firm’s own telemetry, licence record and working practices are stronger evidence.

Calculate total cost of ownership

Separate licence, hosting, managed service, infrastructure, development, upgrades, support, assurance, integration, incidents, editorial effort and internal specialist time. Include the cost of delayed or abandoned changes where it can be evidenced.

Build comparable options:

  • renew and operate as now;
  • optimise or remove unused elements;
  • upgrade within the current product family;
  • adopt a different Sitecore product or architecture;
  • migrate to another platform;
  • separate content management from other marketing capabilities.

Use the same period, demand assumptions and risk treatment. First-year implementation cost should be compared with ongoing ownership, transition and exit. Obtain an explicit commercial proposal rather than relying on another customer’s renewal story.

Sunk investment explains the present estate and does not prove it should continue. Equally, money already spent on sound content models, integrations or components may represent reusable value.

The companion article on what legacy platforms hide from the profit and loss account can help structure costs, provided each estimate is grounded locally.

Observe editorial and delivery work

Ask editors to complete representative tasks and delivery teams to release a safe change. Record wait time, handoffs, assistance, defects and constraints.

Poor editorial experience may come from the platform, implementation, component design, workflow, permission model or operating process. A new CMS can preserve the same bottleneck if the organisation repeats the design choices.

Examine how quickly the team can create and govern structured content, reuse approved material, preview channels, update navigation and correct urgent information. Include accessibility and brand controls. Independence should mean appropriate control, not unrestricted page construction.

For developers, assess build, test, deployment, observability, environment creation and recovery. Scarce skills may be a risk; measure recruitment, supplier concentration, rates and knowledge rather than asserting that the whole talent market has deteriorated.

Test architecture against real future needs

Create a small number of future scenarios tied to agreed strategy. Examples may include serving several brands, publishing structured content across channels, integrating a CRM journey or supporting an evaluated AI use.

Do not treat “AI-ready” as synonymous with headless or composable. AI applications require fit-for-purpose information, permissions, provenance, evaluation and governance. Tightly coupled presentation may make reuse harder, yet migration alone will not create safe, structured knowledge.

For each scenario, test whether the current estate can support it, what change is required and how alternatives compare. Consider data, APIs, latency, security, content operations, skills and total cost.

A proof of concept should target consequential uncertainties. It should not become a vendor-led tour of every feature.

Inventory customisation and integrations

Custom code is neither automatically valuable nor automatically debt. Determine which business need it serves, whether the need remains, code and test quality, support ownership and the cost of replacement.

Classify each item:

  • retain or port because it creates necessary value;
  • replace with supported native capability;
  • redesign because the old requirement was flawed;
  • retire because the need disappeared;
  • isolate temporarily with an explicit exit plan.

Map integrations at the same time. Identify authoritative data, security boundaries, error handling, monitoring and failure recovery. Migration estimates are unreliable until the team knows which behaviours, rather than merely which endpoints, must survive.

Evaluate alternatives without a favourite

Xperience by Kentico, Payload, Optimizely, Umbraco and other platforms may all enter a longlist. Product capability, packaging and pricing change, so a generic recommendation becomes stale quickly.

Define weighted criteria from the firm’s service, then verify products through current official documentation, contractual proposals, reference evidence and focused hands-on testing. Consider:

  • editorial model and governance;
  • required marketing and experimentation capability;
  • integration and content APIs;
  • accessibility and security;
  • hosting and operational responsibility;
  • data and supplier portability;
  • implementation ecosystem and internal skills;
  • whole-life cost;
  • migration and exit risk.

The related guides on Contentful and Payload and choosing a digital platform can support evaluation. Their product claims also need current verification at the point of use.

Avoid replacing one oversized suite with a collection of services the organisation lacks capacity to operate. Composability creates choice and coordination work.

Plan before renewal removes the options

Use contract dates to work backwards through assessment, selection, content decisions, migration, parallel operation and notice. The right lead time follows estate complexity and procurement, rather than a universal 12-to-18-month rule.

A planned decision usually provides more options than an emergency caused by end of support, a failed renewal or loss of specialist knowledge. That does not justify invented claims that emergency migration costs a fixed multiple.

If staying, agree optimisation, upgrade and governance actions with owners and review dates. If leaving, create a target content model, repeatable migration, redirect plan, whole-service tests, rollback and operating handover.

Distinction’s platform health check can examine utilisation, cost, support, editorial work, architecture and credible alternatives. Because Distinction works with platform implementations, its commercial interest should be explicit and the evidence open to challenge. The useful output is a defensible stay, change or migrate decision before the contract makes it by default.