Most composable commerce re-platforms don't fail. They stall.
The distinction matters. A failed project gets shut down, post-mortemed, and learned from. A stalled project lingers. The programme is still running. The teams are still staffed. Money is still being spent. But the thing that was supposed to ship in nine months is now on month fourteen, the scope has shifted twice, and nobody can clearly articulate what “done” looks like for the business — only what “done” looks like for the technology.
I've led these programmes from both sides: as the technical lead building the platform, and as the architect defining the target state. I've seen what stalls them. It's almost never the technology. Composable platforms are mature enough. The tooling works. The vendors are capable. What stalls a re-platform is the gap between the architecture decision and the organisational reality of executing it with 30 to 80 engineers, existing integrations, and a business that can't afford to stop selling while you rebuild underneath it.
This article is about the failure modes I've seen repeatedly — and the structural decisions that prevent them.
What stalling looks like from inside
From the outside, a stalled migration looks like missed deadlines. From the inside, it feels different. It feels like every decision requires a meeting. Teams are building features but nobody's sure if they're building them in the right order. The integration layer keeps growing because the boundaries between services weren't defined clearly enough. The business is asking when they'll see value, and engineering is answering in technical milestones that don't map to anything commercial.
The backlog is full. People are busy. But the programme has lost its centre of gravity. There's activity without convergence.
What I've learned is that this almost always traces back to three structural problems — and all three are solvable, but only if you address them before the programme gets momentum. Once a large team is moving, changing direction is expensive. The decisions that prevent stalling are the ones you make in the first eight weeks, not the ones you make at month six when things feel wrong.
Nobody agreed on what “done” means
This is the most common failure mode, and the most damaging. A composable commerce re-platform can mean very different things to different stakeholders. To the CTO, “done” might mean the legacy monolith is decommissioned and the new architecture is fully event-driven. To the Head of eCommerce, “done” means the customer experience is at least as good as what they have today. To the CFO, “done” means the programme stops consuming capital and starts delivering return.
These aren't conflicting goals, but they produce conflicting priorities if nobody reconciles them. The CTO wants to build the architecture properly, which takes longer. The Head of eCommerce wants to migrate the highest-traffic journeys first, because that's where the customer impact is. The CFO wants to see the first phase in production generating revenue before funding the second.
“Should we build the custom pricing engine now or later?” is never really a technical question. It's a business sequencing question that nobody has explicitly answered, so the engineering team is left to infer the answer from incomplete context.
What prevents this: a definition of “done” that's expressed in business outcomes, not technical milestones. Not “we've migrated the product catalogue to commercetools” but “customers can browse and purchase through the new platform with no degradation in conversion rate.” The technical milestones sit underneath that, but the programme is measured against what the business cares about. When a sequencing conflict arises — and it will — there's a shared reference point for resolving it.
This sounds obvious. In practice, it requires forcing a conversation that most organisations skip because it feels premature. You're asking a CTO and a Head of eCommerce to agree on sequencing before the architecture is fully defined. That's uncomfortable. It's also the single highest-leverage thing you can do in the first month.
The domain boundaries were drawn wrong
Composable commerce is, at its core, a domain decomposition problem. You're taking a monolith that handles everything — catalogue, pricing, inventory, cart, checkout, order management, fulfilment, customer accounts, promotions — and splitting it into bounded services that can be developed, deployed, and evolved independently.
The question isn't whether to decompose. The question is where to draw the lines.
This is where I see the second failure mode. Teams draw boundaries based on the vendor landscape rather than the business domain. They look at commercetools and see “products,” “carts,” “orders,” and “customers” and assume those are the right service boundaries for their organisation. Sometimes they are. Often, they're not — because the way your business thinks about customers, or pricing, or fulfilment doesn't map cleanly onto how any vendor models those concepts.
A B2B organisation with complex account hierarchies, negotiated pricing, and approval workflows has a fundamentally different “customer” domain than a B2C retailer. A business that sells both physical products and digital subscriptions has a fundamentally different “order” domain than one that sells only physical goods. When you let the vendor model define your domain boundaries, you end up building translation layers — adapters that reconcile what the vendor thinks a “customer” is with what your business actually means by it. Those translation layers start small. They grow. They become the most complex, least understood part of the system. And they're the primary source of the integration friction that slows everything down.
What prevents this: domain modelling before vendor selection, or at least before architecture definition. Map how your business actually works — its entities, its processes, its invariants — and then figure out how the vendor capabilities map onto that reality. The boundaries should follow business language, not vendor language. When a service boundary aligns with how the business thinks and operates, the teams on either side of that boundary can work autonomously. When it doesn't, every feature requires cross-team coordination, and you've recreated the coupling of the monolith in a distributed system.
I've seen teams skip this step because it feels abstract compared to the urgency of “we need to start building.” Six months later, those same teams are spending 40% of their capacity on integration work that exists only because the boundaries were wrong.
The sequencing ignores business risk
A composable re-platform is a multi-phase programme. You can't migrate everything at once — the risk is too high and the teams can't execute it. So you sequence: some capabilities migrate first, some later, and during the transition period, the old and new systems run in parallel with some form of integration between them.
The sequencing decision is where the third failure mode lives. Most teams sequence based on technical dependencies — “we need the product catalogue before we can build the cart, and we need the cart before checkout.” That logic is sound from an engineering perspective. It's often wrong from a business perspective.
Technical sequencing optimises for architectural cleanliness. Business sequencing optimises for value delivery and risk reduction. These aren't always the same thing. A technically clean sequence might have you building foundational services for six months before the business sees any value. A business-aligned sequence might mean launching a thin slice of the new platform — one market, one product line, one customer segment — to prove the architecture works in production before committing the full migration.
Budgets get questioned. Scope gets cut. Timelines get compressed. And the team, which was already working hard, is now working under pressure that makes good architectural decisions harder.
What prevents this: sequencing that balances technical dependencies with business value milestones. This means identifying the thinnest possible vertical slice — a complete customer journey through the new stack, even if it only covers a fraction of the business — and making that the first delivery milestone. It proves the architecture in production, gives the business something tangible to evaluate, and builds the organisational confidence to fund the next phase.
In practice, this often means accepting some temporary architectural compromise. The first slice might need a bridge to the legacy system that you'd rather not build. The data flow might not be as clean as the target state. That's fine. The goal of the first phase isn't architectural purity. It's proof of viability — evidence that the new platform can handle real traffic, real transactions, and real operations. Once you have that, the conversation about the next phase is grounded in evidence rather than projections.
The vendor problem nobody talks about
Everyone entering a composable migration is overwhelmed by the vendor landscape. MACH, headless, API-first, composable — these terms describe principles, not solutions. The actual decisions — which commerce engine, which CMS, which search, which OMS — are consequential and hard to reverse.
But the vendor problem that stalls programmes isn't making the wrong choice. It's making the vendor decision too central to the programme.
I've seen teams spend four to six months on vendor evaluation before writing a line of code. By the time they start building, the programme has consumed half its runway on selection and procurement. Worse, the vendor evaluation often drives the architecture rather than the other way around. The team evaluates vendors, picks one, and then designs the architecture around its capabilities and constraints. That's backwards.
Domain boundaries, integration contracts, data ownership, eventing patterns — these are decisions that should be stable regardless of which vendor sits behind a given capability. If you get the architecture right, swapping a vendor is a bounded problem. If you get it wrong, you're locked in whether the contract says so or not.
The practical implication: run vendor evaluation in parallel with domain modelling and architecture definition, not before it. Let the architecture tell you what questions to ask vendors, not the other way around. And resist the temptation to let a vendor's reference architecture become your target architecture. Their reference architecture is optimised for showcasing their product. Your architecture needs to be optimised for your business, your teams, and your constraints.
What actually prevents the stall
The failure modes above are structural, not technical. They're solved by decisions, not tools. The decisions that matter most happen before the programme has momentum — in the first six to eight weeks, when the cost of changing direction is still low.
Define “done” in business language. Force the conversation between technical leadership, commercial leadership, and finance before the programme starts. Agree on what the business will measure, not just what engineering will deliver. Revisit it quarterly — not because people are acting in bad faith, but because the business context changes, and the definition of “done” needs to change with it.
Model the domain before you design the architecture. Understand how your business actually works — its entities, its processes, its edge cases — and draw service boundaries that reflect that reality. This is a few weeks of focused work with the right people in the room. It's the highest-leverage activity in the entire programme.
Sequence for confidence, not cleanliness. Identify the thinnest vertical slice that proves the architecture in production and delivers visible business value. Protect that milestone. Everything downstream depends on the organisational confidence it creates.
Let the architecture lead the vendor conversation. Evaluate vendors against your domain model and integration requirements, not the other way around. If you can't articulate what you need from a vendor without referencing their product, the architecture isn't defined well enough.
The real risk
Composable commerce is the right direction for most enterprise retailers and B2B organisations that have outgrown their monolith. The technology is proven. The patterns are understood. The vendor ecosystem is mature enough.
The risk isn't that composable doesn't work. The risk is that the migration programme stalls because the organisational decisions weren't made with the same rigour as the technical ones.
There's also an upside that most re-platform business cases undervalue. A composable architecture with clean domain boundaries, typed contracts, and observable operations isn't just easier to maintain — it's easier to extend in ways you can't predict today. AI-driven commerce is arriving faster than most roadmaps account for. Agentic workflows that automate order operations, personalise customer journeys, or orchestrate fulfilment depend on the same architectural qualities that make a composable platform work well for humans: clear boundaries, reliable contracts, and data flows you can reason about. The re-platform you're doing now is also the AI enablement work you'd have to do later. That's not the reason to do it — but it's a significant second-order benefit of doing it properly.
Sequencing, domain boundaries, and the definition of “done” are architecture decisions — they just don't look like architecture decisions to most people.
That distinction sounds semantic. In practice, it's the difference between a programme that delivers and one that lingers.