Migration to the MACH world. One layer at a time.
You don't need a two-year replatforming to get out of a legacy system. You need the right first layer and someone who masters the transitions.
commercetools recently started selling individual modules instead of only the full platform: Core Commerce for cart, checkout and order management, Product Catalog for the product model, pricing, inventory and search. Both connect to existing systems. That is remarkable, because a vendor is now saying out loud what we have recommended for years. Modernization is no longer an all-or-nothing decision, but a sequence.
Two paths, one goal
Big-bang replatforming
- 18 to 30 months to the first live effect
- One budget, one approval, one board meeting
- All risks hit at once on go-live day
- The legacy system is maintained until the very end
- The benefit arrives at the end
- One wrong move costs the entire project
Step-by-step migration
- First live effect after one quarter
- Budget per layer, approval at department level
- Each layer goes live and rolls back on its own
- The legacy system shrinks with every step
- The benefit arrives along the way
- One wrong move costs a single layer
MACH Alliance
We are members, not spectators
We are a MACH Alliance Certified Member 2026. That is not an award for the shelf, but a commitment to four principles: Microservices, API-first, Cloud-native, Headless. These four decide whether, in five years, you can still replace whatever is slowing you down.
In practice that means we build no dependency on us. Every layer we modernize for you stays replaceable. Even against us.
Where you start
The sequence decides the outcome. These three layers are the cleanest to peel off one at a time.
Product and search layer
Product data, pricing, inventory and search move first. The legacy system keeps cart and checkout. The effect shows quickly, because assortment and search sit right on revenue.
Transaction layer
Cart, checkout and order management out of the monolith. The harder cut, but the one that truly solves scaling problems on peak days.
Process orchestration
In B2B the pain rarely sits in the shop, but in approvals, pricing logic and order routing. This layer pays off first when your business is more complex than your frontend.
Which platform fits your starting point
We are partners of these platforms. Which one fits you depends not on our preference, but on your starting point.
commercetools
Enterprise volume and peak load, large B2C and B2B assortments. The modules can be used individually, the path to the full platform stays open. Our longest MACH partnership, Heart Partner since 2016, with five platforms delivered.
Emporix
B2B with complex pricing and approval structures. Process orchestration instead of pure transaction, with AI-driven, autonomous flows along the order path. Strong when the shop is not the problem, but the process behind it.
VTEX
MACH-first and cloud-native. Unified commerce for B2B and B2C on one platform, when a single system needs to carry several sales channels.
Evidence
No declarations of intent, but what we have built and where we let ourselves be audited.
What you are probably asking now
For a while both really do run. The difference is what you pay for. With a big bang you pay two years for a promise. Step by step you pay for a layer that works after a few months, and you finance the next step from the effect of the previous one. We plan the parallel-operation phase from the start, instead of hiding it.
At the point that costs you money today. If search breaks down in the assortment, it is the product layer. If checkout falls over on peak days, it is the transaction layer. If you are stuck in approval loops, it is the process layer. The Platform Audit makes exactly this assignment, before anyone talks about technology.
A target picture with an end date and one rule: every layer we peel off has a defined handover point to the legacy system that disappears again. We document per step what gets switched off afterwards. Without that switch-off list it is not a migration, but an extension.
Yes, and that is the normal case. The modules connect via APIs, not via a platform kinship. We have worked with Shopware, Magento and OXID and know where the interfaces of these systems hold up and where they do not.
Not the modules, but the seams. Keeping product data in sync, running orders across two systems, holding identity and session together, keeping the search index current, deciding pricing logic in one place, booking returns cleanly. That is where the weeks go, and that is where it is decided whether it works. So we talk about it early, not mid-project.
No, and that is part of the architecture. MACH means replaceable building blocks, and that applies to the service provider too. We document so that another team can carry on. If you keep us, it is because the result is right.
Our MACH ecosystem
First the sequence, then the technology
In the Platform Audit we look at your legacy system and tell you which layer comes first and what the first step costs. Without a platform recommendation in our pocket that was fixed before the conversation.