With an influx of composable tools on the market that are easy-to-use, offer prebuilt integrations and components, and are available at a range of price points, it’s easy to debunk the myth that composable is only for large enterprises with deep pockets and advanced engineering teams.
Another major factor making composable a practical option for many companies is that many legacy vendors have been racing to add APIs and modularity to their platforms to support the approach, as the flexibility it offers is tempting more businesses to leave their legacy monoliths . Which means choosing between modern tools and your long-established legacy systems is no longer an all-or-nothing choice .
For example, SAP announced their composable commerce offering in March 2023 and less than a year later a survey of SAP Commerce Cloud users found that 83% were either considering (38%), transitioning to (14)%) or had already adopted (31%) a composable approach. With the main drivers for the move revolving around flexibility, customization, and performance.
What makes the composable approach so flexible is the fundamental idea that teams should be able to “compose” their own stack of best-fit technologies. Businesses no longer have to compromise on a one-size-fits-all set of features, but this also means there isn’t a one-size-fits-all roadmap to transformation.
This guide walks through some typical early steps companies take in a composable commerce migration. With tips on defining goals, selecting vendors, and planning implementation to help get the ball rolling.
1. Gather the requirements
Make the business case
If you’re considering composable you likely already have a list of frustrations caused by your legacy platform. Clearly defining the business value of solving these challenges can help get the buy-in and budget needed to make the move. Such as how a new solution could help:
Reduce risk. Our current platform is reaching end of life (EOL) and would interrupt these critical business processes if it fails.
Lower costs. A composable approach would allow us to more granularly scale services to meet traffic peaks, allowing us to take advantage of autoscaling and significantly reduce hosting costs.
Boost productivity. The majority of teams’ time is spent on tedious tasks, like manual platform upgrades or publishing product pages, and automating these processes would free them up for more valuable work.
Improve customer experience. Our mobile site is slow and the bounce rate is high, a modern architecture could substantially increase performance and conversion rates.
Add revenue. With a solution that lets us rapidly replicate environments, localize content, and set regional prices we could enter these key markets in this time frame.
Enable innovation. After years of customization it feels risky to make even a small change to our platform, and nearly impossible to launch new ideas. A modular architecture would give us the flexibility to quickly adapt to market shifts.
Starting with the business case lets teams align on the key objectives that will drive decisions throughout the transition, and helps figure out the best metrics to track and communicate progress. Here are some basic steps to help you sell the composable transformation idea to the board:
Set up a cross-functional migration team
Finding a core group of advocates from across the business (engineering, design, marketing, merchandising, customer support, finance, etc) can help fast-track decisions, identify potential blockers, work out compromises, and give overall credibility to the plan.
Ideally, the team should be a mix of people who have deep technical knowledge of the existing system, can speak to day-to-day business processes, and are really great communicators that can get peers on board with change.
Take stock of your existing system
To be able to break up a monolith into modular, composable blocks you’ll need a 360° view of how the current system works. This includes:
Data. What data lives in the system and how it’s structured, secured, gathered, accessed, updated, and disposed of.
Features. Which features are critical, which ones are currently clunky, and which are redundant or obsolete.
Business processes. How changes to content, design, user features, and platform functionality are currently made. Taking note of which tasks are the most recurring and time-consuming, and where the biggest bottlenecks are.
Customer channels. Web and mobile sites, B2B and B2C login accounts, mobile apps, customer service portals, marketplaces, forums, email marketing, social media, etc. Including the tools used to manage them and if they differ between regions and markets.
User journeys. How logged in and anonymous visitors interact with the system across channels.
Integrations. All third-party tools and custom solutions used to extend the platform, including their dependencies and how data flows between them.
Global operations. The locales, languages, and currencies being used. As well as how products, services, pricing, payment methods, marketing content, and regulations differ between regions.
Scalability needs. The expected traffic peaks the system needs to handle and performance metrics from past traffic spikes.
Customizations. The unique functionalities built up over the years and how vital they are to business. Such as business rules, pricing configurations, data models, or customer experience features.
Operating costs. The total cost of ownership (TCO) of the system including licensing, hosting, support services, and hours spent on maintenance and upgrades.
Define missing capabilities
List the capabilities needed to fill the gap between your existing system and the goals stated in your business case. Defining these at a relatively high level (localized pricing, granular permissions, personalized search) keeps you from getting too caught in the weeds of technical requirements at this early stage. As you start to explore different solutions the approaches that are the best-fit for your architecture typically become more clear.
2. Change management
Adopting a composable approach is just as much an organizational change as a technical one. The degree of change needed will vary - replacing parts of a legacy platform with modern tools is going to be far less of a shakeup than moving to a fully microservices setup - but in general, if it’s time to modernize your tech stack it’s likely time to modernize your ways of working.
Project to Product
A lot of companies handle change in terms of one-off projects. Each project has a checklist of requirements, a clear end-date, and when it wraps up the team moves on and the newly implemented solution isn’t changed until the next update project. Whereas with products, a team is responsible for the full lifecycle of a specific part of the system - they design, implement, measure, improve, maintain, and eventually retire product capabilities.
Products can be anything from a single service, to a user journey, to a full application and the teams managing them are multidisciplinary. With developers and system operators (the classic DevOps combo) as well as people who can give relevant input from the business side.
Teams are trusted to make smart decisions about their product. This autonomy spreads out innovation, with improvements happening in parallel across the business, but can be a pretty big change for organizations that are used to aligning on every decision.
Agile development
A core benefit of composable architecture is its modularity. Each component works independently and can be changed without risking the rest of the system, giving companies the flexibility to quickly and continuously adapt components to meet new needs.
However, that flexibility will stay theoretical if teams stick with the familiar development cycles of their monolithic system. Where a tangle of dependencies meant that updates had to be highly coordinated and were usually bundled into big, infrequent releases that required an extensive testing period.
Taking full advantage of composable means creating an environment where developers feel confident making fast, iterative changes. Part of this is practical, like setting up a continuous integration and continuous delivery (CI/CD) pipeline to automate builds, tests, and deployment. While a big part of this is shifting team culture, like decentralizing decision making and getting used to the idea that it’s OK if changes fail as long as you can quickly recover.
Implementation partners
Many companies work with an external agency to get up and running with composable. There are plenty of great implementation partners out there that can help with architecture design, vendor selection, data migration, project management, and provide development resources for implementation (and beyond).
A good partnership starts with figuring out how the joint team will work. Make sure everyone’s on the same page when it comes to responsibilities, deliverables, how information will be shared, who needs to be involved in different decisions, and the regular progress updates expected from both sides.
3. Evaluate new solutions
Start thinking modularly
When going from a single suite of features to choosing specialized tools for different domains, it’s not always easy to define the feature groups that should be replaced or to figure out which types of solutions should replace them.
Categorize existing functionality. As you’re taking stock of the current system, divide functionality into logical groups (e.g. payments, authentication, content delivery) and start mapping out the relationship between groups and the business processes they impact.
Compare with your list of missing capabilities. Take the feature wishlist you made when gathering requirements and map where these capabilities fit among the groups.
Flag what to keep, improve, or replace. This could be based on a range of factors like performance, flexibility, dependencies, level of customization, and how business critical the functionality is.
Find solution clusters. Are there clusters of closely related groups with multiple missing/replaceable features? Could these clusters be covered by a certain type of software? Such as a content management system, loyalty platform, or a combined search and merchandising solution.
Define core criteria
Choosing a stack of composable tools means the selection process is going to involve a much wider pool of solutions and, typically, more decision makers. One team might lead the site search evaluation, for instance, while another chooses the order management system.
While each domain is going to have its unique set of requirements, defining a core set of criteria that should run through the whole architecture can help speed up the shortlist process. These criteria could include a set of baseline standards that help quickly eliminate options (e.g. cloud native, fully API enabled, compliance with key regulations). As well as factors that should be the highest priority when narrowing down the list (e.g. performance, ease-of-use, customer support).
Keeping this list to 3 to 5 core criteria makes it memorable, practical for a range of solutions, and helps independent teams make cohesive decisions throughout the process.
Try before you buy
Figuring out which solutions best-fit your needs will take more specific information than a sales deck can provide. Fortunately, as most modern composable tools are designed to be lightweight and easy to implement, you can evaluate solutions hands-on with small proof of concept projects (POCs) that can be done quite quickly, like with a one day hackathon.
The best POCs apply the solution to an actual business case, as this lets you:
address the biggest uncertainty (Does it integrate with our CRM? Does it work with our Japanese site? Can it handle our traffic spikes? Can it streamline our checkout journey?);
avoid wasting effort on work that’s thrown away;
ensure the product works beyond the market demo;
test API quality and coverage;
check that documentation is clear and up to date;
see if the team enjoys working with the platform.
4. Make the move
Break it into steps
Most companies shift from legacy to composable in phases. The modularity of the architecture, with each component working independently and connected via APIs, makes it possible to implement one component at a time. This allows organizations to keep the parts of the legacy system they like in place and gradually modernize the rest, avoiding major disruption to the business or customer experience.
The specific steps each company takes will be different, but in general the two most common ways to break up the move is by functionality or by channel.
1. Break it up by functionality
Replace one slice of the experience across the whole ecosystem. This could be a whole application, like replacing site search, or a more narrow focus, like moving over product pages to the new CMS.
2. Break it up by channel
Build a composable stack to completely support one channel, such as a regional site, brand site, or mobile app. Typically starting with one of the least complicated, least business critical channels that can be launched with a minimal set of features. Then gradually expanding the stack and adding functionality as you roll it out to more complex channels.
The Strangler Fig pattern
Even when the steps are small, you don’t want to flip a switch and suddenly have everyone using the new component. One way to avoid this is using the Stranger Fig pattern (named after the plant that grows on top of, and eventually overtakes, its host tree) to move traffic to the new service.
With this approach, all traffic comes through an API gateway that will divide it between the new and old service. Starting with a small percentage of visitors sent to the new component, and gradually changing the ratio until all users are successfully using the new component and you can safely retire the old one.
Decouple the frontend first
It’s very common to start a composable commerce migration by going headless , where backend systems only talk to the frontend (the head) via APIs. This “decoupling” means that changes made to the frontend have no impact on backend code, and vice versa.
With a headless setup you can immediately start improving the customer experience (CX), even if your backend systems stay the same. Quick changes to the CX not only have big value potential, they are also a great early proof point for the composable approach, with CX improvement often being a key reason for the move. In a survey of SAP Commerce Cloud customers , the most commonly reported challenge with legacy ecommerce was the lack of ability to customize the CX (61%).
Once the API layer is in place, you can then gradually replace the backend services that power CX by just switching over APIs instead of having to completely rewire the frontend with every change.
To set up the “head” for headless, some companies choose to build their own frontend using frameworks like React, Vue.js, and Angular. Other companies use a Frontend-as-a-Service (FEaaS) solution that provides infrastructure, prebuilt integrations, and customizable frontend components that save teams from having to rebuild the wheel. Some FEaaS solutions, like Alokai, also provide the API orchestration layer to help unify the data and services across your composable stack.
Create your composable roadmap
Going headless is more or less a universal step, but after that pretty much all advice on what to do next is “it depends”. The best course of action comes down to business needs, but some general tips for creating your composable roadmap are:
Create a scoring rubric. Ranking options based on customer impact, commercial impact, team productivity, complexity, cost, and other factors can help prioritize change and identify low hanging fruit.
Prove incremental value. Aim for small steps that can be implemented in weeks, or even days. This is particularly important when gaining momentum early on. It also makes it easier to roll back changes if they don’t have the intended impact, without throwing months of work down the drain.
Don’t go backwards. It can be tempting to keep making quick, one-off customizations to the legacy platform but this just moves the goalpost. Implementing all new features and functionality with modern, API-first practices prevents you from building new dependencies to legacy features you plan on retiring.
Be prepared to pivot. Business priorities will shift, market expectations will evolve, new requirements will be uncovered, and teams will gain experience that leads to new strategies. While it’s hard to “plan for change”, outlining high-level processes for implementing and communicating changes can be helpful.
Ready to take the next steps towards composable commerce?
If you’re curious about what a composable migration would look like for your team, and how quickly you could launch a fully integrated storefront, our experts are on hand and ready to have a chat .
