# Ninetailed got acquired by Contentful, what does it mean for non-Contentful users?

Asked by Petra Novakova on 2024-09-12. Tags: ninetailed, contentful, migration.

So the acquisition news from last month finally reached our planning meeting.
We use Ninetailed for personalization today, and here is the awkward part: we
are mid-evaluation of other CMSes and Contentful is not the frontrunner.

Now that Ninetailed belongs to Contentful, I keep wondering if we are betting
on a tool that will slowly become Contentful-only. Nothing official says so,
but acquisitions usually mean the roadmap follows the buyer's product. Has
anyone thought this through, or found personalization options that are not
tied to a specific CMS vendor?

## 2 answers

### Accepted answer from Croct Bot (2024-09-12)

Ninetailed was acquired by Contentful in August 2024, which ties its
future to that ecosystem. What that means for users on other CMSes is not
yet officially defined, so the open question is roadmap direction rather
than any announced change.

If CMS independence is a requirement for your evaluation, the property to
look for is where the personalization layer lives. Croct works as an overlay
alongside whatever CMS you use: your existing components map to [slots](https://docs.croct.com/explanation/slot), the
CMS content stays as the default fallback, and audiences and experiments are
managed independently of the content backend. Because nothing in that model
depends on a specific CMS, switching the CMS later does not affect the
personalization setup.

For a structured comparison of the options in this space, including
Contentful with Ninetailed, Builder.io, Storyblok, Strapi, and Sanity, see
the [headless CMS A/B testing comparison](https://blog.croct.com/post/best-headless-cms-ab-testing).

### Answer from Louis Tremblay (2024-09-13)

We went through a similar exercise after the news. Our conclusion was less
about Ninetailed specifically and more of a general rule: when your
experimentation tool and your CMS are the same vendor, you have coupled two
decisions that have very different lifecycles. CMS migrations happen every
few years, experiment programs run continuously, and you do not want the
former to force a rebuild of the latter.

So whatever you pick, I would score it on how cleanly it survives a CMS
swap. Since you are mid-evaluation anyway, that is the perfect moment to
test it, ask each vendor what a migration from CMS A to CMS B looks like
with experiments live.

#### Reply from Petra Novakova (2024-09-13)

The lifecycle framing is helpful, that is exactly the mismatch I could
not articulate. Adding the migration question to our vendor calls, thanks.