Someone puts a paper on your desk. "We should move these apps to Platform X. Here's the cost comparison." You look at it. The numbers show runtime compute. Just runtime compute. No cross-cloud networking for the databases that aren't moving. No dual-running costs while both platforms operate in parallel. No platform consolidation overhead. No FTE expansion across half a dozen teams. No retraining budget. No impact on existing cloud commitments.

Runtime is easy to model. Everything else takes work. That's why most platform cost papers look like this one, and why the real number usually lands somewhere very different.

I spent a couple of months building out the full TCO of a platform migration proposal. The original paper was fine on runtime. Here's what it didn't cover.

Apps move to the new platform, but databases stay where they are – different cloud or in the data center, different network. Every request now crosses a cloud boundary. Cross-cloud interconnect has port costs and per-GB egress on each of those database queries. Hundreds of apps, each making thousands of calls a day, and that egress adds up to hundreds of thousands a year. The existing connectivity to the old platform stays too. Both run in parallel for the duration of the migration, and the original line doesn't shrink until the last app moves off.

Then there are services that duplicate instead of replacing what's already there. Managed cache for stateful apps. A parallel SIEM pipeline that stays parallel forever because your SOC now monitors two clouds. New API management alongside existing API management. Each one adds a line item without cancelling an old one.

People were the most underestimated category. Cloud foundations, network engineering, SecOps, DBA, service management, security architecture – each needs partial to full headcount expansion. Engineers who can operate across multiple cloud providers are harder to find and more expensive than single-cloud specialists, especially in the AU/NZ market. Five to seven new hires in the world of the 2026's shrinking labour budgets.

One-time costs added up fast. Hundreds of apps, each needing container rework, build pipeline migration, performance testing, and validation. Existing platform investment written off. And training – upskilling programmes across multiple teams. This line gets dropped from proposals more often than any other, and it's rarely cheap or fast. Tens of thousands of engineering hours that don't show up on a cloud bill.

Finally, compliance and commercial impact. In a regulated enterprise, shifting workloads between clouds can breach existing commitment minimums. New provider commit required for pricing leverage. Database licensing may double if the estate splits across providers. Then the governance work: regulator notification readiness, evidence collection at expanded scale, concentration risk reviews, substitution arrangement documentation – the most exciting stuff all engineers love.

The original paper had one cost category. The full picture had eleven. Both papers were looking at the same migration.

Most platform cost conversations zoom in on one line - compute, or storage, or a licensing renewal. Optimise it in isolation. What I've been trying to do instead is look at what the whole platform costs and what that cost delivers to the developers who use it.

A developer platform is a combination of services: IDP, container orchestration, compute, networking, security scanning, compliance controls, CI/CD, observability, and the people who keep all of it running. When a developer deploys through a golden path, they consume all of these at once. A unit price per service per month makes that visible.

Compute, storage, pipeline, observability – these attribute to the consuming team through tags. Quality tagging and the number is there.

Security and compliance overhead is separate. That's a regulatory tax. The platform makes it cheaper through economies of scale – one pattern for SIEM pipeline, one set of CPS 234 evidence collection, one security scanning layer shared across every service. The cost exists whether or not the platform does. Separating it out shows what the platform actually charges and makes the regulatory overhead visible for what it is.

The hard part is the platform team itself. The people who build and maintain the golden path, run on-call, ship the roadmap, do integration work. I'm thinking about this as a Team's Share – every consuming team sees a portion of the platform team cost in their unit price. I haven't settled on the division yet. By number of services? Weighted by consumption? Per team flat rate?

Getting this right matters because this is the layer that determines whether the platform reads as a cost centre or as a service worth paying for. And the latter will set it up for long-term success.

Separately, there's a question of how you present unit costs once you have them. Will Larson writes about "second degree attribution" – showing a team their number relative to everyone else. A team spending $100K a month reacts differently when they know they're second out of forty. Why does service A cost three times more than service B? Do we really need this cross-cloud data transfer pattern? Those questions come up when the numbers are visible and comparable.

I don't have a proven model yet. More on this when the numbers survive a finance review after year or two running.