Avoiding Vendor Lock-In with Headless

Vendor lock-in refers to a practice where it is difficult to switch vendors/ providers. In short, you are locked into something e.g. perhaps a SaaS application and it is difficult to switch. 

Contractual Lock-In

There are various forms of lock-in with contractual terms representing one common one e.g. you’ve signed a 3-year deal and there are punitive clauses if you want to break the agreement. 

High Switching Costs

Another example of vendor lock-in is when perceived switching costs are too high. The cost of migration is simply too much and outweighs the benefit. Part of this may relate to the actual amount of work needed (say to port data from one system to another). Another can relate to training costs - i.e. retraining employees on a new system. 

Vendor lock-in is thus problematic for companies who find that the application they’ve chosen no longer meets their requirements and they are keen to choose a better option but find the process is likely to be difficult.

SaaS and Vendor Lock-In

One of the attractions of SaaS applications from a business perspective is that the majority of SaaS applications run on a recurring revenue basis. So instead of a one-off fee (transactional), the model is one based on recurring revenue (relational) where payments are ongoing. Leaders of SaaS businesses naturally seek to make their applications as sticky as possible, to reduce churn, and try to ensure that switching costs are a contributory factor. 

After all, their entire business model is based on unit economics shaped by one-off upfront acquisition costs, followed by lifetime revenue (with low associated marginal costs). If this relationship breaks down, and the client does not stick around, then the business model isn’t viable. In an ideal world businesses base retention strategies on providing ongoing value, but in some instances artificial barriers that make switching more difficult act as an additional barrier.

However, as this article will argue, artificially increasing switching costs no longer works. 

Buyers are now more sophisticated than ever before and reducing switching costs and ensuring your application delivers real ongoing value is a better recipe for success. After all, it is now easier than ever to assess the switching costs up-front before subscribing to a new application.

So how does this all relate to CMS selection?

When viewed through the lens of Content Management Systems (CMS) traditional CMSs have their own type of vendor lock-in. At the most basic level with a traditional CMS, it gets harder to switch as websites get more mature over time (and the number and types of pages grows).

Take WordPress as an example, it is a legacy (or monolithic) CMS that is now 20 years old. With an ever-growing list of issues with WordPress, increasing numbers of website managers are seeking alternatives. However, they are learning that it is not always easy to make a change. Migrating off WordPress is not exactly straightforward.

1. As sites mature over the years the amount of pages and plugins increase significantly. Every addition is likely to make the data structures more complex and therefore more difficult to export for use elsewhere. This can lead to long and expensive migrations, or the need to rebuild and rewrite years of content from scratch.

2. WordPress has a plugin for almost everything and any well established website is likely to be using them as a solution for many common website problems. With any migration, finding alternatives to these plugins can be challenging, and often requires bespoke website development that takes time and costs money.

3. With a traditional CMS the front end and back end are coupled together tightly making it more difficult to isolate different elements. Therefore it’s likely any migration will require a rebuild of at least the front end of your website.

4. WordPress is the most dominant CMS in the market, with a rich ecosystem, as such there are plenty of long term supporters and a large community of highly skilled developers keen to ensure it remains a front runner. Choosing to migrate to something else can be seen as an unwise choice.

5. Many of those responsible for site management and maintenance will be familiar with WordPress as a platform and therefore have “gone up the learning curve” earlier in their careers. Hence, it is easy to take the view that the marketing team won’t want to learn a new CMS and that despite its flaws it is still “the market leader” and thus a platform to stick with. 

As a result, despite its limitation, migrations off of WordPress are often only considered when a site reaches breaking point. 

When the decision to make the move is started, a phased migration is a popular route for many - porting parts of the site across to a Headless CMS [What is a Headless CMS?] as a form of incremental adoption.

A Headless CMS is an API-based approach to website building where the front-end and the back-end are decoupled. This means the entire approach is based on the premise of using best-of-breed solutions rather than using an all-in-one offering like a website builder. CMS vendors like Contento are not wedded to any front-end technology. Flexibility and scalability are key benefits of deploying a Headless CMS-backed website. This inherently different approach is all about being vendor agnostic and allowing developers to assemble the best frameworks for their specific use case. 

In contrast, a headless CMS provides developers with the freedom to design the frontend using their preferred technology stack. This not only accelerates development cycles but ensures that you're not limited by the platform's design constraints. They can also deliver on your UX team's specs as they are conceived.

— Source: Why SaaS Companies Should Migrate from Drag-and-Drop to a Headless CMS by Michael Risploi

With a Headless CMS-backed website you have the freedom to build a bespoke frontend that you can change at any time, rather than being limited by the template-based approach of a traditional CMS.

With Contento, it is very easy to get your data out. We offer a 24-hour turnaround for data export requests. As Contento is a Headless CMS your frontend and your backend are separated, so you can easily keep the frontend whilst swapping the backend out.

You can also query all the data in your site yourselves using our API. Your developer can handle this for you, and then save that data into whatever format that you want.

As with all data migrating, life is much easier if you've adopted a structured content approach in the first place:

If you're using a headless CMS, then you're doing some form of structured data. If you've structured it well, then you're going to get it back out in an organised fashion. If you have well-named content types and fields, then you're going to have access to all of those fields in the exported data, which in turn makes importing it elsewhere easier.

— Source: Josh Angell, CTO, Contento

A key concern for all modern SaaS buyers is the question of vendor lock-in. 

• How big are the switching costs?  

• Can I get my data out easily?

When it comes to traditional CMS compared to modern CMS (like Headless offerings e.g. Contento) the approach varies considerably. Modern Headless CMS are API based and part of an approach that promotes portability and flexibility.

The digital world is always in flux. Today's innovative tech might be obsolete tomorrow. By opting for a headless CMS, you're ensuring that whatever new technology or platform emerges, your content can be seamlessly adapted without a complete overhaul of your website or application.

We can now achieve complete re-designs without having to also do total content migrations. Anyone who's had to do this on a traditional open source platform like Wordpress or Drupal knows this can be painful. Doing this with a drag-and-drop editor or CMS can be downright gruelling. If you plan to do regular re-designs every 2 or 3 or 4 years, you can save yourself some major headaches by keeping your content and CMS separate from your frontend code.

— Source: Why SaaS Companies Should Migrate from Drag-and-Drop to a Headless CMS by Michael Risploi