Gradually Migration to a Composable Architecture
Replatforming is scary. Terrifying, actually. And really, really expensive.
When you think about moving from a monolithic system to a composable website, doing it all at once means years and years of work with nothing to show for it. However, if you migrate gradually — meaning one page or service at a time — you’ll be working with new technology in production within months.
The typical migration path
There are a number of approaches to achieving this, and there isn’t one that is necessarily better than the rest.
However, many of us have found that shifting the mindset into the new and composable system and treating it as the front door to everything else in your system is the best way to go. To get started that usually means:
Choose a deployment and hosting platform.
Implement a reverse proxy on the platform to route everything to existing (now legacy) systems.
As you add pages and services, remove the proxy, one route at a time.
Eventually that proxy will dwindle to few services and pages as you work to replace everything.
Some legacy systems will survive
This approach is desirable for the following reasons:
You can show results quickly
You focus your time building the highest priority items without getting distracted
Because you will follow the priority, it’s very possible (and highly likely) that you’ll never actually get to sunsetting all legacy systems.
And that’s okay. You may find that going through this process results in recognizing that some service is still serving you well, that you can still staff it, and that it would be too big of a cost to replace to justify it.
Those cases will arise and this is where the proxy and gradual migration come in handy.
Migrating content sources
One of the most challenging moves is going to be moving content. It’s somewhat unreasonable to expect content editors to use different services to change content on different pages (even if that’s what they do today). Your editors deserve better.
You also don’t want your developers to have to implement new queries every time you move a page over to the new system.
Therefore, we recommend taking two actions when moving content:
Content API: Build or buy an API that exposes the content your new site is going to use. It will serve all legacy content initially, and when new pages are added to the new CMS, your frontend code still hits the same API to retrieve the new content. Nothing had to change in the code.
Single content source: Ideally editors would be able to go to a single source of truth to edit content, regardless of where that content lives. Stackbit is the only solution we’re aware of that makes this process easy to handle. Headless CMSs and DXCs have not yet evolved to provide the capability of writing back to legacy systems.