Answer-first: Migrating from Magento Enterprise to Composable Commerce using a 3-phase Strangler Fig model combined with Go 1.25, Kratos v2, and Dapr Pub/Sub eliminates the $200k/year license fee entirely, splits the domain into 21 DDD bounded contexts, guarantees zero downtime, and prepares the platform for Agentic Commerce.
Welcome to the complete handbook for Composable Commerce Migration — how to surgically dismantle a Magento 2 monolith into a production-grade microservices platform without dropping a single order during the transition, ready for the Agentic Commerce trend (commerce optimized for both human users and AI agents).
About this Series (E-E-A-T & Real-World Practice)
This content is distilled from building a real Composable Commerce Platform — 21 Go microservices plus 2 frontends covering the entire commerce business flow: Browse → Search → Cart → Checkout → Pay → Fulfill → Ship → Return. With more than 17 years of experience building e-commerce systems, author Lê Tuấn Anh delivers a battle-tested handbook that eliminates the Magento license fee down to $0. Every architectural decision in this series is backed by one of our 24 Architecture Decision Records (ADRs).
🎯 Migration Consulting#
Is your team planning to break away from Magento, or evaluating a move to a composable commerce architecture as AI systems reshape e-commerce in 2026?
👉 Book a 1:1 Architecture Consulting Session with Senior Architect Lê Tuấn Anh — 17+ years of experience building enterprise e-commerce platforms in Vietnam and Southeast Asia.
📚 Core Curriculum#
Magento’s EAV schema, integer primary keys, and PHP module coupling make migration especially treacherous. This series gives you a complete 3-phase Strangler Fig playbook:
Part 0: Executive Summary — Why $200K/Year Is a Trap
The true cost of Magento Enterprise, why a composable architecture pays for itself in Year 1, and how to avoid the “Distributed Monolith” pitfall.
Part 1: DDD Bounded Contexts — Decomposing Magento Modules
How to map Magento’s module structure into 21 bounded contexts using Domain-Driven Design.
Part 2: Rush Monorepo — Managing 21 Go Services + 2 Frontends
Why we chose Microsoft Rush over Nx/Turborepo for a monorepo mixing Go + Next.js + React.
Part 3: Golang + Kratos v2 — Deep Dive into the Microservice Framework
How Kratos v2 handles transport, dependency injection, and the common library model.
Part 4: Internal gRPC Architecture + REST Gateway
Service-to-service communication over gRPC, with REST exposed via gRPC-Gateway.
Part 5: EAV Schema Migration — Magento’s Biggest Trap
Untangling catalog_product_entity_varchar and mapping integer identifiers → UUIDs.
Part 6: Phase 1 — Strangler Fig: Read-Only Cutover + CDC
Deploying Go services as read-only, consuming CDC from Magento’s MySQL.
Part 7: Phase 2 — Dual-Write: Dapr PubSub + Feature Flags
Enabling write APIs, synchronized through Dapr PubSub + Transactional Outbox.
Part 8: Phase 3 — Full Cutover: Zero Downtime + GitOps
Progressively shifting traffic, moving Magento to hot-standby.
Part 9: Transactional Outbox + Saga Pattern Across Services
How the Checkout → Order → Payment → Warehouse saga flow operates.
Part 10: ADR Walkthrough — 24 Architecture Decisions Explained
Every major decision — Dapr vs Kafka, database-per-service, gRPC vs REST.
| Capability | Magento Enterprise | This Platform (2026 Standard) |
|---|
| License cost | $125,000–$200,000/year | $0 |
| VNPay / MoMo payments | Third-party plugins | Native integration with circuit breakers |
| Flash-sale capacity | Scale the entire monolith 10x | Scale only Order + Payment services |
| Agentic AI & LLMs | Hard to integrate, complex schema | API-first, citation-ready for AI |
| Data ownership | Vendor-hosted (locked in) | Self-hosted, 100% full control |
🧭 Where Should You Start?#
❓ Frequently Asked Questions (FAQ)#
Does this series assume I am running Magento 2?#
Yes. These migration guides target Magento 2.x. The EAV schema, integer primary keys, and module dependency model are all Magento 2 specifics. If you are on Magento 1, the DDD and Golang patterns still apply, but the SQL extraction queries will differ.
The Composable Commerce platform runs on Go 1.25 with Kratos v2 (go-kratos). All 21 services share a common common library to standardize outbox processing, idempotency, health checks, and configuration management.
Yes. The 3-phase Strangler Fig approach is purpose-built for zero downtime. Phase 1 routes only read traffic to the microservices while writes still go to Magento. Phase 2 introduces dual-write mode with feature flags. Phase 3 progressively shifts traffic to the new platform.
Series Hub | Next Chapter: Part 1: Decomposing Magento into 21 Services with DDD →
Answer-first: Migrating from a monolithic Magento deployment to a Composable Commerce platform with 21 Go microservices eliminates the $200k/year license fee entirely, boosts flash-sale capacity by 10x, and removes the risk of single-vendor lock-in.
Answer-first: Start with a Modular Monolith mindset, then progressively shift to Composable Commerce built on 21 Go microservices, Kratos v2, and Dapr PubSub. This is the definitive answer to replacing Magento Enterprise. It delivers extreme commerce capability (multi-warehouse, payment sagas, real-time search) at a license cost of $0, while also meeting the API-first requirements of Agentic Commerce in the 2026 AI ecosystem.
...
← Previous Chapter: Part 0: Avoiding the $200K/Year Magento Trap | Series Hub | Next Chapter: Part 2: Rush Monorepo for 21 Go & Next.js Apps →
Answer-first: The number of microservices you need is decided by your team structure, your scaling profile, and the boundaries of your business invariants; applying DDD carves 240 Magento modules into 21 independent bounded contexts (such as separating Checkout from Order, and Pricing from Promotion).
Answer-first: The number of services you need is determined by your team structure, your scaling profile, and the boundaries of your business invariants — not by cookie-cutter formulas. In the 2026 e-commerce environment, with the shift toward Agentic Commerce and Composable APIs, establishing clear boundaries becomes even more critical. The platform in this series uses 21 services to serve 10,000+ orders per day.
...
← Previous Chapter: Part 1: Decomposing Magento into 21 Services with DDD | Series Hub | Next Chapter: Part 3: Go + Kratos v2 Framework Deep Dive →
Answer-first: Governing a polyglot monorepo (21 Go microservices and 2 Next.js frontends) with Microsoft Rush delivers strict dependency control, incremental builds, and automatic generation of TypeScript SDKs from proto files — all without version conflicts.
When you own 21 Go microservices and 2 frontend applications, the first infrastructure question is not Kubernetes or CI/CD — it is how do you manage the source code itself?
...
← Previous Chapter: Part 2: Rush Monorepo for 21 Go & Next.js Apps | Series Hub | Next Chapter: Part 4: gRPC Internal + REST Gateway →
Answer-first: The enterprise-grade Go microservice architecture on this platform is built on Kratos v2 with a strict 5-layer model, Google Wire dependency injection, parallel HTTP/REST and gRPC transports, and a shared library that standardizes logging and middleware.
For engineers coming over from Magento PHP, the shift to Go microservices is not just a change of programming language — it is a fundamentally different way of organizing code. Magento has controllers, models, blocks, helpers, and plugins. Go with Kratos v3 (fully optimized for Go 1.25) has exactly 5 layers, each with a crisply defined responsibility.
...
← Previous Chapter: Part 3: Go + Kratos v2 Framework Deep Dive | Series Hub | Next Chapter: Part 5: Migrating the Magento EAV Schema →
Answer-first: Every API in the Composable Commerce system starts from a Protocol Buffers (.proto) contract, using gRPC for high-speed internal communication between services and gRPC-Gateway to automatically expose JSON REST endpoints for Web and Mobile applications.
Every public-facing API in the Composable Commerce platform starts from a .proto file. The code — including the gRPC handler functions written in Go, the TypeScript SDK, the HTTP routes, request validation, and the error codes — is all automatically generated from that contract. This article documents the conventions behind the scenes that keep the whole system running smoothly.
...
← Previous Chapter: Part 4: gRPC Internal + REST Gateway | Series Hub | Next Chapter: Part 6: Phase 1 — Strangler Fig Read-Only →
Answer-first: Escaping Magento’s complex Entity-Attribute-Value (EAV) structure requires extracting data through dynamic pivot SQL statements, mapping integer IDs to UUIDs, and restructuring into a normalized relational schema in PostgreSQL to optimize query performance.
The EAV schema is the reason most Magento migration projects fail.
From the outside, it looks easy to handle: product data is shredded across catalog_product_entity, catalog_product_entity_varchar, catalog_product_entity_int, catalog_product_entity_decimal, catalog_product_entity_datetime, and catalog_product_entity_text. Six tables — write a simple ETL job, get it done over a weekend.
...
← Previous Chapter: Part 5: Migrating the Magento EAV Schema | Series Table of Contents | Next Chapter: Part 7: Phase 2 — Dual-Write with Dapr PubSub →
Answer-first: Phase 1 of the Strangler Fig model migrates only the read/query path (Catalog, Search) to Go microservices, using Change Data Capture (Debezium CDC) to sync data from Magento’s MySQL in near real time without disrupting the business write path.
Phase 1 is the safest stage of the entire migration — and that is by design. No write operation ever touches the new microservice system. Magento remains the single source of truth for every data modification. The only thing Phase 1 has to prove is that your pile of microservices can serve read operations faster and more reliably than Magento.
...
← Previous Chapter: Part 6: Phase 1 — Strangler Fig Read-Only | Series Table of Contents | Next Chapter: Part 8: Phase 3 — Full Cutover Zero Downtime →
Answer-first: Phase 2 enables write APIs on the Go microservice system alongside Magento thanks to asynchronous Dual-Write via Dapr Pub/Sub and the Transactional Outbox, with feature flags and automatic data conflict resolution.
In Phase 1, both systems existed side by side but only one of them was allowed to write data: Magento. In Phase 2, both systems write at the same time. This is the most technically complex stage — and the place where most migration projects corrupt their own data if they do not have a crystal-clear conflict resolution strategy prepared up front.
...
← Previous Chapter: Part 7: Phase 2 — Dual-Write Dapr PubSub | Series Hub | Next Chapter: Part 9: Transactional Outbox & Saga Pattern →
Answer-first: Phase 3 completes the migration: 100% of checkout and order traffic is routed to the Go microservices, Magento is kept on a 30-day hot standby for instant rollback, and deployments are fully automated through ArgoCD GitOps.
Phase 3 is the finale: 100% of traffic moves over to the microservice system, Magento formally steps back into the role of a passive archive, and the entire platform runs on the Go microservices through a GitOps workflow. There will be no trace of PHP left in any critical request path. And it also puts an end to the days of paying Magento license renewal fees.
...
← Previous Chapter: Part 8: Phase 3 — Full Cutover Zero Downtime | Series Hub | Next Chapter: Part 10: 24 Architecture Decisions (ADRs) →
Answer-first: Handle distributed transactions when a customer places an order by combining the Transactional Outbox pattern in PostgreSQL with Saga Choreography over Dapr Pub/Sub, guaranteeing eventual consistency across Cart, Order, Payment, and Fulfillment.
When a customer hits the order button on the Composable Commerce platform, up to 7 events must fire in sequence across 4 fully independent services: Order created → Payment authorized → Stock reserved → Fulfillment triggered → Notification sent → Loyalty points awarded → Shipping label generated. Any single link in this chain can snap. The network can drop. The database can crash. A third-party payment gateway can time out.
...
← Previous Chapter: Part 9: Transactional Outbox & Saga Pattern | Series Hub
Answer-first: A recap of the 24 Architecture Decision Records (ADRs) distilled from a real-world migration project: why Dapr was chosen over Kafka for Pub/Sub, database-per-service, Wire dependency injection, and the zero-downtime cutover strategy.
21 services. 24 decisions. Three and a half months of weighing options, all carefully recorded in Architecture Decision Records (ADRs).
An ADR is a short, tidy document that answers one question decisively: “Why did we commit to option X when options Y and Z looked just as good?” Without ADRs, all architectural knowledge lives fragile and undocumented in engineers’ heads. The day one of them resigns, that knowledge walks out the door with them — and the new team taking over will end up dismantling and rebuilding a component in exactly the same way the previous team once eagerly tried and rejected.
...