Article
Adobe Analytics to CJA Migration: A Step-by-Step Guide
How to migrate from Adobe Analytics to Customer Journey Analytics (CJA): upgrade paths Adobe documents, historical data, data views, reconciliation and cutover.

On this page
- Is Adobe Analytics still supported? When to move to CJA
- Adobe Analytics vs. CJA: the differences that shape the migration
- The upgrade paths Adobe documents
- How to migrate from Adobe Analytics to CJA, phase by phase
- 1. Inventory: which reports, segments and alerts are actually used
- 2. XDM schema, datastream and identities
- 3. Historical data with the Analytics source connector
- 4. Connection and data view: from eVars and props to dimensions
- 5. Migrating projects and components
- 6. Parallel run and reconciliation
- 7. Training and retiring Adobe Analytics
- Why don't Adobe Analytics and CJA numbers match?
- Risks and common mistakes when migrating to CJA
- Identities, consent and licensing in Mexico
- How we do it at WolfSellers
- Frequently asked questions about migrating from Adobe Analytics to CJA
- Does Adobe Analytics have an end-of-support date?
- Will I lose my Adobe Analytics history when I migrate to CJA?
- Do I need Adobe Experience Platform to use CJA?
- Can I run Adobe Analytics and CJA at the same time?
- Do my segments and calculated metrics move to CJA automatically?
- How long does an Adobe Analytics to CJA migration take?
- Related services
Migrating from Adobe Analytics to Adobe Customer Journey Analytics (CJA) isn't a change of reporting screen: it's a change of data model. Your data moves into Adobe Experience Platform (AEP) datasets with XDM schemas, eVars and props stop existing as a concept, and the logic you apply at collection time today —persistence, visits, marketing channels— is configured in a data view and calculated every time you run a report.
The pressure doesn't come from support: Adobe Analytics is still a current product, and its end-of-life notices cover features, not the product itself. The reason to migrate is what you need to analyze. If you want to see web, app, CRM, contact center or in-store activity in a single journey, that's CJA; if your analysis is web-only and working, you can plan without rushing.
CJA is the Adobe Experience Cloud analytics application that runs on AEP and lets you explore data from any channel, stitched by person, in Analysis Workspace; we cover the basics in our Customer Journey Analytics guide. At WolfSellers we implement Adobe Analytics, AEP and CJA. Here we walk through the path Adobe recommends, the process phase by phase, why the numbers don't match one to one, and what to watch for in Mexico.
Is Adobe Analytics still supported? When to move to CJA
Adobe updates the Adobe Analytics release notes several times a month; the current ones as of this writing cover October 2026 and were last updated on October 29. Their end-of-life section doesn't list a retirement date for the product, only for features:
- Adobe Analytics API 1.4 and WSSE authentication: shut down on August 31, 2026; integrations built on them no longer work.
- Legacy Report Builder: retired in June 2026; the new Report Builder works with both Adobe Analytics and CJA.
What Adobe does set is the direction: its upgrade guide recommends moving fully to CJA and turning off Adobe Analytics once you're comfortable with the data. Keeping both products is flagged as not recommended, because your contract would include both and that can cost more over time.
Move now if:
- You need to analyze journeys across channels —web, app, CRM, contact center, point of sale— with the person, not the device, as the unit of analysis.
- You already run, or plan to implement, AEP, Adobe Real-Time CDP or Adobe Journey Optimizer (AJO): according to Adobe, the Web SDK consolidates data collection for those products into a single implementation.
- You're hitting Adobe Analytics limits: up to 75 props and 250 eVars, Low Traffic or Uniques Exceeded labels, and configuration changes that only apply going forward.
Wait, or prepare more, if:
- You depend on features CJA doesn't have or handles differently: Activity Map isn't available yet, Contribution Analysis isn't supported, Data Feeds has no exact replacement, and alerts can't run hourly (in CJA they're daily, weekly or monthly).
- You don't have a customer identifier you can collect across all your channels. Without it, cross-channel analysis —CJA's primary use case, per Adobe— is limited.
- Your measurement is web ecommerce, it's in good shape and there's no cross-channel business case. Tuning what you have may pay off more; we explain how in our guide to measuring ecommerce with Adobe Analytics.
Adobe Analytics vs. CJA: the differences that shape the migration
| Topic | Adobe Analytics | Customer Journey Analytics |
|---|---|---|
| Data model | Report suites with fixed variables: up to 75 props, 250 eVars and custom events 1 to 1000 | AEP datasets with XDM schemas; no fixed limit on dimensions and metrics, including objects, lists and nested values |
| Sources | Mostly web and app, plus data import | Any AEP dataset in the same connection: web, app, CRM, contact center, point of sale |
| Unit of analysis | Visitors and visits | People, based on the person ID you choose in the connection. Visitors becomes People, Visits becomes Sessions and Hits becomes Events |
| Identity stitching | Cross-Device Analytics, limited to one report suite and a device graph | Field-based stitching or graph-based stitching on the AEP identity graph, depending on your CJA package |
| Where the logic lives | At collection: processing rules, VISTA rules, marketing channel rules, eVar persistence | At report time: data view and derived fields; Data Prep if you need to transform before storing |
| Configuration changes | Apply going forward | Also apply to historical data, with no reprocessing |
| Persistence | Set per eVar at collection | Per dimension, at report time: session, person (through the end of the reporting window), custom time up to 90 days, or until a metric occurs |
| Exports | Data Feeds and Data Warehouse | Full Table Export (the evolution of Data Warehouse), AEP dataset export and the BI extension; no exact Data Feeds replacement |
The row teams underestimate is the logic one: in Adobe Analytics, a processing rule is baked into the data; in CJA it lives in the data view, and two data views can apply different rules to the same data.

The upgrade paths Adobe documents
Adobe documents several upgrade paths and rates each one by level of effort and long-term viability. The recommended one combines a new Adobe Experience Platform Web SDK implementation with the Analytics source connector, which brings in historical data and lets you compare data side by side.
| Path | Effort and viability, per Adobe | When it fits |
|---|---|---|
| New Web SDK + Analytics source connector (recommended) | High / high | You want your own schema, history in CJA and a comparison period, whatever your current implementation |
| New Web SDK, no connector | High / high | You don't need Adobe Analytics history inside CJA |
| Migrate your current implementation to the Web SDK | Moderate / high | You're on AppMeasurement or the Analytics extension and want intermediate milestones: the Web SDK feeds Adobe Analytics first, then AEP. Your variables travel in data.__adobe.analytics and each field is mapped to XDM in the datastream |
| Configure the Web SDK you already use | Low / high | Your Adobe Analytics already runs on the Web SDK: you add AEP as a service in the datastream and review the schema |
| Analytics source connector only | Low / low | You want data in CJA fast. Adobe doesn't recommend it long term: higher latency, a schema with more than a thousand fields using eVar and prop naming, and a harder path off Adobe Analytics |
To choose based on your own setup, CJA includes the Customer Journey Analytics Upgrade Guide: Workspace tab, Upgrade to Customer Journey Analytics in the left panel. It asks about your implementation, the features you use and your goals, then generates tailored steps as a shareable link or a .csv file. If you don't have CJA access yet, your Adobe account team can complete it with you.
How to migrate from Adobe Analytics to CJA, phase by phase
This is how we turn Adobe's process into seven phases; the first three decide whether the rest goes well.
1. Inventory: which reports, segments and alerts are actually used
Analytics Inventory (Admin menu in Adobe Analytics, for product admins) shows how many projects, segments, calculated metrics, base report suites and users you have. Adobe positions it for deciding what to migrate, what to clean up first and in what order. Add real usage to that count:
- Projects and scheduled reports that someone actually opens or receives.
- Critical segments and calculated metrics, with their definitions and the fields they need, as Adobe advises.
- Alerts, especially hourly ones.
- Integrations: Data Feeds, Data Warehouse, Report Builder, APIs, Analytics for Target (A4T) and Audience Manager.
If nobody uses it, it doesn't get migrated.
2. XDM schema, datastream and identities
Adobe recommends a schema tailored to your organization instead of the Adobe Analytics schema, which keeps you thinking in props and eVars. If you'll use CJA with Real-Time CDP, enable Profile on the schema. Then come the dataset, the datastream with AEP as a service, and the Web SDK, through tags, manually or via API.
This is where identity gets decided. Adobe asks that the person ID —a customer number, account ID or hashed email— exist in every source, be populated on every row, contain no raw personal data and use the same format everywhere. Stitching is case-sensitive: Bob and BOB are two people. More in our guide to data governance in AEP.
3. Historical data with the Analytics source connector
The connector creates one dataflow per report suite and copies its data into an AEP dataset in XDM format. Per Adobe:
- History: 13 months by default in production sandboxes and 3 in non-production ones. More than 13 months requires an additional SKU.
- Timing: a backfill of fewer than 10 billion events takes under 4 weeks.
- What it copies: each hit after processing rules and before visit- and visitor-level processing, so it doesn't include, for example, visit number. Timestamps arrive at the second.
- How long it lasts: the history exists as long as the connector does. If you stop collecting with Adobe Analytics, what was already copied stays.
- Multiple report suites: analyzing more than one requires the CJA Select package. If an eVar means different things in different report suites, align them or use Data Prep, or they'll blend into one dimension.
The alternative is to keep Adobe Analytics running for a set period and query history there (Adobe's example is one year); that data won't be in AEP.
4. Connection and data view: from eVars and props to dimensions
The connection combines your datasets —Web SDK, connector and other channels— and defines the person ID; CJA ignores records with no person ID or timestamp. The data view is where Adobe Analytics logic gets rebuilt:
| In Adobe Analytics | In the CJA data view |
|---|---|
| eVar expiration and allocation | Persistence per dimension: allocation (most recent, original, all, first known or last known) and expiration |
| Visit definition | Session settings: inactivity timeout and a metric that starts a new session |
| Classifications | Lookup datasets |
| Marketing channels | Derived field using the marketing channel function template |
| Merchandising eVars | Binding dimensions and binding metrics |
| Virtual report suite | Another data view on the same connection |
All of it is retroactive: change a dimension's persistence and historical data is recalculated at report time.
5. Migrating projects and components
Adobe Analytics includes a component migration tool (Admin > All admin > Data configuration & collection > Component migration), also available via API. It re-creates your projects in CJA, maps each report suite's dimensions and metrics to a data view, and re-creates segments, date ranges and calculated metrics from that mapping, up to 20 projects at a time. Before you use it:
- Mappings are org-wide: they apply to everything migrated afterward, regardless of who migrates it. Adobe recommends agreeing on them before the first project.
- With Web SDK data, everything is mapped manually. Even with connector data, some dimensions and metrics always need manual mapping, such as visit number, time spent, bounces and bounce rate.
- What doesn't carry over: sharing, curation, annotations, folders, tags, favorites and schedules.
- Unsupported panels: A4T, segment comparison, page summary and Contribution Analysis can make the migration fail or cause errors. Remove them first.
6. Parallel run and reconciliation
Adobe recommends keeping Adobe Analytics running for a while after CJA starts collecting data, to compare side by side, and not turning it off until you're comfortable with the numbers. Reconciliation gets its own section below.
7. Training and retiring Adobe Analytics
Workspace looks similar in both products, but the model changes. Adobe suggests giving users 3 to 6 months, leaning on champions among your Adobe Analytics power users and running hands-on training on data model differences. Projects can't be shared between Adobe Analytics and CJA.
Per Adobe, retirement takes three steps:
- Stop Adobe Analytics data collection: AppMeasurement, the tags extension, the API or a third-party tag manager.
- Remove Adobe Analytics as a service from the datastream once users are working in CJA.
- Remove the connector once the history you've built with the Web SDK is enough.
We show what you can analyze afterward in Customer Journey Analytics analysis examples.
Why don't Adobe Analytics and CJA numbers match?
According to Adobe, differences are normal and have known causes. These are the ones it documents for connector data, plus one that comes from comparing against a new implementation:
| Difference | Why it happens | What to check |
|---|---|---|
| Different data on each side | The connection may include another report suite, other channels or person-stitched data | Compare the same report suite and the same combination of datasets |
| Time zone and calendar | Each product has its own settings | Match them if you want parity |
| Visits vs. sessions | Adobe Analytics computes visits at processing time; CJA computes sessions at report time. Connector datasets don't include visits | The data view's session settings |
| Persistence and attribution | In CJA they're calculated at report time; a variable with a long expiration in Adobe Analytics won't behave the same | Each dimension's allocation and expiration; Adobe recommends "most recent" allocation in Adobe Analytics |
| Data Sources | Data Sources uploaded to a report suite don't reach CJA through the connector | Leave them out of the comparison |
| Excluded rows | The connector skips excluded hits, non-hit rows and streaming media keep-alive hits; CJA ignores rows with no person ID or timestamp | Count records using Adobe's method |
| Same-second events | Connector data carries second-level timestamps | Use the Web SDK, with millisecond precision, when order matters |
| Privacy requests | Adobe Analytics obfuscates identifiers and keeps the hit; AEP deletes the rows | Expect differences after processing requests |
| Two implementations | Compared with AppMeasurement, a new Web SDK also reflects tagging differences | Validate tagging before metrics |
To validate volume, Adobe documents a method: count records per day in AEP with Query Service and compare them with the rows of a Data Feed for the same period, excluding excluded hits, Data Sources rows and keep-alive hits. If volume matches, what's left are configuration differences, not lost data.

Risks and common mistakes when migrating to CJA
- Keeping the connector as your long-term implementation. Adobe rates it lowest for viability: data reaches CJA in under 3.75 hours without stitching and under 7 with stitching, and you stay tied to Adobe Analytics.
- Copying eVars into XDM one by one. Replicating eVar1 through eVar250 carries the old model's problems forward.
- Mapping components project by project. Mappings are org-wide, so one isolated decision affects every migration after it.
- Demanding one-to-one parity. Without agreeing up front on acceptable differences per KPI, the parallel run never ends.
- Turning off Adobe Analytics or the connector too early. The connector's history goes with it, and features like Data Feeds have no exact CJA replacement.
- Inconsistent identifiers. Mixed casing, different formats or unhashed personal data break identity stitching.
- Forgetting integrations. Reports pulled through API 1.4 (already shut down), legacy Report Builder workbooks, hourly alerts, A4T panels and Data Feeds exports.
- Ingesting too much. CJA entitlements are measured in rows of data available for analysis (daily average), and Adobe monitors usage. Set retention from the start: CJA offers a rolling data window per connection, and for the connector Adobe recommends setting dataset retention and starting with the data lake only before enabling Profile.
Identities, consent and licensing in Mexico
Stitching identities across channels means processing personal data, and Adobe asks you to comply with applicable laws, including obtaining the necessary permissions, before enabling stitching. In Mexico that runs through the Federal Law on the Protection of Personal Data Held by Private Parties (LFPDPPP); in the US or Canada, the same check applies under the privacy laws that govern you. This isn't legal advice: confirm it with your legal team.
- Consent (art. 7). As a general rule, tacit consent is valid: the individual had access to the privacy notice and didn't object. Financial or asset data require express consent, and sensitive data require express, written consent (art. 8).
- Purposes (arts. 11 and 15). Processing is limited to the purposes stated in the privacy notice; using data for a different purpose requires obtaining consent again. Check that your notice covers the analysis you'll run when you combine channels.
- Minimization. Adobe recommends that the person ID contain no raw personal data: hash anything sensitive.
Privacy handling migrates too. For connector data, requests are processed with Adobe Experience Platform Privacy Service, and AEP doesn't copy Adobe Analytics privacy labels: identities and labels have to be configured in the schema. Switching the privacy source is done per dataflow and can't be reversed once started.
Licensing. WolfSellers doesn't sell Adobe licenses: Adobe Analytics, CJA and AEP are contracted directly with Adobe. Your CJA package determines the stitching method (field-based from Select, graph-based from Prime), the stitching backfill and how many datasets can be stitched; more than 13 months of history requires an additional SKU, and keeping both products means having both in your contract.

How we do it at WolfSellers
We start with an assessment of your Adobe Analytics setup: real usage of projects, segments, metrics and alerts; implementation type and report suites; the identifiers available in each channel; and integrations that depend on Data Feeds, APIs or Report Builder. That tells us whether migrating now makes sense and which of Adobe's upgrade paths fits you.
Then we design the XDM schema, identities and data view; implement the Web SDK and the connector; agree on component mapping before the first project; run the parallel period with documented reconciliation per KPI; and train your champions before recommending that Adobe Analytics be retired. We don't give generic timelines: we estimate them after the assessment.
We cover this through our Adobe Analytics, Adobe Experience Platform and Data Engineering & Integrations services. If you'd like us to review your implementation, get in touch.
Frequently asked questions about migrating from Adobe Analytics to CJA
Does Adobe Analytics have an end-of-support date?
Adobe doesn't publish a retirement date for Adobe Analytics in its release notes: its end-of-life notices cover features, such as API 1.4, shut down on August 31, 2026. It does recommend moving fully to CJA and turning off Adobe Analytics once you're comfortable with the data.
Will I lose my Adobe Analytics history when I migrate to CJA?
Not if you plan for it. The Analytics source connector brings 13 months of history by default in production sandboxes, and more with an additional SKU; that history exists as long as the connector does. You can also keep Adobe Analytics running for a while and query it there.
Do I need Adobe Experience Platform to use CJA?
CJA runs on AEP: it analyzes Experience Platform datasets, and according to Adobe your CJA entitlement lets you ingest data into AEP. Products like Real-Time CDP or Journey Optimizer are licensed separately; you need them, for example, to publish audiences from CJA.
Can I run Adobe Analytics and CJA at the same time?
Yes, and Adobe recommends it during the transition, to compare data and keep history. What it doesn't recommend is keeping both permanently, because your contract would include both products.
Do my segments and calculated metrics move to CJA automatically?
Not as they are: they aren't compatible with CJA. The component migration tool re-creates the segments, date ranges and calculated metrics in the projects you migrate, based on how you map dimensions and metrics to your data view. If your data comes through the Web SDK, that mapping is manual.
How long does an Adobe Analytics to CJA migration take?
It depends on the size of your implementation and how many sources you combine, so we don't give a generic timeline. Two reference points from Adobe: a backfill of fewer than 10 billion events takes under 4 weeks, and it suggests giving users 3 to 6 months to get familiar with CJA.
Related services
If this topic is relevant to your business, these services from WolfSellers can help you implement it:


