With all the benefits Spartacus front end brings to the table for SAP CX customers, there’s a single drawback. That drawback is that it works just for a specific build version of the back-end platform. The question of whether we need to upgrade our Hybris back end is often the first one we hear when talking with a potential customer.
Not getting much into the details, upgrading the whole back end, given the number of custom features, modifications, and integrations, is a severe undertaking. It’s also a risky one. The big-bang migrations are, by definition, burdened with the considerable risk of, at a minimum, disturbing the business.
It’s not just in the case of Spartacus. The question of the right way and the right moment for migration is an ongoing one for any mature and productive system.
This observation struck me. Is there a different way we can upgrade without putting too much at stake?
The right moment
The first thing is motivation. When is it the right time to upgrade? Because it’s an investment, the answer is when there’s a positive ROI. For the front end, it could be when you’re doing a redesign. It’s when introducing a new category of products or a new marketing campaign that requires some changes to the UI.
The cost of implementing these features on a legacy platform vs. a new platform is usually comparable, and the risk is similar, too. The benefits are multiple. If your new front-end platform provides the user with a better user experience, the higher conversion rate can offset the migration costs.
It’s worth pointing out that deferring the migration until later usually results in higher costs and complexity. This is because the number of features required to be rewritten or migrated simply grows on the system life cycle curve.
What better time than now?
1 + 1 = 2
If you need to keep the risk very low, it’s easier to not touch what is already working. Easier said than done, but in the case of a migration, it means that the best-case scenario would be to keep the existing system up and running with no changes. Then, move the research and development to a different instance or environment.
You’re setting up a new, upgraded back-end instance. If you’re migrating to another platform, set up the new environment with a new back end and build the implementation from scratch. Sounds easy, right?
On the pros side, there’s virtually no risk for the existing business. A step-back option is switching back to the old system at any point even after the new one’s production launch. On the cons side, there’s potentially a lot of additional work to synchronize the data between instances.
The right segment
It would be great if the migration only disturbs as few customers as possible.
Some time ago, we worked with a customer implementing a new front end for just a segment of customers that had a different brand and storefront. This case is super easy to migrate. We launched a second back-end upgraded instance and then created the new user experience. Additional work was required to synchronize these two back-end systems for the range of overlapping customers. Still, it was easy compared to the potential risks of upgrading the whole system at once.
The other option is to segment the customers using a kind of sticky session and then AB testing. So, launching the new platform for, say, 15% of the customers. The segmentation could be done quickly on the Nginx/varnish/CDN level.
For one of our clients, Lampenwelt (https://lights.ie), we implemented precisely this case. The front end was switched from Magento to Magento plus Vue Storefront. We extended Magento’s API to work with the new front end and ran it as a separate instance. We reused the same database, so no additional sync was needed. Then, we implemented an Nginx-based proxy. This AB test is great because it doesn’t require any client’s side DOM changes because a separate engine server side just generates the whole page.
The right scope
Another option for making the migration safer is to just migrate some parts of the page. It can be relatively easy when your legacy system, and the new one, offer a full REST/GraphQL API.
In that case, you can route the users depending on the URL they’re on. For example, you could serve the new system’s product pages, and the legacy platform can still operate the checkout.
The API is a vital part of the story because it’s being used to synchronize the platforms. With the example above, an “Add to cart” action from the new product page should execute an API call in the legacy platform to update the shopping cart.
There could be some issues with session management. That can be potentially solved by implementing a third-party authorization provider like auth0 or SAP CDC.
Like with identity management, you could move other services, like the shopping cart and product information management services, to separate microservices using the Strangler Fig pattern. In this case, the microservices themselves are a bridge to just modify how the middleware interacts with a new or legacy platform. However, building and maintaining such a structure can quickly become an overwhelming task.
Micro front ends
There’s another category of upgrades and migrations that, when, even keeping the legacy system, you must or want to use some parts of the new platform inside of it. One of the cases we’ve been working on quite recently was a Spartacus implementation where we were to use the new Smart Edit CMS in the old accelerator-based Hybris instance. The mega-menu component was planned to be managed in the new CMS while still rendered at the legacy website.
For this case, the micro front end’s design pattern sounds like a fit. You could render a DOM-separated JS component from the new platform and just embed it in the legacy one. I can imagine the whole shopping cart, product detail page, or any other site element integrated this way.
The performance can be a question, especially in the case of having too many granular web components. It’s easy to get into an over-fetching situation that can be managed with frameworks like single-spa or redux-micro-frontend.
Snipcart case
Another super exciting case that is more like an inspiration than a “battery included” solution is Snipcart. More specifically, the way it integrates with the existing web pages.
Snipcart uses HTML snippets to pass the data from your website.It can be a template-driven WordPress page or Magento 1 to the shopping cart software. This is great because it doesn’t require any back end work or XML or SQL exports. Just the HTML tags or JSON objects.
In a separate blog post, I described in detail a way to build a so-called front-end driven back end. It’s pretty similar to the micro front ends integration pattern. However, it doesn’t necessarily need any UI representation.
What’s your way?
I’m curious about your feedback. Surely these insights are not exhausting the safe migration patterns library. What was your way?
Published April 15, 2021
