The annual licence and hosting bill rarely represents the full cost of a platform. Work created by its limitations sits in technology, marketing, operations, risk and supplier budgets. Each line can look reasonable on its own. The shared cause disappears when the P&L is viewed by department.
That is why a platform described as “good enough” can consume far more cash and capacity than leadership realises. The problem is not poor accounting. Conventional accounts answer different questions from a platform decision.
A useful legacy-cost model creates a management view across the P&L. It should show the cost currently absorbed, the evidence behind each estimate and the portion that a proposed change could credibly remove. It should also expose benefits that sound plausible and cannot yet be supported.
The result is a range, not a magic number.
Begin with a cost map, not a replacement case
If the exercise begins with a desire to approve a new platform, every inconvenience is likely to become a benefit in the model. Give the assessment a neutral brief:
What cash, capacity, risk and forgone choices are associated with operating this platform for the next decision period?
Define the platform boundary. Include the content system, hosting, custom components, integrations, support arrangements and the internal processes needed to run them. Record adjacent systems whose costs should remain separate. Without this step, the assessment can absorb every digital inefficiency in the organisation.
Set a baseline period that represents normal operation. One unusually difficult month may distort the result; a full year can hide a recent deterioration. Use more than one period where necessary and explain anomalies.
Trace cost through six ledgers
The “ledgers” below are management categories. Finance may record them under different headings.
Maintenance labour
Identify internal and external effort spent on patches, releases, compatibility problems, monitoring, incident recovery, hosting administration and changes required simply to preserve service.
Time sheets can help, although many teams do not record work at that level. A two-to-four-week activity sample, checked against tickets and release records, may be more credible than retrospective estimates for an entire year.
Classify mixed work carefully. An upgrade may preserve support and enable a new capability. Allocate the cost or describe it as shared. Avoid calling all engineering on an established platform “maintenance”.
Manual workaround effort
Find recurring steps that compensate for platform limitations: reformatting content, rekeying information, reconciling exports, rebuilding reports, duplicating approvals or asking a supplier to make routine changes.
Observe the process before estimating it. Multiply task time by actual volume and an appropriate employment cost. Do not assume every hour can be removed. Some steps contain judgement, control or relationship work that the replacement process will still need.
Add rework and delay where they are measured. Keep speculative productivity gains separate.
Integration maintenance and failure
List the interfaces required for the platform to operate. Use incident data to identify support time, downstream correction, delayed work and supplier involvement.
Custom integrations are not inherently bad, and packaged connectors are not maintenance-free. The relevant questions are reliability, ownership, documentation, change frequency and the effort required when either system evolves.
Where an incident affects several teams, guard against counting the same lost time in multiple categories.
Security and continuity exposure
Record cash spent on compensating controls, specialist reviews, extended monitoring and recovery arrangements created by known platform constraints.
Treat risk separately from certain cost. A vulnerability, outage or unsupported component does not justify inserting an arbitrary share of a generic breach figure. Describe credible scenarios, existing controls, possible impact and the evidence used for likelihood. Ask security, risk, legal and compliance specialists to validate the assessment.
The replacement option needs an equivalent view of migration, configuration, supplier and transition risks.
Constrained opportunity
List specific initiatives delayed, reduced or abandoned because of a demonstrated platform constraint. Link each to a decision record, discovery finding or technical assessment.
An earlier business case may provide a starting range. Discount it for uncertainty and for other dependencies. A client portal that the current CMS cannot support may also require process, identity, content and adoption work; its whole projected benefit cannot be attributed to the CMS.
If no credible value exists, record the constrained choice without converting it to money. That makes the limitation visible while protecting the model from advocacy.
Supplier and skill concentration
Compare current support rates, contract terms, recruitment evidence and the availability of people who understand the estate. Include knowledge concentration and documentation, not merely the price of a specialist.
A higher rate may reflect experience, urgency or contract structure rather than platform age. Compare equivalent services and use current market evidence. The more strategic concern may be resilience: whether the organisation can continue operating when one supplier or individual becomes unavailable.
Reconcile the management model to the P&L
For each estimate, record the existing budget owner and account code where possible. This prevents a board from reading the total as entirely new expenditure.
Use four columns:
- Recorded cash cost: invoices, payroll allocation and other expenditure already visible.
- Absorbed capacity: employee time currently included in departmental overhead.
- Risk exposure: scenario-based consequence rather than certain annual spend.
- Constrained value: opportunities supported by evidence, shown separately from cost.
These columns should not be added casually. £100,000 of employee capacity, £100,000 of possible incident impact and £100,000 of projected opportunity are different economic quantities. A single “legacy tax” total can obscure more than it reveals.
Show the official platform budget beside the wider management view. Explain the reconciliation. A CFO can then see which amounts are already in the accounts, which are allocations and which remain uncertain.
Model ranges and confidence
For every material line, document:
- source data and period;
- calculation;
- inclusions and exclusions;
- low, central and high values where justified;
- confidence level;
- the assumption most likely to change the result; and
- the person who has reviewed it.
Ranges should express genuine uncertainty. Avoid setting a central value simply halfway between two arbitrary bounds. Some categories may have a reliable cash figure and no need for a range. Others may belong in a narrative risk register until the evidence improves.
Run sensitivity analysis on the few assumptions that drive the decision. Common examples include internal time released, remaining support life, migration effort, adoption of a new workflow and the value of a constrained initiative. Showing how the conclusion changes when those assumptions move is more persuasive than defending one total to the last pound.
Compare cost trajectories with the same discipline
The current platform and every modernisation option need comparable treatment over an agreed horizon.
For the current state, model known contract changes, end-of-support events, planned regulatory work, likely volumes and committed remediation. Do not apply a universal annual escalation rate.
For a change option, include discovery, implementation, content and data work, integrations, testing, security and compliance assurance, change management, dual running, contingency, decommissioning and target-state operation. Show when savings or capacity could actually be released. A process may continue for months after launch, and a contract may run until its next break point.
Include at least one alternative to full replacement. Remediation, simplification, selective decoupling, reduced scope or a managed extension may produce a better risk-adjusted outcome.
The board can then compare trajectories rather than “technology spend” with an implied zero-cost status quo.
Decide what the model can support
The calculation may reveal that current operation is materially more expensive than the visible budget. It may also reveal that the platform is only one part of a broader operating problem, or that immediate replacement would cost more than the constraint justifies.
That is useful. A credible model is capable of producing an answer its sponsor did not expect.
If the decision is to retain the platform, convert the analysis into management actions: assign cost owners, address the largest control weakness, reduce a workaround, improve documentation and set a review trigger. If the decision is to modernise, use the same evidence to define scope and benefits. The model should survive into delivery so that claimed savings can be tested.
The Replatform Reckoning sets out a broader financial and delivery approach for platform change. Check any figures, product timelines and assumptions in the guide against current supplier information and your own organisation before using them in a board case.
Making the cost visible does not force a replacement decision. It gives leadership a P&L view that matches how the platform is actually operated, rather than how its invoices happen to be filed.
