blog

Adobe Analytics to CJA Migration: Why Historical Data Now Has a Price Tag

Written by Arunkumar subbiah | Aug 11, 2026, 9:12:02 AM

The moment most migration teams discover the problem

A stakeholder asks for a three-year performance comparison. In Adobe Analytics, that was a short task nobody escalated. In Customer Journey Analytics, someone flags the cost, and a routine report becomes a budget conversation.

Nothing broke. The team simply carried one habit from the old environment into a new commercial model where that habit has a price. We see this pattern often enough in enterprise migrations that we now treat it as a standard workstream in any Adobe Analytics to CJA transition, rather than a surprise to be handled after the first invoice.

This article covers what changed, why the impact lands harder than teams expect at both the business and analyst level, how CJA billing actually works, and the three-step process that removes the cost surprise from long-range reporting.

What actually changes when you move from Adobe Analytics to CJA

In Adobe Analytics, history is ambient. Years of data sit in the report suite, available whenever anyone wants a long view. Pulling three years costs what pulling last month costs. There is nothing to plan around, so nobody plans.

CJA bills on rows. Every row of event data brought into a connection is licensed, stored, and counted. Pulling three years of history is not only a query. It is an act of adding a large volume of rows, and the row count is the billable unit.

The shift reduces to one line: in Adobe Analytics, more history is free. In CJA, more history is more rows, and more rows is more cost.

Simple to state. The consequences show up in two very different places.

Adobe Analytics vs CJA: how history behaves

Dimension

Adobe Analytics

Customer Journey Analytics

Cost of historical range

Included, effectively unmetered for reporting

Priced by rows ingested and retained

Three-year pull vs one month

Broadly the same cost

Materially higher, driven by row volume

Exploratory "pull everything first"

Standard practice

The most expensive step in the project

Keeping data for follow-ups

No incremental cost

Counts at every billing snapshot

Meters to manage

Effectively one, retention

Monthly rows, annual ingestion, GB storage

Skill required

Answering the question

Scoping the question before answering it

 

Where the cost lands at the business level

Consider a common situation. An organisation licenses CJA sized around normal reporting needs, roughly a year of data with comfortable headroom. Six months in, leadership asks for a three-year performance review ahead of annual planning. A reasonable request, and one Adobe Analytics would have answered without discussion.

Answering it in CJA at full event-level detail means ingesting two additional years of data. That carries three business consequences, and only the first is obvious.

1. The direct licensing cost

More rows against the license. If the historical years were high-traffic, a single backfill can push the account toward or past its licensed row count, which converts a reporting request into a procurement conversation.

2. The annual ingestion cap

This is the consequence that catches teams. CJA does not only meter what you are storing. There is also a yearly limit on total ingestion, typically expressed as a multiple of your licensed rows. A large historical backfill consumes a meaningful share of that allowance.

The part that stings: deleting the data afterwards reduces your stored row count, but it does not refund the ingestion budget. A careless three-year backfill in Q1 can quietly spend headroom the business will want in Q4.

3. Planning friction

Once a long-range pull has caused a billing surprise, every future request slows down. Analysts begin asking permission for work that should be routine. Stakeholders learn that "historical" means expensive and slow. The lasting cost is not the invoice. It is an organisation that becomes hesitant to ask large questions of its own data.

None of this means CJA is mispriced. It means long-range analysis needs to be planned the way any metered resource is planned, deliberately rather than on demand.

Where the cost lands at the analyst level

The same problem looks completely different from the analyst’s chair.

An analyst with years of Adobe Analytics experience carries a set of instincts: pull the full range, explore freely, keep everything available in case a follow-up question arrives. Those instincts were correct in that environment, because history was always on and never metered.

In CJA, each instinct now has a price attached.

"Pull the full range" now means ingesting every row in that range. The exploratory three-year pull that used to be a warm-up step becomes the single most expensive action in the project.

"Explore freely" assumes the data is already present. In CJA, exploring at full granularity requires the data to be there, stored, counted, and billed for the entire duration of the exploration.

"Keep it around for follow-ups" is the quiet one. Data sitting in an active connection counts at every snapshot, whether or not anyone queried it that month. The just-in-case archive that cost nothing in Adobe Analytics appears on the license dashboard month after month.

The result is a skill shift that rarely appears in migration documentation. In Adobe Analytics, the analyst’s job began at "how do I answer this question?" In CJA it begins one step earlier, at "what does this question actually need?" Once that becomes habit, it stops being a burden. The difficulty is that nobody flags the habit as mandatory, and the first invoice is usually how teams find out.

How CJA billing is actually calculated

You do not need to be a licensing specialist. Three facts change how you approach every long-range request.

Billing is snapshot-based

CJA counts the unique rows present in your active connections when it takes a snapshot, typically monthly and visible in your license dashboard. The number moves as data is added or removed. In practice, rows are not billed forever because they once existed. They are billed while they are present when a snapshot runs, and deleting data lowers the count at the next snapshot.

The yearly cap is a separate meter

On top of the monthly count sits the annual ingestion limit described above. Two meters, not one. Both need managing.

Platform storage has its own meter

The Experience Platform layer beneath CJA is measured as well, in gigabytes rather than rows, with daily snapshots against contracted storage. Deletion behaves similarly with one caveat: the reduction appears only after retention and cleanup jobs complete, not at the moment the delete is issued. If you are clearing data on a schedule to control cost, build that lag into the schedule.

The process we apply to every long-range request

Every long-range request goes through three checks, in order. It takes minutes, and in our experience it removes the cost surprises.

Check 1: Does the question need detail, or just totals?

This is the largest lever and the step most teams skip. Year-over-year revenue, directional traffic trends, high-level behavioural shifts: these are aggregate questions. They do not require row-level event data at all.

CJA summary data exists for exactly this purpose. Bring in pre-aggregated numbers and compare them, without paying the per-row cost of the full event stream. Most cost overruns we encounter begin here, with raw events pulled for a question that summary data would have answered. In the leadership review scenario above, summary data would very likely answer the question at a small fraction of the row cost.

Check 2: If detail is required, bring history in slices

Sometimes granular data is genuinely necessary, for a deep segmentation study or a multi-year journey analysis. Even then, you rarely need the whole range live simultaneously.

Pull a slice of the range, run the analysis, offload it, then pull the next slice. Because billing reflects what is present at snapshot time, a rolling window keeps the active row count low even when the total history touched is large. It is more hands-on than keeping everything loaded, and it is the difference between a controlled cost and a runaway one.

One caveat: slicing manages the monthly row count, but every slice still spends against the yearly ingestion cap. Plan the total volume up front rather than slice by slice.

Check 3: Provision for the question, not for "just in case"

The old-world instinct is to keep everything on hand because a follow-up might arrive. In CJA that instinct is a recurring charge. Keep what current questions need. If a follow-up arrives, bring the data back deliberately, with the cost known in advance.

Pre-migration checklist for CJA historical data

  • Before any long-range pull, classify the request: aggregate question or detailed question.
  • Aggregate question: use summary data and avoid the row cost entirely.
  • Detailed question: ingest in slices, analyse, offload, repeat.
  • Budget the total backfill volume against the yearly ingestion cap before starting, not during.
  • Monitor both meters: monthly row count and annual ingestion allowance.
  • Track platform storage separately, as a GB-based meter with daily snapshots.
  • Expect a lag between deleting data and seeing counts drop.
  • Do not leave just-in-case data sitting in active connections between snapshots.
  • Adobe Analytics treats history as included. CJA treats history as licensed volume.
  • Two meters govern data volume in CJA, the monthly row snapshot and the annual ingestion cap. Deletion affects the first but not the second.
  • Experience Platform storage is a third, GB-based meter with its own deletion lag.
  • Most CJA cost overruns start with raw event data pulled for a question that summary data would have answered.
  • The analyst skill that migration documentation rarely mentions is scoping the question before pulling a single row.

What this means for your migration roadmap

Teams that treat historical data as a scoping decision keep answering the big questions after migration. Teams that treat it as an afterthought stop asking them, and that is the real cost.

Practically, this belongs in the migration plan itself rather than in post-launch firefighting. Three decisions are worth making before the first connection is built.

  1. Which questions the business actually asks across a multi-year horizon, and which of those are aggregate rather than granular. This determines how much history needs to exist at row level at all.
  2. How much history to ingest at cutover, balanced against the licensed row count and the first year of ingestion allowance.
  3. Who owns the scoping check, so that request triage sits with a named role rather than emerging as an ad hoc conversation after a billing alert.

Axeno works with enterprise analytics and marketing teams on Adobe Analytics to CJA migration scoping, data ingestion design, and licensing-aware reporting models, so long-range analysis stays answerable without unplanned cost. If a migration is on your roadmap for this year, the scoping conversation is worth having before the ingestion decisions are locked.

Key Takeaways

  • Adobe Analytics treats history as included. CJA treats history as licensed volume.
  • Two meters govern data volume in CJA, the monthly row snapshot and the annual ingestion cap. Deletion affects the first but not the second.
  • Experience Platform storage is a third, GB-based meter with its own deletion lag.
  • Most CJA cost overruns start with raw event data pulled for a question that summary data would have answered.
  • The analyst skill that migration documentation rarely mentions is scoping the question before pulling a single row.