You know you need to do something about your platform. Here's exactly what an assessment involves, what it disrupts, and what you're left holding afterwards.
You already know you need to do something about your platform. That's not the bit holding you up.
What's holding you up is everything else. What will we actually need to give them access to? Who's getting pulled into meetings? Is this going to eat two months of my team's time? And - the real question, the one nobody asks out loud - if we go through all of this and decide not to do anything, have we just burned everyone's time and budget for nothing?
I know this because we hear it constantly. Technology leaders who've had the platform conversation internally three or four times, who've maybe even got informal budget approval, but who haven't pulled the trigger because the process itself feels like an unknown. I'm not sure what a platform assessment actually involves or whether the disruption is worth it.
Fair enough. So let me describe it - not the sales pitch version, but the actual process, with enough specificity that you can decide whether it makes sense before you speak to anyone.
A platform assessment covers seven areas. Not because seven is a magic number - these are just the places where we consistently find the things that cost firms money, create risk, or block progress.
Current platform capability. We're looking at whether your platform can do what your firm needs it to do now, and what you'll need it to do in 12 to 18 months. There's a meaningful difference between "the CMS technically supports personalisation" and "your team can actually use the personalisation features without filing a support ticket." We care about the second one.
Technical debt. The accumulated mess. Outdated dependencies, unsupported plugins, deferred maintenance, custom code that nobody who still works at the firm fully understands. Every platform accumulates this over time - the question is how much of it is creating genuine risk versus how much is just ugly but harmless.
Integration architecture. How your platform connects to your CRM, marketing automation, finance systems, client portal - whatever else sits in the stack. Which connections are solid, which are fragile, and where the gaps are costing you. I was reviewing a firm's integration layer last year and found a critical data sync running on a scheduled task that someone had set up as a "temporary fix" in 2019. It was still running. It was also failing silently about 15% of the time. Nobody had noticed because the failures were just absorbed into manual workarounds. That's the kind of thing we find.
Editorial experience. How your content and marketing team actually experiences the platform day-to-day. The tasks that take twenty minutes when they should take two. The workflows that require a developer to do something that should be self-service. The features that are technically available but practically unused because nobody was ever trained on them, or because they're buried behind an interface that makes no sense. This one matters more than most CTOs expect - editorial frustration is one of the biggest drivers of shadow IT and workaround culture, and it compounds quietly for years before anyone names it.
Performance. Page speed, server response times, the bottlenecks that affect both user experience and search visibility. We're looking at it through a commercial lens - not just "is it fast enough" but "where is slow performance actually costing you enquiries or engagement?"
Security posture. Platform version, dependency support status, access control configuration, and the specific vulnerabilities your current setup creates. This is the area that tends to produce the most eyebrow-raising findings, particularly for firms running platforms approaching or past end-of-life support. I've had clients genuinely surprised by what's sitting in their stack - not because they're careless, but because nobody had looked properly in three or four years.
Scalability. Can your platform's architecture handle what's coming? More content, more users, more integrations, potentially AI capabilities that your current CMS was never designed to support. If you're planning to grow - through acquisition, new markets, or new service lines - we need to know whether the platform grows with you or becomes the thing that slows everything down.
These seven areas map directly to how we think about the "Now" in our WHNN® framework - getting an honest picture of where things actually stand before anyone starts talking about where they need to go.
A prioritised findings report. Typically 15 to 25 pages. Not a technical audit document - a commercially framed assessment that your managing partner can read and your implementation team can act on.
Every finding is ranked by its likely effect on your commercial objectives: client acquisition, client experience, operational efficiency, risk exposure. Not by how technically interesting it is. I've seen assessment reports from other firms that spend twelve pages on database indexing optimisation and half a page on the fact that the enquiry form hasn't worked properly on mobile for six months. We don't do that. Commercial impact determines the priority order.
Each finding is written in plain language. There's a technical appendix for your development team, but the main report is designed to be read by someone who makes investment decisions.
The report concludes with three clearly differentiated pathways:
Optimise - address the most pressing issues within your existing platform architecture. The "you don't need to move, but you do need to fix these things" option.
Incremental improvement - a phased programme of targeted investment that addresses issues in priority order without a full migration. A structured plan to make your current platform significantly better over six to twelve months, rather than ripping it out.
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.
One thing I should be straight about: the three pathways aren't equally likely outcomes. The findings will point more strongly toward one than the others. We're not going to present three options and shrug. We'll tell you what we think you should do and why. But the decision is yours, and there's no obligation to proceed with Distinction for whatever comes next. The assessment is a complete deliverable in its own right.
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.
Two to three weeks from kickoff to findings presentation.
Week one is the week that requires the most from your side. We get technical access provisioned, schedule and complete stakeholder interviews, and review whatever platform documentation exists. Week two is mostly us, heads down - technical analysis, editorial experience testing, performance analysis, security review. Week three we synthesise findings, develop the three pathways, write the report, and review it internally before presenting it. Then a one-hour findings presentation with you and relevant stakeholders to walk through everything, discuss the pathways, and answer questions.
Your total time commitment across the three weeks is typically four to six hours. Most of that is in the stakeholder interviews and the final presentation. We're not setting up camp in your office for a month. I know some firms have had that experience with consultancies - a sort of low-grade occupation where people are always around but nothing seems to move - and I understand the wariness. But if we can't form a clear view within three weeks, something's gone wrong with our process, not yours.
Three things, really.
Read-only administrative access to the CMS or DXP, plus hosting environment credentials or documentation, and access to the integration layer or API documentation where applicable. Three to four stakeholder interviews of about 45 minutes each - typically the primary digital or technology lead, one or two content editors or marketing team members who use the platform daily, and the managing partner or operations lead sponsoring the assessment. And whatever existing documentation you have lying around: technical docs, integration diagrams, previous audit findings. Even if they're incomplete or three years out of date, they're useful as a starting point. Saves us rediscovering things you already know.
What we don't need: your commercial strategy documents, financial information beyond what's needed to frame the investment context, or access to client-facing systems beyond the platform being assessed. We need to see the platform, talk to the people who use it, and understand what the firm needs it to do. That's it.
In our experience, firms go one of three directions after receiving the findings.
Some proceed with the optimise pathway. This tends to happen when the assessment confirms that the current platform is fundamentally sound and the issues are addressable within the existing architecture. It's usually the fastest and most cost-effective path. Sometimes the best outcome of an assessment is confirming you don't need to spend a fortune - you just need to spend smartly on the right things. One client last year came in expecting to hear they needed a full replatform; the findings said otherwise. They spent about a fifth of what they'd budgeted, fixed the things that were actually causing problems, and were done in eight weeks. Not every story ends in a big project.
Some commission a more detailed scoping for the incremental or replatform pathway. When the assessment recommends more significant investment, firms typically use the findings to commission a scoping engagement that produces the precise cost and timeline needed for board approval. The assessment gives you enough to know the direction of travel; the scoping gives you enough to get the cheque signed. For firms heading toward replatforming, our Billy accelerator for composable digital experiences and Henry accelerator for AI-powered content migration are often relevant at this stage - both are specifically designed to reduce the risk and timeline of the transition.
And some take the findings internally and don't proceed immediately. They use the document to brief internal IT teams, challenge their current platform vendor, negotiate better support terms, or build the business case for investment that happens six or twelve months later. That's completely fine. The findings document has standalone value. We don't follow up with a commercial proposal unless you ask us to. No chaser emails, no "just checking in" calls. If the assessment does its job, you'll know what to do with it.
Look - I'm aware that describing your own assessment process in this much detail is a slightly odd thing to publish. But the reason we do it is simple: the biggest barrier to getting started isn't scepticism about the value. Most technology leaders already know their platform has problems. The barrier is uncertainty about the process itself - what it involves, what it disrupts, what it costs, and what you're left with at the end.
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. And if you'd rather see the output before having any conversation at all, [download the redacted sample assessment summary] - it'll tell you more about what we actually deliver than any conversation could.
[PLACEHOLDER: Investment range for a standard platform assessment - James to confirm what figure or range can be published]