How to switch from a monolithic to a composable architecture in 7 steps

In recent blog posts, we discussed the benefits of a composable architecture and the common pitfalls  of moving to a composable architecture. Now that we’ve highlighted the benefits and the challenges, there’s only one area left to cover: how to make the switch.

The goal of switching from monolithic or “legacy” architecture to composable is to do so with as little disruption as possible to your organization’s digital experience. This seven-step process helps you do just that.

Step 1: Make sure you’re ready

Moving to a composable content management system (also known as a “headless CMS”) is a major undertaking that requires a lot of time and resources. So before you take any concrete action, it’s crucial to first ensure that your organization is ready to make the switch. To determine if your organization is ready to switch, ask yourself the following questions:

What are your goals?

Do you need to scale certain key functions or features to keep up with customer growth? Does your digital experience require a particular tech stack that can’t be replicated with a legacy CMS? Do you need to cut down on development time and reduce your time to market? Before moving to composable, it’s important to define what specific business needs you hope to meet by making the switch.

Can these goals be achieved with your legacy architecture?

Depending on your organizational needs, it’s possible that your monolithic architecture isn’t up to the task. Still, it’s a good idea to confirm this before committing time and resources to moving to a composable CMS.  

Do you have the right people in place?

Implementing and managing a monolithic CMS and a composable CMS are two very different things. You need to be sure you have engineers and developers on your technical team who can effectively manage the transition — and everything that comes after.

Step 2: Take inventory and categorize functions

A monolithic CMS is large and complex. You may not realize how many functions are contained within the codebase — or the ways each function connects to and depends on the others. You don’t want to find yourself midway through a migration and scrambling to find an application to replace a key function you didn’t know was there.

In order to ensure a seamless switch from monolithic to composable architecture, it’s important to take an inventory of what you currently have. Mapping out how all the existing monolithic functions work together helps ensure you have the right tech stack in your new composable CMS to handle those functions once the migration is complete. 

During this step, you should also group all your functions into logical units based on the area of your business they support. For example, all the functions that support your customer service can be grouped into one unit, while functions that support shipping can be grouped together in another. 

Knowing what functions and services you currently have is a crucial part of the next step: deciding what to prioritize as you switch to composable. 

Step 3: Define your priorities

It can be tempting to want to migrate everything from your legacy CMS to composable all at once, but doing so is a recipe for disaster. The smartest and safest way to switch to composable architecture is with an incremental process; how that process unfolds is up to you.

There is no one-size-fits-all approach to this step. Some enterprises may focus on moving functions with the fewest number of dependencies into a composable CMS. Others may be experiencing performance issues with core functions in their legacy CMS and choose to move those services over first. Each organization will have its own unique business needs and  priorities. 

Step 4: Find a platform

The purpose of this step is to help you get a clear picture of what you need from your composable CMS and how you intend to use it, which in turn helps you identify the platform that is best suited to host your new composable CMS.

Once you’ve taken inventory of what you have in your legacy CMS, the next step is to define how each existing feature works. This will give you a better idea of how those features need to function as individual applications in a composable CMS. You’ll also need to identify the APIs needed to build each of these applications. There are different categories of APIs depending on the functions and protocols required for your organization’s tech stack. 

Step 5: Isolate functions and design applications

Now that you’ve taken inventory of your monolithic CMS’s functions and split them into groups, you’ll need to isolate the functions themselves. That means untangling any dependencies that exist between functions within these groups so they can work as independent applications in your composable CMS. 

Designing the applications will fall on your organization’s technical team, which is why it’s so important to ensure you have the right talent before starting the transition. In a monolithic CMS, functions are linked to domain logic, but composable doesn’t work that way. Your team needs to separate the presentation, business logic and data layers of each function — and set up gateway APIs to route requests between each of those layers — in order to ensure these functions can operate independently in a composable environment.

Step 6: Define your strategy

You’ve started the process of designing the applications and determined the order in which these functions will be migrated over to your composable CMS. Now you have to decide on a migration strategy. There are a few ways you can perform this migration.

The Strangler Pattern

Introduced by Martin Fowler in 2004, the Strangler Application Pattern is an incremental approach to migrating from legacy architecture to a composable system. 

With the Strangler Pattern, your team builds and deploys the individual applications for each function. While this is going on, a router (also known as an intercept, a proxy or a facade) directs user requests. If the request involves a function that hasn’t been migrated yet, the legacy CMS handles it; if it involves a function that has been migrated, your new composable CMS handles it. As more applications go live, your composable CMS will pick up more and more of the user requests. Eventually, once all services and functions are up and running in your composable CMS, you can route all traffic there and retire the monolithic CMS. 

This approach gives your enterprise a valuable safety net in case one of the applications doesn’t work as intended, allowing you to quickly identify the problem and deploy a fix. It’s also minimally disruptive to an existing system, which makes it a very popular approach to migrating to composable architecture.

Domain-Driven Design (DDD)

The Strangler Pattern is ideal for organizations with static needs. But if your organization is constantly adding new functionality, Domain-Driven Design (DDD) offers greater flexibility during the migration process.

With DDD, new functionality is added to a standalone application, rather than to the monolithic codebase. An API gateway routes incoming requests to the monolith or the new composable application, depending on where the requested function lives. In the long run, DDD and the Strangler Pattern both eventually phase out your monolithic CMS — the difference mainly lies in how agile your CMS can be during the migration. 

Parallel adoption

A parallel adoption pattern works similar to the Strangler Pattern, but with one key difference: the monolithic CMS does not get retired right away. Instead, the monolithic and composable solutions run the same features in parallel with one another. Duplicating these features allows you to compare how each CMS performs with a given request, which can help you determine if the composable application is an improvement over your existing functionality. 

Eventually, the monolithic CMS does get retired, but not before you can gather extensive performance data to ensure the composable CMS is delivering as expected.

Step 7: CI/CD & Strategic Migration

The last step is to create a CI/CD (Continuous Integration/Continuous Delivery) process. The CI/CD process allows your team to automatically test any changes and confirm the code is ready to deploy, and if it is, to automatically publish those changes. A CI/CD pipeline allows your team to code, test, and deploy changes without getting in each other’s way, and it’s a key part of a major benefit of composable: the ability to test and code changes without disrupting the digital experience for your users.

At this point, you’re ready to begin migrating functions out of your monolithic CMS and into your new composable solution. As we mentioned above, the order in which you migrate and implement each application depends on what best suits your needs. Above all, the migration should be done gradually to ensure your monolithic CMS can serve as a backup and your team is able to address issues as they arise. 

Learn more

Learn more about the benefits of a composable architecture in our guide, “What is composable architecture?”

Schedule a free demo to see how Contentstack’s headless content management platform and industry-leading, cross-vendor support can help your organization make the transition to a composable architecture today.