# Migrating off Ninetailed after the sunset, what do our audiences and experiences become?

Asked by verena_k on 2026-03-25. Tags: ninetailed, migration, audiences.

We ran the standalone Ninetailed app on a Contentful site until the March 2026
legacy sunset caught us, so I am now planning the migration properly.

Here is what we currently run:

- 6 audiences (industry, returning visitor, two campaign-based, two behavioral)
- 9 experiences that swap hero and CTA entries per audience
- Variant entries live in Contentful next to the defaults

Before I estimate anything I want to map old concepts to new ones explicitly.
In Croct terms, what does a Ninetailed audience become, what does an experience
become, and where does variant content live? I have read
[the sunset thread](/answers/ninetailed-legacy-app-sunset-march-2026) but it does
not go into the concept mapping.

## 2 answers

### Accepted answer from Croct Bot (2026-03-25)

Your list maps over quite directly.

**Audiences.** In Croct, an [audience is a CQL condition](https://docs.croct.com/explanation/audience/introduction) evaluated in real time on
every interaction. Your six audiences become six conditions, for example:

```cql
user is returning
```

```cql
campaign's source is "google" and campaign's name matches "spring"
```

One structural difference: audiences are defined inside experiences, as part of the
who/where/what flow, rather than as a separate library you attach afterwards.

**Experiences.** Same concept, same name. An experience says who sees what content
in which slot. Your nine experiences become nine Croct experiences targeting the
hero and CTA slots.

**Variant content.** This is the main workflow change. [Variant content is authored](https://docs.croct.com/explanation/content/experience-content)
inside the Croct experience, not as extra entries in Contentful. Your Contentful
entries stay as the single default that your app renders, and experiences override
that content only for matched audiences. In practice this means you can delete the
duplicate variant entries from Contentful once the migration is done, which most
teams count as a win for editors.

One dependency worth noting for the behavioral audiences: conditions like
`user is returning` or `session's stats' pageviews > 3` work from the SDK's
automatic tracking, with no instrumentation needed. Only conditions built on your
own custom events or attributes require sending those first.

So the estimate is roughly: map the hero and CTA components to slots in code once,
then recreate six conditions and nine experiences in the dashboard.

### Answer from Sander de Vries (2026-08-05)

Having just finished this exact migration off the sunset Ninetailed app, I
can confirm the concept mapping above held in practice. Two things I would
add from doing it.

First, the behavioral audiences really did need nothing extra: `user is
returning` and pageview-based conditions worked straight off the SDK's
automatic tracking, and only our one custom-event audience needed the event
sent first. Second, deleting the duplicate variant entries from Contentful
afterwards was the step our editors noticed most, since a single default
entry is all that remains per slot.

On effort: budget the bulk of it for mapping the hero and CTA components to
slots in code once. Recreating the six conditions and nine experiences in
the dashboard was the quick part.