MACH Transition Offerings

---

MACH architecture can provide many benefits like fast go-to-market, development team flexibility, and avoiding vendor lock-in, but it's not a silver bullet for every organization. This approach requires a high level of digital maturity within an organization, as well as stable Dev/Ops processes. Our solution architects are experienced in defining the right target architecture for different organizations and their maturity levels. When clients decide on a MACH approach, we help them plan and implement a step-by-step migration.

Digital experience platforms that follow MACH architecture usually implement a headless CMS. Our talents have experience with both implementing headless CMS from scratch, as well as transitioning from a headful to a headless CMS. We are experienced in implementing Contentul, ContentStack, StoryBlok, Sanity, and Strapi, but we are also open to support implementations of any other headless CMS.

Headless e-commerce is for us a standard approach when implementing DXPs because we aim to provide a united look and feel for end users. Our talents have experience with both implementing headless e-commerce from scratch, as well as transitioning from a headful to headless e-commerce. We have experience implementing Commercetools, Adobe Commerce/Magento, and Shopify, but we are also open to support implementations of any other headless e-commerce.

Decoupling the frontend layer is one of the first steps towards a target MACH architecture. Frontend applications should be detached from the backend via a gateway that routes requests. In a MACH architecture, we usually aim to enable more than one frontend solution. We help customers split their frontends, but reuse as many components as possible. Our frontend teams are experienced in developing SPAs and micro-frontends in React/Next.js, Angular, and Vue/Nuxt.

A mid-layer in a MACH architecture is usually an API Gateway or a Backend for Frontend solution, depending on the number of different frontend requirements. Decoupling backend systems from the frontends is key when implementing a MACH solution. This approach enables decoupled development in product teams and much easier future replacement of any backend system. Therefore, avoiding vendor lock-in.

In a MACH architecture, we still need to use legacy backend systems, but we do not aim to heavily customize them. Instead, we develop any customizations and additional business logic in dedicated microservices. Our teams are experienced in developing and deploying scalable microservices written in Java, .NET, and Node.js. However, as we are developers at heart, we don't shy away from other technologies.

Refactoring a heavily customized, existing monolith system is not an easy task, but we have done it before. Our recommended approach is a step-by-step refactoring of the monolith by moving functionality into dedicated microservices. Until a complete migration is done, a router is required to route the traffic between microservices and the old monolith solution.