Adobe confirmed the 1.4 API and WSSE authentication end-of-life on August 12, 2026, shutting down all legacy endpoints permanently with no grace-period extensions for enterprise customers. Simultaneously, every major Adobe analytics product announcement since June 2025, including Marketing Campaign Analytics, Content Analytics, and the Data Insights Agent, ships exclusively to Customer Journey Analytics (CJA). Organizations still running Adobe Analytics (AA) as their primary analytics layer are now operating on a deprecated infrastructure with no path to new feature parity.
The CJA migration conversation in most practitioner circles stays at the level of tooling: which component migration tool UI steps to follow, which Workspace projects transfer cleanly, and which checklist items to sequence. That framing misses the actual problem. The decisions that determine whether a migration succeeds or stalls are architectural, not procedural. Person ID strategy, Data View modeling, and report suite consolidation logic each require deliberate choices that ripple through the entire downstream measurement system. Getting those wrong creates technical debt that a component migration tool cannot resolve.
This piece works through those decisions in the order they need to be made, with specific guidance on where the irreversible choices sit, and which ones are more forgiving than older documentation suggests.
Why the migration timeline is no longer yours to choose
The framing that most analytics teams apply to CJA migration is voluntary modernization: a platform upgrade to pursue when engineering capacity allows, after the current sprint backlog clears, sometime in the next planning cycle. As of September 25, 2026, that framing is no longer accurate.
Five separate Adobe infrastructure retirements ran between January and August 2026. Legacy SSO, the LiveStream API payload format, TLS 1.2 cipher suites, Report Builder in its legacy form, and the v1.4 API with WSSE authentication each required engineering attention. Each consumed capacity that analytics engineering teams had planned to allocate toward migration work. Teams entering 2026 with a CJA migration on the roadmap found themselves in mandatory remediation on legacy dependencies before they could move forward.
The August 12, 2026 1.4 API shutdown is the most consequential of these. Any integration calling the 1.4 API endpoints stopped receiving data that day. Integrations must now migrate to the Adobe Analytics 2.0 API with OAuth-based authentication via the Adobe Developer Console. That is a non-trivial migration for organizations with internal reporting pipelines, third-party connectors, or custom-built data extraction jobs that relied on the 1.4 endpoints. The work is not optional and there is no fallback.
What makes the timing particularly compressive is that the 1.4 EOL work and the CJA migration work draw from the same engineering pool but require different skills and context. Teams that spent the first half of 2026 remediating API authentication dependencies are starting CJA migration planning later than they intended, often significantly later.
The product roadmap makes the pressure structural rather than temporary. As of the date of writing, every major Adobe analytics capability released since June 2025 is CJA-only. Marketing Campaign Analytics, Adobe CX Analytics, the Data Insights Agent, Intelligent Captions, Guided Analysis, Content Analytics, and the CX Enterprise Coworker agent all ship exclusively to CJA, with no equivalent investment in Adobe Analytics (Focus GTS, 2026-06-24). Adobe has not published a formal sunset date for Adobe Analytics itself, and practitioners including Focus GTS and Adswerve consistently note that no public EOL date exists. Verify that position with your Adobe account team quarterly, because the product gap is widening with each release cycle.
The practical consequence is a bifurcation: CJA is where Adobe's product roadmap is being built, and Adobe Analytics is where organizations are currently running. The longer a team defers the migration architectural decisions, specifically Person ID strategy, and Data View modeling, the more compressed the execution timeline becomes relative to a product roadmap that is not waiting.
Typical CJA migrations run 12 to 24 months for full AA decommissioning with historical data continuity (Focus GTS, 2026-06-24). At least one partner, Comwrap Reply, markets a 6 to 8 week rapid deployment. That timeline applies to greenfield or single-report-suite scenarios without historical continuity requirements. It is not a representative figure for organizations running multi-suite AA implementations with complex classification hierarchies and calculated metric dependencies. The difference in scope is significant enough that conflating the two figures creates planning risk.
If your team has not yet begun Person ID design or Data View modeling, you are already operating on a compressed timeline.
The three decisions that determine whether your migration succeeds or stalls
Person ID strategy
Person ID is the most consequential architectural decision in a CJA migration and the one most likely to be underspecified in early planning. In Adobe Analytics, visitor identification is handled by the ECID (Experience Cloud ID), or a custom visitor ID, and it is largely implicit: the system uses what it has. CJA requires you to make the identity model explicit by selecting which field, or fields, in your dataset serves as the Person ID for each connection.
The decision sounds straightforward until you map it against the actual data. Multi-report-suite organizations typically find that visitor identification was inconsistent across suites: one suite was implemented against authenticated sessions only, another against all sessions including anonymous, and a third against a custom prop that was repurposed across implementation generations. When those suites are being consolidated into a single CJA connection, the Person ID field needs to be consistent across all contributing datasets. If it is not, the identity stitching produces phantom persons: users who appear as multiple distinct individuals because their identifier differs across the data sources being joined.
The specific failure mode to watch for is the difference between transient and persistent identification. If your Person ID is session-based in some data sources and persistent-across-sessions in others, the stitching logic will produce visitor counts that are neither comparable to historical AA figures nor internally consistent within CJA. This is not a solvable problem post-migration without re-ingesting data.
CJA offers two stitching methods: field-based stitching, which uses a persistent identifier you specify, and graph-based stitching, which leverages the Adobe Experience Platform (AEP) identity graph. Graph-based stitching handles unauthenticated-to-authenticated transitions more cleanly, but it requires that your identity graph in AEP is actually populated, and maintained. Organizations that have AEP deployed with a functioning identity graph can lean on graph-based stitching to resolve the cross-device and cross-session identity problem. Organizations that are migrating to CJA without a mature AEP identity graph need to design a persistent identifier strategy before attempting to set up their connection.
The irreversibility concern with Person ID is real but often overstated. You can change your Person ID field after the connection is established, but doing so triggers a re-processing of historical data, which takes time, and breaks any historical trend lines built on the previous Person ID definition. In practice, changing Person ID is painful enough that teams treat it as permanent. Design it deliberately before you create the connection.
For organizations with multiple report suites and inconsistent visitor identification history, the correct sequence is:
- Audit each report suite for how visitor identification was implemented, including which implementation generations used which ID fields, and whether authenticated vs. anonymous sessions were handled differently.
- Identify the highest-fidelity persistent identifier available across all contributing data sources, typically hashed email for authenticated sessions.
- Design the unauthenticated identity strategy separately: either accept anonymous session fragmentation, implement field-based stitching with a cookie-based persistent ID, or invest in the AEP identity graph before migration.
- Document the Person ID decision and its rationale before creating the CJA connection.
This audit is a prerequisite to accurate scoping. Teams that skip it tend to discover mid-migration that their report suites were implemented against incompatible identity models, which adds months to the timeline.
Data View modeling
The second architectural decision is how to model your Data Views. A Data View in CJA is the configuration layer that determines what dimensions and metrics users see when they build analyzes, how components are labeled, and formatted, and what attribution and lookback window settings apply. It is roughly analogous to a virtual report suite in AA, but with significantly more flexibility, and significantly more surface area for decisions.
The eVar/prop taxonomy that most Adobe Analytics implementations built up over years was designed for a session-based, page-view-centric data model. CJA's event-based model does not have eVars or props. It has dimensions and metrics derived from the XDM schema fields in your datasets. When you migrate from AA to CJA, you are not transporting eVars into a new container: you are deciding which XDM fields map to which analysis dimensions, and whether the business logic that was embedded in eVar processing rules gets rebuilt as derived fields, as reclassification logic, or as calculated metrics.
The three categories of AA behavior to work through systematically are:
Behaviors that map cleanly. Standard page tracking, event-based conversion tracking, and most classification hierarchies translate reasonably well if the underlying data is in the XDM schema. These are the components the migration tool handles competently.
Behaviors that require rebuild as derived fields. Processing rules logic, merchandising eVar binding, and any prop/eVar that captured derived or computed values rather than raw field values need to be rebuilt in the Data View as derived fields. This is deliberate work, not automated migration. The complexity scales with how much business logic was embedded in AA processing rules rather than in the data layer.
AA behaviors with no CJA equivalent requiring deliberate abandonment. Participation allocation (crediting all events in a session to a single dimension value) does not exist in CJA as a native attribution model. Pathing reports in AA behave differently from flow visualizations in CJA. Some segment definitions built around AA's visit container logic do not have a direct translation into CJA's event, session, and person container model. These require an explicit decision: rebuild with a different approach, or document that the historical report no longer exists in the new system.
The abandonment decisions are where migrations stall. Stakeholders who depend on specific AA reports often treat those reports as requirements that must be preserved exactly. When the underlying behavioral model is incompatible, the migration team gets stuck in a loop of trying to reproduce reports that cannot be reproduced without distorting the new data model. The better approach is to document which AA reports have no CJA equivalent, explain the architectural reason, and propose the closest CJA equivalent in the same conversation. Presenting abandonment as a choice with a rationale rather than a migration failure keeps the project moving.
Data View modeling is also where you make decisions about attribution. CJA allows you to set attribution models at the component level within the Data View, rather than at the report level. That flexibility is genuinely useful but also means you need a governing policy: which attribution model applies to which dimensions by default, when override models are permitted, and how those decisions are documented so they can be maintained. Without that policy, different analysts apply different attribution models to the same dimension, and produce results that cannot be reconciled.
Report suite consolidation
The third decision, consolidation of multiple report suites into a unified CJA connection, is where identity complexity compounds.
Adobe Analytics customers with large implementations typically accumulated multiple report suites over time: separate suites for different brands, regions, or product lines, sometimes separate suites for mobile, and web properties on the same product, and occasionally separate suites that reflected organizational changes rather than measurement requirements. The constraint is that combining report suites with inconsistent event taxonomies and incompatible visitor identification creates a dataset that requires significant data cleaning and restructuring work before it is analytically useful.
The component migration tool cannot solve this. It migrates Workspace projects and components from a single report suite at a time. The consolidation of multiple suites into a coherent CJA dataset is schema harmonization work that happens at the dataset and Data View layer, before analysts ever open the tool.
For multi-suite organizations, the correct sequence is to audit cross-suite schema consistency before beginning Data View design. The audit outputs a gap analysis: which dimensions are consistently named and defined across suites, which require harmonization, and which are suite-specific with no cross-suite equivalent. That gap analysis becomes the input to Data View design decisions and to the estimate of how much rebuild work versus automated migration applies to this specific implementation.
This is also the decision that most directly determines timeline. A single-suite implementation with a clean XDM schema and a consistent Person ID field can reach a working CJA state in 6 to 8 weeks. A multi-suite implementation with heterogeneous schemas, mixed identity models, and classification hierarchies built up over eight years runs closer to the 12 to 24 month range, and the longer estimates apply when historical continuity is a hard requirement.
What the component migration tool actually does, and what it cannot do
As of September 2025, Adobe released meaningful improvements to the component migration tool that invalidate a significant amount of practitioner guidance written before that date (Adobe Experience League release notes, 2025-09-14). Two changes are directly relevant to migration planning.
First, the tool now supports batch migration of up to 20 projects simultaneously. The previous behavior was one project at a time, which made large-scale Workspace migration a manual, sequential process. Batch migration reduces the mechanical effort on large projects materially.
Second, dimension, and metric mappings can now be updated on subsequent migration runs. Prior to September 2025, the mapping decisions made during an initial migration run were permanent: if you mapped an AA dimension to the wrong CJA component, you could not correct it through the tool without re-migrating from scratch. Multiple practitioner posts and some Adobe documentation written before September 2025 still state that mappings are permanent. That is no longer true. Verify source dates on any guidance you are referencing: pre-September 2025 sources may accurately describe the old behavior while incorrectly implying it is current.
Adobe also released a dedicated CJA Migration API in 2025, enabling programmatic migration of Adobe Analytics projects, and components (Adobe Experience League, 2025). This API matters for large implementations where UI-based migration at any batch size is still impractical. The Component Migration API requires that dimensions and metrics be mapped first via the Dimensions Mappings or Metrics Mappings APIs before component finalization can proceed. That prerequisite is significant: it means programmatic migration still requires a planned mapping exercise before automation can handle the bulk of the work. The API enables scale; it does not eliminate the mapping design step.
What the component migration tool and the Migration API explicitly do not cover:
Processing rules logic. Any business logic encoded in AA processing rules needs to be rebuilt as derived fields in the Data View. The tool migrates project components; it does not migrate the processing layer that generated the values those components reported on.
Classification hierarchies. AA classification sets and SAINT classifications do not migrate automatically. The data they contain needs to be restructured as lookup datasets in AEP and mapped through the connection before it appears as usable dimensions in CJA.
Calculated metric dependencies. Calculated metrics that reference AA-specific metrics or use functions not available in CJA require manual rebuild. The tool handles the component migration; it flags incompatible calculated metrics but does not reconstruct them.
Segment logic using AA-specific containers. Segments built on hit, visit, or visitor container logic in AA need to be reviewed and rebuilt using CJA's event, session, and person container model. The containers behave differently enough that direct translation frequently produces incorrect results without manual review.
Data feeds and data warehouse outputs. If your organization uses AA Data Feeds or Data Warehouse exports as inputs to downstream systems, those are separate migrations. The component migration tool operates at the Workspace project level; it does not touch data export pipelines.
The practical planning implication is that a realistic inventory of migration scope has three distinct components: the automated migration work the tool handles competently, the rebuild work that requires analyst, or engineering effort, and the abandonment decisions that require stakeholder alignment. Most organizations underestimate the second and third categories because the tool exists and appears to handle the migration comprehensively. It handles one layer of the migration. The rest is deliberate architecture work.
Data ingestion: Analytics Source Connector vs. Web SDK, and why the choice matters for long-term architecture
The data ingestion decision is the most technically consequential choice in the migration and the one where Adobe's own positioning and practitioner guidance diverge most clearly.
The Analytics Source Connector streams data from an Adobe Analytics report suite into AEP, making that data available as a dataset in a CJA connection. It is the fastest path to getting historical AA data into CJA, which makes it a practical choice for parallel running, and historical backfill. Organizations that need to maintain historical trend continuity while the CJA implementation matures use the Analytics Source Connector to bridge the gap: run both AA and CJA simultaneously, validate that CJA figures reconcile with AA figures on agreed dimensions, and then cut over when confidence is sufficient.
The limitation of the Analytics Source Connector as a permanent solution is its schema. Data ingested via the Source Connector carries the AA report suite schema, including the eVar/prop structure. That schema does not match the XDM schema that a natively instrumented Web SDK implementation produces. If you run CJA long-term on Analytics Source Connector data, you are essentially running on the AA data model inside CJA's analysis environment. You get CJA's cross-channel joining capability and attribution flexibility, but your event taxonomy is still constrained by how your AA implementation was built. The full benefit of CJA's architecture, particularly the ability to apply derived fields, and work with a clean XDM schema, is only available when the underlying data is coming through a properly designed Web SDK implementation.
Adobe increasingly positions the Web SDK as the preferred forward-looking collection method, while practitioners differ on how strongly to state that the Analytics Source Connector should not be the permanent solution. Verify current Adobe guidance with your account team before committing to either as a long-term data collection strategy. What is settled is that the two produce different schemas and that schema decision has downstream consequences for how much Data View rebuild work is required as the implementation matures.
One important clarification on EOL scope: Adobe's April 2026 confirmation in the Experience League community explicitly states that the Data Insertion API is not affected by the 1.4 API end-of-life (Adobe Experience League Community, 2026-04-21). Organizations using the Data Insertion API for server-side or batch data collection into AA do not face the same August 12, 2026 forcing event as organizations using 1.4 API endpoints for reporting or data extraction. Adobe recommends migrating to the Bulk Data Insertion API over time, but the Data Insertion API remains supported.
The Streaming Media XDM field path migration is a closed forcing event that is now fully resolved, but its history is instructive. Customers who implemented the Analytics Source Connector to collect Streaming Media data into AEP before April 22, 2025 were required to migrate their configurations to new XDM field paths by the end of July 2025. As of July 31, 2025, the deprecated field paths were removed from the AEP Schema UI entirely (Adobe Experience League, 2025-07-31). Organizations that did not complete the migration lost Streaming Media data in CJA. The pattern is consistent with the broader infrastructure retirement cadence: Adobe sets deadlines, removes the legacy infrastructure, and does not maintain backward compatibility after the EOL date. The 1.4 API shutdown followed the same pattern. Plan accordingly for any future deprecation notices.
For organizations designing the data ingestion architecture now, the practical recommendation is to treat the Analytics Source Connector as the historical backfill, and parallel running mechanism, and plan the Web SDK implementation as the target state for ongoing data collection. The timeline for those two tracks does not have to be simultaneous: most teams run the Source Connector for 12 to 18 months while the Web SDK implementation is built, validated, and cut over. What matters is that the Web SDK implementation is on the roadmap with a specific delivery date, not treated as an eventual improvement that does not have committed engineering resources.
Measuring migration success: data quality, adoption, and the signals that tell you the transition is actually complete
The technical milestone of "CJA is live and receiving data" is not the same as a successful migration. In 2025, 64% of organizations cited data quality as their top data integrity challenge, and GNW Consulting identifies this as the primary reason CJA adoption stalls post-implementation even when the technology is in place. The pattern is consistent: the technical migration completes, CJA is accessible, and then analysts revert to AA because they do not trust the CJA figures or because the CJA reports do not match the ones they have been using for years.
Both of those problems are addressable, but they require deliberate measurement, and intervention, not just technical delivery.
Data quality validation
The reconciliation step is the one most often compressed when migration projects run late. CJA figures will not match AA figures exactly, and they should not: the two systems have different attribution models, different identity resolution methods, and different session definitions. The goal of reconciliation is not identical numbers. The goal is understanding the specific, documented reasons for each category of discrepancy.
A useful reconciliation framework runs at three levels:
Volume checks. Total sessions, pageviews, and conversion events should be in the same order of magnitude for the same date range. Differences above 10 to 15% in either direction warrant investigation before any discrepancy is explained away as "expected model differences."
Dimension-level checks. For key dimensions, such as acquisition channel, product category, and authenticated vs. unauthenticated sessions, compare AA, and CJA distributions. Discrepancies that concentrate in specific dimension values usually point to schema mapping issues or Person ID inconsistencies rather than general model differences.
Metric-level checks. Revenue figures, goal completions, and calculated metrics that feed reporting or paid media optimization require specific reconciliation documentation. If CJA and AA produce different revenue numbers, stakeholders need a documented explanation before CJA figures can be used in decisions that affect budget allocation.
The shared metrics and dimensions library released by Adobe in 2025 is directly relevant here. It allows teams to define components once at the connection level and deploy them consistently across all Data Views within that connection (Adobe, 2025). That consistency is the technical prerequisite for data quality at scale: if different Data Views define the same metric differently, reconciliation becomes an ongoing manual process rather than a one-time validation exercise.
Adoption and proficiency
The Forrester Total Economic Impact study on Adobe Ultimate Success found that organizations combining desk-side coaching and workshops alongside formal training reached full CJA proficiency approximately 30% faster than training-only approaches: nine months instead of twelve (Forrester TEI study, cited by Adswerve, 2026-07-28). That difference is not trivial in a migration context where the business is operating on two analytics systems simultaneously, paying the cost of maintaining both.
The proficiency gap between technical availability and analytical confidence is where migration ROI is realized or lost. A team that has CJA deployed but lacks the capability to build analyzes independently is not migrated: it is running an expensive parallel system. The goal is a state where the teams that previously built analyzes in AA can build equivalent analyzes in CJA without routing through an analytics specialist for every request.
The Adobe Analytics consulting work that produces the most durable outcomes pairs the technical implementation with structured enablement that is anchored to the team's actual CJA configuration. Training on a demo environment or generic Workspace examples produces skills that do not transfer readily to the production Data Views and connection the team will actually use. Enablement built on the real Data Views, with the real dimensions, and metrics the team will use, compresses the time between technical access, and independent proficiency.
What "done" actually means
A migration is operationally complete when three conditions hold simultaneously:
First, CJA is the system of record for all ongoing measurement decisions. Reports that inform budget allocation, campaign optimization, and product decisions are being run in CJA, not AA. Analysts are building new analyzes in CJA by default.
Second, Adobe Analytics is no longer receiving new data, or being maintained as an active implementation. This is the cut-over decision, and it is typically the most politically difficult: business stakeholders who have built institutional knowledge around specific AA reports are reluctant to abandon them until they have equivalent confidence in CJA. The Data View modeling and reconciliation work is what makes this confidence possible.
Third, the historical data access question is resolved. Either the historical AA data is available in CJA via the Analytics Source Connector, or there is a documented decision about the historical lookback period the organization will maintain and how historical comparisons will be handled when they fall outside the CJA date range.
Technically complete means CJA is receiving data. Operationally complete means AA is off. The gap between those two states is where most migrations spend more time than planned. The measurement architecture assessment process typically surfaces which of these three conditions is the actual blocker for a given organization, which tends to be more useful than a generic migration checklist.
The 12 to 24 month timeline for full AA decommissioning reflects the reality that operational completion, not technical completion, is the milestone that matters. Technical deployment can happen in weeks. Getting the organization to the point where it is running on CJA by default, with historical continuity resolved, and AA maintenance costs gone, takes longer, and requires sustained governance attention, not just engineering effort.
The structural decisions you cannot defer
The organizations that will complete CJA migrations on reasonable timelines in 2026 and 2027 are the ones that treated Person ID strategy and Data View modeling as architectural decisions requiring deliberate design work, not as implementation details to be resolved during the migration itself.
The component migration tool is competent at what it does. Batch migration of Workspace projects, updatable mappings as of September 2025, and the programmatic option via the CJA Migration API collectively reduce the mechanical work of migrating the Workspace layer substantially. That work is not the bottleneck.
The bottleneck is the work that precedes the tool: auditing cross-suite identity models, deciding how processing rules logic translates to derived fields, documenting which AA behaviors have no CJA equivalent, and getting stakeholder alignment on the reports that will change rather than migrate intact. That work requires analytics architecture judgment, not just implementation capacity.
For teams that have not yet started Person ID design, the most useful immediate action is an audit of how visitor identification was actually implemented across each active report suite: which ID field, whether authenticated, and unauthenticated sessions were handled differently, and whether any report suites were implemented against inconsistent identity logic across different implementation generations. That audit produces the input to Person ID design and gives you an accurate read on whether your migration is a 6-month project or a 24-month one.
The 1.4 API is gone. The product roadmap has bifurcated. The timeline belongs to Adobe's release cadence now, not to your planning cycle.