Migrating from monolithic applications to a microservices-based and composable architecture can seem daunting. However, the strangler pattern provides a practical, low-risk approach that enables businesses to transition incrementally while delivering faster ROI. Discover how the strangler pattern ensures a gradual migration to your composable commerce architecture with minimum disruption and faster time to market.
The inspiration behind the strangler pattern
When software developer Martin Fowler visited Australia’s rainforests, he was captivated by Queensland’s colossal strangler figs. These trees start growing in the upper branches of a host tree, gradually working their way down until they take root in the soil — eventually choking and replacing the host tree. Fowler saw a compelling metaphor for software migration: Rather than replacing a system all at once, it’s easier to build a new system around the old one, gradually replacing functionalities until the legacy system is phased out.
This process, now known as the strangler pattern, has become a widely adopted strategy for migrating from monolithic applications to microservices in digital commerce. The gradual transition helps mitigate risks and ensures businesses can start leveraging the benefits of new technology without long waiting periods.
Big bang vs. strangler pattern: Which is better?
There are two migration options to transition from a monolithic platform to a composable stack: Big bang (also known as “Greenfield”) and the strangler pattern (also known as “phased migration”). Here’s an overview:
When replatforming from one (monolithic) system to another in the past decades, businesses had no other choice but to use a “big bang” (also known as a “greenfield”) approach. Companies using this traditional process would rebuild the complete commerce architecture and release it entirely in one operation. In short, the platform would remain in place until the big bang event to switch to the new infrastructure.
✅ Developers get a clean slate and avoid dealing with legacy code.
✅ A single cut-off point simplifies transition planning.
✅ No need to decouple the existing system to implement a new one.
❌ High risk: Any failure could require a full rollback.
❌ Significant upfront cost and a long wait for ROI, as well as thorough planning.
❌ Potential disruptions to business operations.
The strangler approach breaks the legacy commerce platform into small pieces as microservices and slowly replaces single components incrementally. Over time, the monolith will start to “suffocate” and eventually disappear. Using this approach, tech teams can monitor progress easily and control the migration every step of the way with smaller-scale deliverables. If something goes wrong, it’s easier to pull back any changes without affecting the entire infrastructure.
✅Control every step of the migration process while minimizing disruptions and downtime.
✅ Minimizes risk by allowing incremental changes.
✅ Allows for experimentation.
✅ Enables faster ROI with early adoption of new components.
✅ Easier rollback in case of issues — only the affected part is impacted.
❌ Requires running two systems in parallel for some time.
❌ The entire migration may take longer due to its gradual approach.
What’s the best approach for your business?
It’s entirely up to you. When deciding on an approach, take into account:
What’s the strangler pattern and when to choose it?
The strangler pattern is a popular migration approach that gradually transitions your monolithic application into microservices, replacing functionalities piece by piece. As you already learned, the strangler pattern has become a popular migration method in eCommerce because it reduces the chances of system disruptions.
This incremental approach enables you to break down large tasks and projects into small, bite-sized pieces, reducing complexity with an automated CI/CD (continuous integration and continuous delivery) pipeline for each microservice. That way, businesses can reap the benefits of new applications without waiting until the entire solution is complete, optimizing time to value for your composable implementation.
commercetools’ customers have repeatedly chosen the strangler pattern instead of the big bang approach when migrating to composable commerce. This is because composability's microservices-based and API-first nature enables the incremental migration of components rather than a “big bang” traditional process, as it reduces risk and sets up a virtuous cycle of release-win-learn-iterate. Also, you can create minimum viable products (MVPs) to establish a first base for what the rest of your commerce solution will look like — and upgrade over time.
In addition, waiting 12 to 24 months for a sizable replatforming project to kick in doesn’t make sense in an environment of constant change. That’s why C-level executives, business executives and other internal stakeholders usually agree that transitioning step by step diminishes the risks associated with large replatforming projects while reaping the benefits of a more flexible and agile system in the short to medium term.
Migrating to a composable architecture using the strangler pattern involves three key phases:
1. Transform existing services
Start by creating new versions of specific services and testing them alongside your legacy system. Select a function or component with high business impact but low technical risk as your starting point.
2. Coexist with legacy systems
Your monolithic application and new microservices will run side by side for a period. This phase ensures a smooth transition and reduces disruptions while validating that new components are working as expected.
3. Eliminate the old system
Once all components have been successfully migrated and validated, the legacy system can be fully retired. At this stage, your new architecture should be fully operational, leveraging independent microservices with CI/CD pipelines for continuous improvements.
When each of your applications has migrated away from the monolith, each microservice has its own data store and CI/CD pipeline.
How Moonpig implemented composable commerce using the strangler pattern
When the personalized greeting cards and gifts company Moonpig decided to adopt a composable approach, it chose to break down its homegrown monolithic platform into bite-sized, more easily manageable components.
As a result, the retailer was able to identify the functions that genuinely distinguish them from competitors (and could be built in-house) and those that don’t (which could be bought from a best-of-breed provider).
Following this path, Moonpig customized its tech stack with a mix of in-house-built applications and best-of-breed solutions, including commercetools Composable Commerce for B2C, Adyen for payments and Contentful for CMS.
Why the strangler pattern is ideal for B2B organizations?
B2B commerce often involves complex pricing models, contract negotiations, bulk ordering and long-term customer relationships. Migrating a B2B platform to a composable commerce architecture using the strangler pattern helps businesses tackle these complexities step by step. Here’s why the strangler pattern is particularly beneficial for B2B organizations:
Minimized business disruptions: B2B transactions are high-value and long-term, meaning system downtimes can severely impact revenue. The strangler pattern enables a gradual transition that keeps operations running smoothly.
Incremental modernization: B2B organizations often rely on legacy systems with deep customizations. As the strangler pattern allows businesses to replace components one at a time, B2B firms can reduce risks associated with replacing an entire infrastructure at once.
Faster adoption of digital commerce: With B2B buyers expecting B2C-like digital experiences, manufacturers, wholesalers and distributors can start implementing self-service portals, automated reordering and AI-driven pricing without waiting for a full replatforming project.
Integration with ERP and supply chain systems: B2B commerce platforms must seamlessly integrate with ERP, CRM and supply chain systems. A gradual migration ensures that these critical integrations remain intact while new components are introduced.
How ACE Southern ditched the complexity of monolithic eCommerce with a phased migration
ACE Southern a Henry Schein company specialized in dental surgery products, migrated from Adobe Commerce with a gradual implementation approach. First, the manufacturer signed up for the commercetools Free Trial to create a proof of concept (POC) to start a composable implementation.
What’s the big bang approach and when to choose it?
The big bang approach is a more traditional method of system migrations designed to make the switch from the current system to a new one at a single point in time; the go-live. While we usually recommend the strangler pattern, the big bang approach may be beneficial when migrating from notoriously difficult systems to break down into smaller pieces, such as Salesforce or SAP Commerce Cloud. If your company falls into this case, we recommend building everything from scratch and then proceeding with the switchover.
A common reason to consider a big bang migration is where an initiative cannot be delivered reasonably in your existing stack. An example would be a new product category, pricing strategy, bundling capability or another initiative that would be wasteful to build in existing systems being replaced. Pairing a soft launch of those new capabilities with a discrete set of customers to finish “testing” can increase customer satisfaction and mitigate business concerns about a big bang approach.
Why PLUS Supermarkets chose a big bang migration approach
When the leading Dutch grocery chain PLUS Supermarkets migrated to commercetools, the company decided to broaden the scope of its digital transformation process to rethink customer journeys, incorporate innovative features and build an entirely new ecosystem without dependencies on the legacy platform as a way to deliver outstanding shopping experiences.
Due to this expanded scope, the company opted for a “big bang” migration, flawlessly executed within a 24-hour window. From building the entire composable ecosystem to go live, PLUS completed its migration within the planned three-year timeline.
How to get started with commercetools Composable Commerce
Here are three possible migration routes using the strangler pattern:
The easiest way to migrate to a composable architecture is to start with transitioning the product catalog or PIM — even more so if you’re facing performance issues with a difficult-to-navigate product catalog hurting your bottom line. In this scenario, your product catalog/PIM on commercetools can connect via APIs with checkout and other functionalities on the monolithic platform without data discrepancies.
If you’re having trouble converting first-time customers to contract customers, consider capabilities and site experience which are tailored to that customer base as an initial launch point.
Newer customers are less complex from a buying perspective, but pay more attention to product discovery and search context. Getting those features right for a new customer demographic can yield long-term benefits with repeat buyers and long-time customers.
Say your business has acquired new business units or expanded to a new geography, but these aren’t yet integrated into the system due to the high costs of onboarding onto a monolithic infrastructure or prohibitive/negative ROI for smaller business units to justify such integration. In those cases, it is often easier to start with a composable approach from the get-go as a pilot project.
Front-to-back is a technique used during application migration that starts by decoupling the frontend first and moving to true headless with a frontend solution. After that, you can create the API layer and tackle the backend migration. This gradual transition minimizes risk and downtime, plus provides immediate benefits in terms of customer engagement. This approach is recommended to companies with custom and/or legacy frontend solutions, such as SAP Spartacus.
While implementing checkout as the starting point is usually more complex than a product catalog/PIM, many B2B organizations have taken this route to accelerate time-to-value and ROI. Starting with checkout capabilities means securing the most critical part of the customer journey and building differentiation across all other customer touchpoints.
Regardless of which approach you choose, the strangler pattern allows you to migrate to commercetools at your own pace, test strategies and maximize business benefits along the way.
Migrating to commercetools made easy! Get our guides.
📥 For enterprise retailers and brands: Composable Commerce Migration guide for B2C
📥 For manufacturers, wholesalers and distributors: Composable Commerce Migration Guide for B2B
Manuela Marques Tchoe is a Content Writer at commercetools. She was a Content and Product Marketing Director at conversational commerce provider tyntec. She has written content in partnership with Facebook, Rakuten Viber and other social media platforms.