Recognizing zombie commerce platforms before they cost you

Abstract geometric composition representing zombie commerce platforms and platform lock-in risks
Ante PrimoracAnte Primorac
July 24, 2026
7 min read

What we have seen across projects is a pattern that repeats. A merchant picks a commerce platform because every developer knows it and the app ecosystem covers every gap, and commerce platform lock-in feels distant enough to ignore. After a few renewal cycles, the platform makes decisions that serve its own risk profile instead of the merchant’s operations. The merchant discovers the dependency only when a policy change hits their category. By then, leaving is expensive.

Viessmann needed B2B commerce capabilities Shopify could not deliver. TEKLA Fabrics, a Danish fashion brand we have worked with for over five years, built on open-source foundations from the start and avoided the platform lock-in cycle. Between these two endpoints sits a wide middle: merchants who sense the platform is no longer earning their business but cannot quantify what leaving would cost.

This pattern has a name: the zombie company. It describes a business that keeps reporting revenue long after it has lost the ability to earn its position under current market conditions. Commerce platforms share this structure. Revenue comes from contracts signed years ago. Switching costs keep merchants in place. Strategic decline shows up in product decisions long before it shows up in earnings.

The symptoms, from the merchant’s side

The zombie platform does not announce itself. It shows up through the decisions it makes and the ones it stops making.

Risk decisions on your behalf

The clearest signal is when the platform starts making risk decisions on your behalf. Shopify’s decision to ban all electronic nicotine delivery system products is the textbook case. Facing pressure from 25 state attorneys general, the platform banned the entire category globally, including products that were legal in their jurisdictions with compliant setups and age verification. A merchant who did everything right lost their storefront. Not because of anything they did. The platform absorbed regulatory risk by passing it to merchants as a product policy. The zombie signal is not the regulatory pressure. It is the response: a blanket global ban with no compliance framework and no merchant recourse.

Here is what this actually costs you if you get it wrong. A merchant with years of compliant operations, proper verification, and regulated payments wakes up to find their category is gone. Not because the law changed. Because the platform decided the category was not worth the regulatory exposure. The merchant had no seat at the table.

This is characteristic of zombie platforms. When switching costs are high enough, the platform can prioritize its own risk profile without losing the merchant. The merchant shifts from being a customer to serve into a liability to manage.

Fee growth without feature velocity

App store commissions and payment processing fees increase. Features that were once included move to paid tiers. New capabilities arrive as third-party integrations rather than platform improvements, shifting cost and integration burden onto the merchant. The metric to watch is the ratio of platform take rate to core feature velocity. When fees grow across multiple cycles while core improvements stay flat, the zombie pattern is confirmed.

Product direction uncertainty

Adobe acquired Magento in 2018 and rebranded it to Adobe Commerce. Architectural evolution has been limited since, while Adobe’s strategic attention shifted to Experience Platform and AI layers. BigCommerce has been under public-market margin pressure since its 2020 NASDAQ listing, constraining R&D investment in core commerce during a period when the category needed it most. None of these platforms is failing by revenue. All of them are sustained by accumulated advantage (switching costs, app ecosystem dependency, and merchant inertia) rather than by earning new business on their current merits.

Here is what commerce platform lock-in actually costs you

The zombie platform’s strongest defense is not product quality. It is the accumulated cost of leaving.

A mid-market merchant on a locked-in platform has years of theme customization, app configurations, order history, and team familiarity invested. A merchant with 40 custom integrations, three years of order history, and a team of five faces a migration measured in quarters, not sprints. The switching cost is high enough that the platform can degrade its offering before churn moves the needle. Every month builds the trap larger.

The cost of leaving compounds. Commerce platform lock-in is expensive to reverse, but with a partner who has done this before, the cost of building on open-source foundations early is lower than the cost of migrating a locked-in platform later. Our TCO calculator makes this comparison explicit. We have seen this play out both ways, and the gap is wider than most teams forecast.

Breaking out

The alternative is not necessarily another platform you do not control. It can be a stack built on open-source building blocks where you own the business logic, pricing rules, and category policy decisions. There is a spectrum, and the right answer depends on your team’s capacity to own infrastructure.

Platform lock-in is not always bad. A managed platform handles PCI compliance, infrastructure scaling, and security patches so you do not have to. The question is whether those benefits still outweigh the costs given the platform’s trajectory.

Open-source commerce engines like Medusa provide a mature foundation for storefront, checkout, order management, and admin. The difference is that when a regulator targets your category, the decision about how to respond is yours, though you still operate within the constraints of payment processors, hosting, and regional law.

AI-assisted development shortens the foundation phase. Scaffolding a custom checkout flow used to take weeks. That phase is shorter now, as we covered in the real cost of AI-generated code. But owning your stack means owning the problems too: security patches, uptime, the integration layer when a payment provider deprecates an API. You own the hiring pipeline for developers who can maintain it. I am not sure how realistic this is for a smaller team without infrastructure experience. Cheap code does not mean cheap ownership. What changes is that your costs build capability you control rather than paying rent on capability someone else might restrict tomorrow.

The platform exit audit

When you recognize these symptoms in your own stack, the next step is a platform exit audit. It maps every operational dependency: catalog logic, checkout paths, payment configuration, order history, integrations, and admin workflows. Each dependency gets a migration complexity score. The output is not a recommendation to move or stay. It shows what is easy to move, what is hard, and what you would gain by owning your stack.

An audit cannot predict every hidden dependency. Data migrations uncover edge cases the audit misses, and complexity scores are estimates, not guarantees. The value is not precision. It is replacing a vague feeling of being trapped with a map you can act on.

After a platform exit audit, merchants typically land in one of three positions. Some should stay, at least for now. Others choose coexistence, moving one category or one market at a time while the old platform handles the rest. A third group finds that full migration is the cheaper path when measured over three years instead of one.

The cost of leaving compounds every quarter you wait. The audit gives you the numbers before a policy change or a category restriction forces the decision on someone else’s timeline.

Ante Primorac

Ante Primorac
Tech Lead

I develop headless commerce solutions that adapt as brands expand. At Agilo, I directly handle architecture and implementation, guiding teams to make practical technical choices without increasing complexity. My emphasis is on creating durable commerce platforms where performance, maintainability, and clear system design are prioritized from the beginning.