Farewell Sitecore. Hello Optimizely

In our recent Masterclass with Optimizely (September 2024) we described how to migrate smart from Sitecore to Optimizely. Here in this blog post we explore the underlying business context which drives the decision to make such a dramatic IT change. Important to understand. Yet, often overlooked by systems integrators.

Why are you leaving?

When a customer takes the decision to leave Sitecore, it’s done with a very heavy heart. No IT director wants to change anything unless there’s a pretty good reason. As they consider their options, it’s safe to assume the following things weigh on their mind:

• They have invested years into the platform. Probably millions too. They know there’s very little re-use in the future state. Ouch!  

• They know switching is expensive and complicated. They’ll be building a new platform while maintaining the current one, splitting resources, doubling up costs. And it means learning new systems as well as teaching the business how to use them. Double ouch!   
  

• Big change is risky. We were promised so much. How can we be sure we won’t be burned again? Groan...

In other words, the current solution has failed. We’re done. No more good money after bad. A technical platform migration is a ‘distress purchase’, and this shouldn’t be forgotten. As good consultants, it’s wise we empathise with our customers, but especially in this context. Understanding the cumulative pain that led to this point, points us toward the best solution. And those pain-points? They’re old friends:  

• Publishing content is too complicated. The sales and marketing team is getting really frustrated or, have given up. They know about Wix, Squarespace and Shopify. They have no idea why it takes weeks to spin up a campaign landing page.    

• Planning deployments and the total cost of support has become too high. To the point where the budget has been throttled back to just ‘keeping the lights on’, and not much else.  
  

• The cool features promised (and paid for) have never been used. And this makes everyone feel pretty sceptical about the sales pitch for the next solution.  

Invariably, all of the above has been caused by short-sighted architecture decisions compounded by hurried implementation and weak development standards (not withstanding poor roadmap choices).

This sounds all too familiar, doesn’t it? But we mustn’t sneer or snark. We’re all culpable. So, starting the project with a degree of humility, and a sympathetic bed-side manner is appropriate.

What do you want now?

If we reflect honestly on the ‘why’, is it any wonder that an MVP-style lift-and-shift approach exists only as a theoretical concept - one that will rarely see the light of day.

The years of handwringing that have led to this point have incubated a great deal of pent-up demand for change. Especially now, in 2024, with all the leaps made in the last five years.

The idea of a like-for-like, lift-and-shift makes no business sense. It won’t get funded.

Leaving a burning platform is an opportunity to catch up on lost time. It’s not a 'migration'. It’s a re-design project. The scope of the re-design is a variable. The implementation of a fresh Optimizely installation and the migration of legacy data, a facet of the project. An important distinction.  

Learning from lessons learned

Of course, when we start scoping, we lean on our experience. We factor the mistakes we’ve made in the past.

Another way of thinking about lessons learned is as assumptions proven false. False assumptions are born three ways: error of judgement, lack of experience and hopeful optimism.

Let’s set aside the first two - assumed irrelevant ;o) - and focus on the third, hopeful optimism. Common here are two interlinked issues:

• We over-estimate the role of automation

• We under-estimate the time and effort required for manual publishing and testing

So a word to the wise - as we plan and scope the project, whatever assumptions we make about these common activities, make sure there is a robust justification for them.