Jason St-CyrOptimizely recently launched their SaaS CMS and Dylan Young over at Valtech did a deep-dive comparison that was really great. I had started just adding some comments for social and then realized this was getting WAY too long. 🤣
I won't ruin the ending, but this article by Dylan Young piqued my interest. In the 'migrations' I usually think about I'm often looking at an existing Sitecore customer trying to move to XM Cloud, but the fact is that there are a lot of options out there and Optimizely is pushing hard to pull those customers over to their SaaS CMS.
Dylan has a really solid analysis in his article and for me the bit that stands out as separating factors are that built-in personalization is missing (really? 😲) and that there are no forms features. A few of my own thoughts based on Dylan's work:
- Ability to Learn: Optimizely having a .NET Core example doesn't necessarily influence the category of 'learning' for me, unless you are really into .NET. Even then, there is a Sitecore .NET Core example site built out (mvp.sitecore.com) with all the code available. I agree on most of the points here, though... the learning curve for XM Cloud is pretty steep.
- Features: Dylan rightly points out that XM Cloud has a head start in this space and it looks like Optimizely has a lot of catching up to do. I suspect the Optimizely CMS will rapidly evolve to try to close some of the feature gaps, or perhaps they'll start offering packages with their personalization/analytics tooling as a bid to compete on features? Time will tell, I suspect.
- Identity/Portal: The state Optimizely is in basically mirrors what happened when Sitecore first launched its portal with only XM Cloud in it. While Sitecore is ahead here at the moment, you can't fault Optimizely much for it and they'll close this gap eventually.
- Extensibility: I know web hooks seem to be today's preferred approach for extension, but it's not the same as being able to truly alter a product. I think this move is going to be great for a lot of customers who never really needed those customizations and will attract a new type of customer that wasn't interested in the on-premise versions both vendors offered.
- Developer choice: I used to position XM Cloud, while on the Sitecore side, as really opening up choice for devs to build with the modern frameworks they wanted. We worked hard to tell that story, but ultimately it wasn't backed up by the product and it became clear that Next.js was the only way to ensure full feature functionality was actually working. You could make other ways work, but it was a bit of a mess. At SUGCON Europe and India, Liz Nelson did talk about updating the DevEx to make it easier for Sitecore to finally get to that optionality that was always desired. My personal take here is that when Sitecore makes those changes it will likely leapfrog over the DevEx for Optimizely, but until then if you aren't using Next.js you are relying a lot on a partner knowing all the ins and outs of another framework on XM Cloud (or having their own framework implementation of JSS).
- Stability and Maturity: I remember my team at Sitecore building on XM Cloud in the early days. It was rough. The product team needed real implementations to be done to push the product and get it to a point where it is today. I don't doubt that Optimizely has had some early adopters go live, but they are a few years behind in this race. I would be hesitant to recommend Optimizely's SaaS option to a new customer that was risk averse or not willing to be an early adopter, which covers a lot of customers in the Enterprise space. That should change soon, so Sitecore's advantage here of being out earlier will soon disappear. Sitecore will need to take advantage now to lock in those Enterprise customers while Optimizely is still building up their case studies and customer proof points.
That's my take on Dylan's categories and research, but you should make your own decision. Read it yourself!
