A platform can remain available and supported while making every useful change harder. The effect appears in estimates, release queues, workarounds and ideas abandoned before anyone creates a business case.
Calling this a “platform tax” is helpful because the cost is distributed. It is also only a hypothesis. Slow delivery can come from unclear priorities, scarce people, weak governance or poor supplier performance. A responsible assessment distinguishes those causes before recommending replacement.
Begin with changes the firm attempted
Select five to ten recent initiatives across different teams. Include successful work, delays and ideas that were declined. For each one, reconstruct:
- the outcome requested
- original and actual time, cost and scope
- waiting time and hand-offs
- platform changes and specialist involvement
- defects, rework and rollback
- compromises made because of constraints
- continuing operating effort
The pattern matters more than one difficult project. A poorly defined requirement should not become evidence against the platform. Repeated technical constraints across well-scoped work deserve attention.
Ask about requests that never reached the backlog. Marketing, operations and client teams may have learned to avoid proposing changes because they expect them to be rejected. Record the need and why it was abandoned without treating speculative benefit as certain value.
Examine six dimensions
Routine change
Measure how long capable teams need to publish content, add a field, change a journey or release a small feature. Separate active work from waiting for access, approval, a supplier or a release window.
A controlled release process may be entirely appropriate after previous failures. The assessment should ask whether its controls match the risk and whether the platform supports safer, more frequent change through testing, preview, progressive release and rollback.
Integration
Map the systems and data flows around the platform. Review interface documentation, authentication, monitoring, error handling, ownership and version support.
The existence of an API is weak evidence. Teams need to know whether it exposes the required data safely, whether changes are versioned and how failures are recovered. Repeated point-to-point code and manual reconciliation may show that integration has become a constraint.
Editorial and operational use
Observe people completing routine tasks. Can authorised users create, review, preview, schedule and correct content without avoidable developer intervention? Can service teams understand status and exceptions? Are accessibility and metadata supported in the workflow?
Do not confuse unlimited editing freedom with a good platform. Guardrails can protect consistency and safety. The issue is whether the system allows the organisation to perform legitimate work at the appropriate level of control.
Architecture and support
Check vendor and dependency support, customisation, test coverage, deployment, observability, recovery and skills availability. Identify components that cannot be patched or reproduced reliably.
Age alone does not establish a problem. Evidence of increasing incidents, constrained change, unsupported software or vanishing expertise is more relevant.
Data and permissions
New services, including AI-enabled ones, depend on usable, governed data. Assess structure, provenance, quality, rights, access controls and the ability to retrieve information through maintained interfaces.
A platform should not expose more data merely to appear flexible. The test is whether it can support authorised uses with appropriate security, audit and lifecycle control.
Total operating cost
Combine licences, hosting, supplier support, internal effort, incident response, manual work and the cost of maintaining custom extensions. Separate routine operation from work caused by avoidable complexity.
Opportunity cost should be tied to specific rejected or delayed outcomes. Avoid claiming that every platform limitation represents lost revenue.
Test the causal story
For each significant symptom, ask what evidence would disprove the platform hypothesis.
If releases are slow, could unclear ownership or overloaded approvers explain the delay? If integrations are expensive, is the external system the constraint? If editors need developers, is that a platform limitation or an overly restrictive governance choice?
Trace a small change from request to production. Review logs, tickets and estimates. Speak to internal teams and suppliers separately, then compare explanations. A blame-free assessment is more likely to reveal where the real waiting and rework occur.
Use a simple confidence rating for each finding and record contradictory evidence. This protects the decision from a persuasive anecdote.
Compare four responses
Operate and monitor
The platform may be adequate for the strategy. Document the risks, improve measurement and define triggers for another review. “Keep” should be an active decision with an owner.
Improve the implementation
Remove unnecessary customisation, update dependencies, strengthen tests, simplify workflows or improve documentation. This is appropriate where the product's foundation remains supported and capable.
Extend selectively
A managed service, content layer or integration capability may address a specific gap. Model the added supplier, data and operating complexity. A new tool can move the constraint rather than remove it.
Replace or retire
Replacement is justified when essential outcomes cannot be supported safely or economically, and other options compare poorly over the decision horizon. Consider phased migration, dual running, data work, training and decommissioning. A modern product does not compensate for recreating every old customisation.
Build the comparison around future work
Evaluate options against a small set of likely scenarios: a new service line, acquisition, portal improvement, regulatory change, content expansion or an approved AI use case. Use scenarios connected to strategy rather than an unlimited list of hypothetical features.
Estimate total cost over an appropriate period, with ranges and assumptions. Include the cost of transition and continued operation. Show which option creates or removes dependence on a vendor, scarce skill or architectural component.
Prototype the highest-uncertainty claim where practical. A technical spike can test whether a critical integration is feasible. A short editorial trial can expose workflow limits. Evidence is cheaper than committing to a platform based on a feature checklist.
Give the board a commercial answer
Report the services affected, consequences, evidence and choices. “The CMS is inflexible” is an opinion. “Publishing a new regulated content type requires three suppliers, averages this much elapsed time and cannot be tested in a representative environment” is a decision input.
The conclusion may be that the platform is sound and governance needs work. That is a successful assessment. It prevents a costly migration that would reproduce the same delay.
Where the platform is the constraint, identify the smallest safe step: foundation remediation, an option appraisal, a migration discovery or retirement of one troublesome capability. Set a decision date and measures.
The question is not whether the technology feels modern. It is whether the current foundation lets the firm make the changes its strategy requires, at an acceptable cost and risk. A platform assessment earns its value by answering that question with evidence, including when the answer is that the platform should stay.
