I spent years building on Magento. It's not fashionable to admit that now — the platform has become something of a punchline in modern development circles. Too heavy. Too slow. Too expensive to maintain.
All of that is true. And yet, I find myself defending Magento more often than I expected. Not as a recommendation, but as a case study in what happens when you actually have to solve hard problems at scale.
What Magento Got Right
Before headless became the default answer, Magento was handling problems that many modern stacks haven't even thought about yet.
Complex pricing logic. Customer groups, tier pricing, catalogue rules, cart rules, tax calculations across jurisdictions. Try implementing that in a "just use Stripe" setup. You'll understand quickly why Magento's pricing engine exists.
Inventory at scale. Multi-warehouse, backorder handling, reserved stock during checkout, stock synchronisation across channels. These aren't edge cases — they're Tuesday for any serious ecommerce operation.
Data integrity under load. Magento's EAV model is often criticised, and fairly. But it was designed to handle flexible product attributes without schema migrations. That flexibility came at a cost, but the problem it solved was real.
The lesson isn't that Magento's solutions were optimal. It's that the problems were legitimate, and modern replacements often ignore them entirely.
What Modern Stacks Forget
I've seen teams migrate from Magento to headless setups with genuine enthusiasm. Nuxt frontend, Stripe for payments, a headless CMS for content. Clean, fast, modern.
Six months later, they're rebuilding half of what Magento gave them out of the box.
Not because headless is wrong. Because they underestimated the complexity that Magento was hiding. Promotional logic. Order management. Customer account synchronisation. Reporting that actually matches the finance team's expectations.
The first version of a headless commerce build is always elegant. The fifth version, after handling edge cases, starts to look suspiciously like the monolith you were trying to escape.
When Magento Still Makes Sense
There are situations where I still recommend Magento — or at least, don't recommend against it:
- Complex B2B with negotiated pricing, quotes, and approval workflows
- Multi-store, multi-currency operations with shared inventory
- Organisations without dedicated development teams who need managed solutions
- Existing Magento installations that are working and don't need to be fashionable
The last point matters more than people admit. Migration has real costs. If your Magento site is stable, performs acceptably, and meets business needs, the case for replatforming is weaker than vendors would like you to believe.
When Headless Wins
That said, headless is the right choice in many scenarios:
- Content-heavy commerce where editorial flexibility matters
- Omnichannel delivery to apps, kiosks, or emerging platforms
- Teams with strong frontend engineering who want control
- Performance-critical applications where every millisecond counts
- Simpler commerce models that don't need Magento's complexity
The key is honest assessment. Not "headless is better" or "Magento is legacy." But: what problems do you actually have, and what are you trading away to solve them?
The Real Lesson
Legacy platforms aren't legacy because they were built wrong. They're legacy because they were built for a different set of constraints, and those constraints have shifted.
But the problems they solved don't disappear just because we use newer tools. They resurface, often in ways we didn't anticipate, and we end up learning the same lessons all over again.
The developers I respect most are the ones who can look at a Magento codebase — or a WordPress site, or a Drupal installation — and understand why it was built that way. Not to replicate it, but to avoid repeating the same mistakes in a shinier package.