Deliver and maintain › Adobe Analytics and CJA
Migrating to CJA
Two months into a migration, somebody puts the same report side by side in both systems. The revenue figures are eleven per cent apart, and a week goes into finding out why.
The answer turns out to be four things at once. An attribution default nobody set. A processing rule from 2021 that was never written down. A purchase deduplication setting that did not come across. And rows the source connector had left behind.
None of those is a fault in either product. Each one is a decision somebody made years ago and nobody recorded, surfacing at the one moment when two systems have to agree.
There is no deadline
Much of the writing about this topic carries an implied urgency, and it distorts the decision.
Adobe has announced no end of life for Adobe Analytics. The product is actively developed and its release notes are current. What was retired is narrower, and it keeps getting generalized. Reports & Analytics stopped working on 17 January 2024. Data Workbench went before it. The legacy Report Builder reached end of life in June 2026. Those are components and tools, and their retirement says nothing about the platform underneath.
Adobe describes Customer Journey Analytics as the next generation product, and its own guidance on moving is a case by case conversation rather than a mandate. That is a different message from the one the market has settled on.
The consequence is practical. A migration run because of a deadline is planned backward from a date. That is how a business ends up in CJA with rebuilt segments, unexplained discrepancies and no new capability. A migration run for a capability starts from a question somebody cannot currently answer, and that question decides the scope and the sequence.
Do you need to analyze data that is not digital behavior, such as call center contacts, store transactions or subscription records, alongside web and app data? Do you need to correct or reinterpret history rather than only what arrives from now on? And do you need to report on people rather than devices, with an identifier good enough to support it? A clear yes to any of the three is a real reason to move, and the migration can be scoped around it. Three vague maybes is a reason to wait, and waiting costs nothing while Adobe Analytics remains supported.
What does not come across
The data moves. Almost everything built on top of it is rebuilt by hand, and the size of that list is the usual reason a plan slips.
| In Adobe Analytics | What happens to it |
|---|---|
| Segments | Rebuilt. They do not port, and the logic often needs rethinking against report-time sessions |
| Calculated metrics | Rebuilt. Same arithmetic, different components underneath |
| Processing rules and VISTA rules | Recreated as Data Prep mappings or derived fields, and the derived field version is usually more capable |
| Marketing channel rules | Partly. Some rule types are unsupported, and a Web SDK implementation needs derived fields to reproduce them |
| Custom session logic | Becomes a data view setting, which is easier to change and easier to get quietly wrong |
| Long dimension persistence | Capped at 90 days. An eVar set never to expire has no equivalent |
| Activity Map | Not available and not currently planned |
| Classifications | Become lookup datasets or derived field logic rather than uploads against a key |
Read that as an inventory exercise rather than a warning. Every row is a countable list in your own estate, and counting them takes an afternoon.
What that inventory looks like in practice
The Kestrel and Co. implementation is a useful size for seeing this, because its documents are complete and public. Its design covers 35 solutions, of which 28 were built and tested in the first phase.
Four of those 28 are configuration rather than tracking calls, and those four are the migration work.
| Kestrel solution | What it is in Adobe Analytics | What it becomes in CJA |
|---|---|---|
| KES-S031 | Marketing channel processing rules, nine channels | Partly rebuilt. Some rule types are unsupported, and a Web SDK feed needs derived fields |
| KES-S032 | Campaign code classifications, uploaded against a key | A lookup dataset, or derived field logic |
| KES-S033 | A processing rule bucketing search result counts | A derived field, applied at report time and changeable afterward |
| KES-S038 | Consent gating on every rule, in the tag manager | Unchanged. It happens before collection, so it migrates with the implementation |
The last row is the useful one. Consent gating is the only one of the four that does not move, because it happens in the browser before any data is collected. Everything Adobe does after collection has to be rebuilt somewhere else.
These three are the ones a migration works from. The design document lists what should exist, the technical document holds the rules that have to be recreated, and the validation report records what was actually proven and what was dropped. They are filled in with the Kestrel example. If you cannot download them now, you can come back to this page later.
The five discrepancies, and what causes each
When two systems report the same period and disagree, the causes are almost always from a short list. Working through it in order settles most investigations quickly.
| Symptom | Cause | What to do |
|---|---|---|
| Conversions credited to different channels | The data view has its own default attribution model, commonly Same Touch, where the Adobe Analytics variable was set to Last Touch | Set attribution deliberately per component rather than accepting the default |
| Orders and revenue too high | Deduplication was configured in Adobe Analytics and not reproduced in the data view | Set the deduplication identifier on the metric in the data view |
| Far more dimension values than expected | CJA keeps every unique value at full cardinality, with no Low Traffic bucket | Expect it, and check whether anything downstream relied on that bucketing |
| Visits and Sessions disagree | Visits is fixed at collection. Sessions is calculated at report time from the data view setting | Match the session timeout, then accept a residual gap as correct |
| Row counts short by a small margin | The source connector segments out certain data, and more rows can be segmented between the Data Lake and CJA | Measure the gap once, write it down, and stop reinvestigating it |
The last row deserves a habit rather than an answer. Establish the size of the structural gap early, in writing, on a period nobody is arguing about. After that, any difference larger than that number is a real finding and anything within it is noise. That is the difference between a week of investigation and an afternoon.
Run both systems, on purpose
The two systems overlap for a period. Treating that overlap as a planned phase rather than an awkward interval is most of what separates a calm migration from a fraught one.
The overlap lets you ask a question of both systems and investigate the difference while the evidence still exists. Once Adobe Analytics stops being maintained internally, every unexplained discrepancy becomes permanent, and the new system inherits a reputation it cannot shake off.
Use the period for something specific. Pick the ten reports the business actually acts on, reproduce those ten in CJA, and reconcile each to a stated tolerance. Ten reconciled reports is a finished migration in every sense a stakeholder cares about. Rebuilding everything anybody ever made is a project with no end.
Why documentation decides how this goes
Adobe's own guidance on migrating puts it plainly: without rule documentation, metric discrepancies are inevitable.
Every processing rule, VISTA rule and channel rule in a live implementation is a decision that changed the data. During a migration each one has to be reproduced or deliberately dropped, and both need somebody to know what it did and why. Where that is written down, the rebuild is mechanical. Where it is not, somebody reverse engineers behavior from reports, which is slow, incomplete, and produces a system nobody quite trusts.
The Kestrel table above is what a documented estate looks like. Four configuration solutions, each with an identifier, a requirement sentence and a record of what was tested. Working out what to rebuild took reading one sheet. An undocumented estate of the same size starts with an archaeology project.
Schema field data types are fixed once data has been ingested against them. A numeric value defined as a string, or a date left as free text, is repaired by deleting the dataset and recreating it. That discards the history already landed in it. Everything else in a CJA migration is reversible in an afternoon. This is not. Have somebody who knows the data read the field types before the first load, and treat that review as a gate rather than a formality.
Where to actually start, and it is not in CJA
The instinct on deciding to move is to open Customer Journey Analytics and start building. That is the wrong first move, and the reason is in the two routes covered in Adobe Experience Platform Integration.
The source connector will get your report suite into CJA in an afternoon. What it delivers is CJA reading data Adobe Analytics already shaped, with the collection-time decisions baked in. You get the new reporting model on top of the old data model, which is the smaller half of the benefit.
The full benefit needs clean events arriving through the Edge Network, and that means moving collection to the Web SDK. Do that first and CJA adoption becomes connecting a dataset. Skip it and you have bought a platform you cannot use properly.
So the practical first project is not a CJA project at all. It is a Web SDK migration, and this site has a complete guide to it.
Web SDK Migration
Thirteen ordered steps from taking inventory to decommissioning AppMeasurement, with a knowledge base of twenty two reference articles behind it. The on-ramp that makes everything in this module affordable.
Take inventory
The first step, and the one that overlaps most with the counting exercise above. Everything you own, written down, before any decision about what carries forward.
The forward path
What the Web SDK unlocks once data flows through the Edge: CJA, server-side Event Forwarding, and Target. The case for sequencing them rather than attempting them together.
Sequence the two projects rather than combining them. Stabilize Adobe Analytics on the Web SDK, prove parity against the old collection, and only then bring CJA in. Running them together is how a team ends up unable to say whether a discrepancy came from the new collection or the new reporting.
When the CJA half does begin, the shape of it is the one this section has described. Count what has to be rebuilt. Reconcile a bounded set of reports rather than everything. Have somebody who knows the data review the field types before the first load, because that is the only step you cannot undo. And keep Adobe Analytics answering until the people who use those reports have signed them off.
Where this leaves you
With a decision that is yours to time. There is no deadline. The case for moving is a capability rather than a date. And the work is dominated by rebuilding what sat on top of the data rather than by moving the data itself.
One theme has run through this whole module. What makes a migration hard is not the difference between two products. It is the undocumented decisions inside the old one, and those were expensive long before anybody proposed moving. A team that has kept a design document current migrates in weeks. A team that has not spends those weeks working out what they built.
That leaves a question about direction: where to go after Adobe Analytics, and which parts of it keep their value once the product changes. What to Learn Next answers both.
The inventory you need is spread across three screens, and gathering it is the first real task of any migration. Segments and calculated metrics are listed under Components. Processing rules, bot rules and channel rules sit under Admin > Report Suites > Edit Settings. Variable configuration is under Edit Settings > Conversion and Traffic. VISTA rules appear on none of them, because Adobe configures those, so your own documentation is the only record you will have.
This article focuses on the concepts, architecture, and practical guidance behind the topic. For the latest UI walkthroughs and step-by-step implementation instructions, use the links below. They leave this site and open Adobe's own documentation in a new tab.