Platform selection risk is real. Here’s what reduces it.

There’s a specific energy in the room when someone says “platform evaluation.” I’ve watched it happen at two enterprise beauty retailers, at a streaming platform, at a ticketing company. Someone mentions the possibility of moving the CMS. A few people exchange looks. The energy shifts. The risk feels total: pick the wrong platform and you’re locked in for a decade, the migration will cost millions, the team will be unhappy, the executives will ask questions you can’t answer.

I’ve run platform evaluations from both ends. First as a practitioner who inherited whatever had been chosen before I arrived, then as a PM who owned the process outright: the briefing documents, the vendor demos, the scoring matrices, the stakeholder alignment, the procurement commitment. I know what the shiver is about.

But I also know what relieves it. And it’s not a better spreadsheet.

What the risk actually is

The fear isn’t usually about picking the wrong features. At the level where these decisions get made, most enterprise CMS platforms can do most of what you need. The fear is about lock-in: the deeper you embed a platform into your architecture, the more expensive it is to leave. You’re not just choosing a tool. You’re choosing the shape of your content model, your data contracts, your editorial workflows, and your team’s operational patterns for the next several years.

That is a real risk. But the thing most platform evaluations get wrong is treating it as a selection risk rather than an architecture risk. The question isn’t only “did we pick the right platform?” It’s “did we build the system in a way that allows us to be wrong about which platform we picked?”

What actually relieves it

The most consistent thing I’ve seen reduce the shiver in a room is a working POC that demonstrates the same content model on two different headless tools. Not a feature comparison matrix. Not a vendor pitch deck. A build.

When developers can see that the data architecture holds across both platforms, the platform decision becomes what it actually is: important, but not existential. The risk moves from “we’re betting the organisation on this” to “we’re choosing the right tool for this phase, and the architecture will survive if that turns out to be wrong.”

This only works if the architecture was designed with portability in mind from the start. And that requires composable thinking before the platform is even selected.

The “permanent” properties

Composability, modularity, reusability. These are properties of a system, not of a platform. A content model expressed in atomic concepts rather than CMS-specific constructs, a component library that accepts any data source, a frontend that talks to APIs rather than embedding platform opinions: these things don’t lock you in.

The specific platform you choose will come and go. Adobe AEM has been “the right enterprise choice” for as long as I’ve been in this industry. So has every platform that got replaced by it. The one constant across fifteen years of these decisions is that the teams that survived transitions well had been thinking in terms of abstractions, not implementations.

“Headless” is the current form of this instinct. The composable architecture argument isn’t new. It’s the same argument that drove teams toward decoupled Drupal before Contentful existed. The vocabulary has evolved. The underlying risk calculus hasn’t.

The same risk is arriving again, this time as AI content retrieval. As answer engines (AEO) and large language models (LLMs) become primary surfaces for information discovery, the same architecture question resurfaces: is your content model expressed in structured, canonical, attributable units, or is it a blob — unstructured, platform-bound, and invisible to any retrieval system that doesn’t already know where to look? The teams that made the portability argument for headless already have most of the answer. The atomic content model they built for CMS independence performs well in AI-native retrieval for the same underlying reasons. The specific planning implications for AI-era content portability are worth their own treatment; a follow-up is in the works.

The proof

Earlier this year I ran a POC against this claim directly. The Sugartown monorepo was built with an explicit architectural promise: migrating from Sanity to another headless CMS would be “straightforward and contained, requiring changes primarily within a bounded content adapter layer.” The documentation said so. But it had never been tested in practice. So we tested it. The full build and its findings are in the companion node.

The short version: the claim held. The components rendered identically on Contentful and Sanity. The content model transferred. The two gaps the POC exposed were in the packaging layer, not the content model, and both were immediately diagnosable.

The result wasn’t “composable architecture is perfect.” It was “composable architecture behaves exactly as promised when you test it, and the gaps it exposes are mechanical rather than strategic.” That is the difference between lock-in and confidence.

If you’re sitting in a platform evaluation right now, or about to be, the thing I’d push for isn’t a better scoring matrix. It’s a small POC that forces your content model to stand up in a second context. Not to prove you picked the right platform. To prove the architecture can survive the discovery that you picked the wrong one.

That’s the only thing that actually makes the shiver go away.

Next in the series

POC: Platform-agnostic by design — Contentful + Vercel vendor evaluation alongside the existing Sanity + Netlify stack. The architecture claim, tested in practice.