AA → CJA Migration: Reset Your Expectations Before You Start

OVERVIEW

After leading enterprise Adobe Analytics to Customer Journey Analytics migrations, the pattern is consistent: teams underestimate the architecture gap, over-rely on familiarity with AA, and treat a fundamentally different platform as if it were an upgraded version of the same tool. CJA is not AA with more features. It is a different data philosophy built on AEP, and the gap shows up exactly where you least expect it.

Why This Is Not a Lift-and-Shift?

Adobe Analytics operates on a session-based, server-side data model. Reports and segments are built around visits, hits, and eVars within a familiar workspace structure. Customer Journey Analytics operates on Adobe Experience Platform (AEP), a schema-first, identity-stitched, event-driven data lake where everything including metrics, sessions, and time-spent calculations must be either inherited from your data architecture or rebuilt from scratch.

The migration path from AA to CJA involves re-mapping your tagging strategy, restructuring data ingestion into AEP datasets, redefining your identity graph, and rebuilding many calculated metrics your stakeholders consider standard. None of that is a copy-paste exercise.

COMMON FAILURE MODE

Teams that scope the migration as 'move our AA reports to CJA' consistently hit cost overruns, performance issues, and stakeholder trust damage during UAT, not during development. The problems are invisible until the data lands in the new environment.

The four gaps that catch teams off guard:

• New Data Model: CJA ingests from AEP datasets via XDM-based schemas. Your AA data model (props, eVars, events) does not port directly. Every dimension and metric requires deliberate re-mapping.
• Identity Stitching Strategy: CJA's cross-channel identity stitching is a capability AA never had. It requires a defined identity graph. Without this, your person-level analytics will not reflect expected fidelity.
• Compute for Derived Datasets: Sessionization, transformations, and derived metric datasets require Data Distiller compute, a licensed capability that must be sized before deployment, not after go-live.
• Metric Rebuild Required: Standard AA metrics like Time Spent on Page and Visit-based segments do not exist natively in CJA. They are created through calculated metrics and session-level logic during implementation.

Data Distiller and Compute Planning Are Underestimated

Of all the hidden cost drivers in an AA to CJA migration, Data Distiller compute is the most consistently underscoped. Data Distiller is AEP's query service layer. It enables SQL-based transformation of raw event data, creation of derived datasets, and sessionization logic that CJA workspaces depend on for accurate, low-latency reporting.

The compute required is not flat. It scales with:

• Volume of raw data being transformed
• Complexity of session logic
• Refresh frequency of derived datasets
• Number of concurrent workloads running against the data lake

WHAT DATA DISTILLER POWERS

Sessionization logic | Derived dataset creation | Custom attribution models | Aggregated reporting views | SQL-based metric transformations 

If compute requirements are not scoped during presales, tied to your specific use cases, data volumes, and refresh cadences, you will encounter one of two outcomes after go-live: degraded query performance or unexpected licensing overage. Both damage client trust. Neither is recoverable without re-architecture.

How to Scope Compute Correctly

• Catalog every derived metric and sessionized dataset you currently use in AA that has no direct CJA equivalent
• Estimate event volume by data source: web, mobile, CRM, offline, and model daily ingestion rates
• Define refresh cadence for derived datasets: real-time, hourly, daily
• Engage Adobe Solution Consultants early to validate architecture and sizing estimates against your ingestion patterns
• Include compute cost estimates in the presales SOW, not as a post-contract addendum

Presales Scoping Makes or Breaks Execution

Adobe Solution Consultants are highly capable at CJA architecture and sizing guidance. This is not the bottleneck. The bottleneck is the depth of engagement at the presales stage.

Enterprise migration projects often treat Adobe's consulting resources as post-contract onboarding support. The discovery conversation happens after signatures, which means the architecture decisions that determine cost, performance, and feasibility are made under time pressure, with incomplete information, against a scope defined without their input.

"Under-scope presales and you inherit the problem downstream. The architecture gets locked in, the client has expectations, and you're solving the wrong problem at go-live."

The corrective is structural. Adobe Solution Consultants should be at the presales scoping table, before the SOW is written, before the timeline is set, and before stakeholder expectations about parity and timelines are communicated.

Presales Scope Checklist: AA to CJA

Metric Parity Gaps Will Surprise Your Stakeholders

The metric parity conversation is the most operationally dangerous part of an AA to CJA migration, not because the gaps are insurmountable, but because they surface at the worst possible time if not handled proactively.

CJA is not Adobe Analytics. Stakeholders who have built reporting workflows, executive dashboards, and QBR decks on specific AA metrics will not have those metrics available out of the box in CJA. Some need to be rebuilt as calculated metrics. Some require session-level logic. Some require a new definitional framework entirely.

OPERATIONAL RULE

Have this conversation before requirements sign-off, not during UAT. A stakeholder discovering that 'Time Spent on Page' does not exist in their new environment is a relationship problem, not a technical one. Technical problems can be solved. Relationship problems in UAT are harder to recover from.

The right approach is a formal Metric Parity Audit conducted during presales. Every metric currently used in AA reporting should be classified into one of three states:

Metric Parity Classification Table

The Migration Planning Framework

CJA gives you significantly more power than Adobe Analytics. Cross-channel person-level journeys, real-time derived metrics, AI-assisted anomaly detection, and direct AEP audience activation are all capabilities that do not exist in the AA environment. But these capabilities only materialize if the data and compute layers are planned correctly from the start.

The framework that consistently works follows three sequential planning gates before technical implementation begins:

Gate 1: Presales Architecture Review

Before the SOW is signed. Adobe Solution Consultants, implementation lead, and client analytics owner in the same room. Output: data architecture decision log, identity strategy, Data Distiller sizing estimate, and preliminary metric parity classification.

Gate 2: Metric Parity Audit

Before requirements sign-off. Every metric in active use mapped to its CJA equivalent or rebuild path. Stakeholder sign-off on gap acknowledgment. Creates a traceable requirements document for the build phase and prevents UAT surprises.

Gate 3: Data Validation Framework

Before launch. Side-by-side comparison of AA and CJA metric outputs for an agreed validation period. Variance thresholds defined in advance. Stakeholder alignment on what constitutes acceptable variance given definitional differences between the two platforms.

WHAT AXENO BRINGS TO CJA MIGRATIONS

With 100+ enterprise Adobe deployments across Fortune 500 organizations, Axeno applies this framework as a standard engagement model, not a custom add-on. The three gates are not optional. They are what separates migrations that go live cleanly from migrations that go live with open issues.