Technology leaders often reach the same awkward point. The platform has recognised problems and informal support for action, yet the assessment itself feels like an unknown. Who will be pulled into interviews? What access will an external team need? How disruptive will the work be? What value remains if the firm decides to delay investment?

This article describes Distinction's platform assessment as a concrete engagement. It should help a potential sponsor judge the scope before entering a sales conversation.

Seven lenses on the current platform

The assessment considers seven connected areas. The depth in each one depends on the client's objectives and access; they are lenses for investigation, rather than a claim that every estate has the same problems.

Current capability. We compare what the platform enables with what the organisation needs now and expects to need next. A feature appearing on a product page is weak evidence of practical capability. We look at whether people can use it within their permissions, skills and workflows.

Technical debt and supportability. This covers outdated dependencies, unsupported components, deferred maintenance and custom code whose ownership is unclear. The aim is to distinguish untidy implementation from debt that creates operational cost, delivery friction or material exposure.

Integration architecture. We trace important connections to CRM, marketing, identity, finance, portals and other services. The review asks who owns each connection, how failures become visible, which limits apply and where manual work compensates for weak data movement. A temporary scheduled task can survive for years if it fails silently and colleagues absorb the exceptions.

Editorial experience. Editors show us recurring tasks, approvals, workarounds and dependencies on developers. A platform can be technically capable while making routine publishing unreasonably slow. That gap affects campaign speed, content quality and the willingness of teams to use governed tools.

Performance. We examine relevant page and system behaviour and connect it to user journeys. The assessment does not turn a single performance score into a commercial loss estimate. It identifies where delay is likely to obstruct discovery, completion or internal work and recommends deeper measurement where attribution is uncertain.

Security posture and support risk. We review matters within the agreed platform scope, such as versions, support status, dependencies, access controls and visible configuration risks. This is not a penetration test or a substitute for specialist security assurance. Any serious finding should be validated and routed through the client's security process before wider circulation.

Scalability and change readiness. Growth can mean additional content, users, markets, acquisitions, integrations or new digital services. We test whether the present design and operating model can support the expected change, including the people and governance required to run it.

Together, these lenses establish the “Now” in Distinction's WHNN® framework. The purpose is a shared, evidence-led baseline before anyone turns a preferred future into a platform recommendation.

The deliverable is a decision document

The principal output is a prioritised findings report, often around 15 to 25 pages with supporting technical material where useful. Exact length should follow the evidence; page count is not the measure of value.

The main report is written for people who fund and operate the platform. Findings are ordered by their likely effect on objectives such as client acquisition, service experience, operating efficiency and risk. Technical severity remains important, particularly for security and resilience, while commercial framing helps the leadership team decide who should act and when.

Each material finding should contain:

  • The observation and evidence
  • The consequence and affected owners
  • Confidence and important limitations
  • A proportionate action
  • Dependencies, indicative effort and urgency

The assessment then develops three types of pathway.

Optimise addresses priority issues within the existing architecture. This can be the right direction when the foundation remains supportable and the main constraints are contained.

Improve incrementally sequences targeted investments without committing immediately to a full migration. It suits an estate where the present platform can carry near-term priorities while particular services, integrations or workflows change.

Replatform - replace the platform entirely. This pathway includes an indicative scope, timeline, and cost range for the recommended alternative. For firms heading this way, I've written separately about what a realistic CMS migration actually costs and how to compare total cost of ownership across platforms honestly - worth reading if the findings point here.

The evidence usually favours one route. Distinction should state its recommendation and reasoning while preserving the client's freedom to act internally or appoint another delivery partner. The assessment is a standalone deliverable, rather than a proposal disguised as analysis.

If you want to see what this actually looks like before committing, [download a redacted sample platform assessment summary here] - a real findings document with client-identifying detail removed, showing the structure, the finding types, the three pathways format, and how issues are prioritised.

Timing and demand on the client team

A typical assessment takes two to three weeks once access and interviews are available.

The first week concentrates client involvement: kickoff, access, documentation and stakeholder conversations. The second concentrates analysis across the agreed lenses. A third week may be used to test conclusions, develop pathways, complete internal review and present the findings.

The source estimates four to six hours of total client time across three to four interviews and the findings session. That may be realistic for a contained platform; it should remain an indicative range. Complex ownership, incomplete documentation or several critical integrations can require more. The scope should say which people are needed and why, so the sponsor can test the demand before kickoff.

An assessment should avoid becoming a low-grade occupation in which consultants attend many meetings while decisions barely move. The countermeasure is a named question, a clear access list, scheduled interviews and an agreed date for the findings session.

Access, handling and boundaries

Distinction will usually request:

  • Read-only CMS or DXP access with enough visibility to inspect relevant configuration
  • Hosting and deployment documentation, with access agreed only where required
  • Integration diagrams, API documentation and ownership information
  • Existing audits, incident notes and architecture records
  • Interviews with the sponsor, technology owner and people who use the platform routinely

Credentials and client data need controlled handling. Access should be least-privilege, time-limited where possible and removed at engagement close. If production access is unnecessary, the team should use a safer route. Security teams need enough notice to approve the arrangement without delaying the work.

The assessment does not require unrestricted access to every client-facing system or broad commercial records. Relevant financial context can help compare pathways, and confidential information should only be requested when it changes the decision. Scope boundaries, exclusions and evidence gaps belong in the final report.

How clients use the result

Some firms optimise the present estate. One source example describes a client that expected a replatform and instead completed targeted repairs in eight weeks for about a fifth of its provisional budget. The proportions should be verified against the project record and client permission before publication. The useful lesson is that an assessment can justify continued investment in the existing platform.

Others use the report to commission detailed scoping for incremental improvement or migration. An indicative direction is rarely enough to authorise a large programme; discovery must establish user needs, content, architecture, delivery plan, cost and risk in greater depth.

A third group takes the findings internally. The report may help an internal team prioritise work, challenge a vendor, plan budget or wait for a contractual moment. That is a legitimate use. Any later sales contact should respect the preference agreed with the client, rather than relying on a universal promise of no follow-up.

Distinction's Billy and Henry accelerators may become relevant to a composable implementation or content migration. They should be introduced only when the evidence supports that path, with their scope and limitations explained separately.

Decide whether the assessment resolves an uncertainty

An assessment is worthwhile when uncertainty about platform condition, fit or options is preventing a decision. It is less useful when leaders have already agreed the problem and need delivery discovery, or when a specialist security, accessibility or data exercise is the real requirement.

Before commissioning one, ask what decision the report must enable, what evidence is available and who must trust the conclusion. If those answers are clear, the work can stay focused and retain value regardless of which pathway the client chooses.

If this has answered those questions clearly enough and you want to talk through whether an assessment makes sense for your specific situation, book a 30-minute scoping conversation. No commitment, no proposal.