Adobe Experience Cloud automation needs a capability map before it needs more code

Adobe Analytics API 1.4 reached end of life on 12 August 2026. The obvious response is to change the endpoint and move every integration to API 2.0.

That is necessary, but it is not a migration plan.

Legacy automation often grew over years. One script downloads reports. Another creates or changes variables across report suites. A Power BI connector applies several filters. A deployment process assumes an administration endpoint exists because it existed in 1.4. Replacing authentication and report requests can leave important operational capabilities uncovered.

The first migration asset should be a capability map: what the organisation automates, which API supports it now, what control surrounds it and what happens when it fails.

Inventory business capabilities, not API calls

An endpoint inventory tells engineers what is invoked. A capability inventory explains why the call exists.

For each integration, record:

• business process and owner;
• source and destination;
• authentication method and credential owner;
• API, version and endpoint;
• schedule, volume and rate behaviour;
• filters, segments and calculated logic;
• configuration changes it can make;
• downstream reports or decisions;
• retry, idempotency and reconciliation behaviour; and
• replacement status.

Several endpoints can implement one business process, and one endpoint can support many processes. Migrating at the call level misses both relationships.

Separate reporting APIs from administration APIs

Reporting and configuration have different risk profiles.

A failed report request delays insight. A configuration call that changes eVars, props, events or activity settings can alter future data and become difficult to reverse. Treat write automation as controlled infrastructure, even when the platform does not provide a full infrastructure-as-code experience.

Use stronger controls for writes:

• peer-reviewed desired-state changes;
• environment and report-suite allowlists;
• preview or diff before commit;
• immutable execution logs;
• post-change validation;
• rollback or compensating action; and
• separation between deployment and approval credentials.

If API 2.0 does not cover a legacy administration capability, name the gap. Do not quietly replace automation with an undocumented manual step.

Modern authentication is an ownership change

Moving from WSSE or older credentials to Adobe Developer Console OAuth Server-to-Server credentials is more than token syntax.

Decide:

• which team owns the project and credential;
• the minimum product profiles and permissions;
• where secrets are stored and rotated;
• how non-production and production are separated;
• what monitoring detects failed or unusual use; and
• how access is removed when an integration retires.

Avoid a shared “Adobe API account” used by unrelated automations. It destroys attribution and expands the impact of a leaked or over-privileged credential.

Build a migration matrix

Classify every capability into one of four states.

• Supported replacement: move to the current API and validate semantic parity.
• Supported with redesign: the outcome is possible, but request shape, pagination, filtering or workflow must change.
• Manual temporary control: no suitable API exists, so a named owner performs and evidences the action until a replacement is available.
• Retire: the integration or output no longer justifies its operating risk.

“Manual temporary control” needs an expiry date. Otherwise, it becomes permanent invisible labour and the next audit rediscovers it as a surprise.

Validate semantics, not only HTTP success

An API 2.0 report returning status 200 can still produce a different business result from a 1.4 integration.

Compare:

• selected report suite and virtual report suite;
• segment combination and filter semantics;
• dimension and metric scope;
• attribution and date range;
• timezone and data latency;
• pagination and row limits;
• handling of Unspecified and zero values; and
• downstream type conversion.

Run old and new paths in parallel where the legacy service remains available in a controlled environment or compare against archived known outputs. Reconcile material differences before changing the consumer.

Lineage is part of safe automation

AEP audiences, AJO journeys, Target activities and Analytics components are reusable. Automation that renames, replaces or deletes one object can affect several downstream experiences.

Maintain dependency records such as:

• audience to journey, destination and Target activity;
• schema field to dataset, query, audience and activation mapping;
• Analytics segment or calculated metric to scheduled report and dashboard;
• Target offer to activity and property; and
• AEM component or content model to pages and consuming applications.

Where an API cannot expose complete lineage, use controlled naming, tags, registries and release evidence. The absence of a perfect graph does not justify operating without any dependency map.

Audit trails must answer four questions

For every material automated or manual change, evidence should answer:

1. what changed;
2. who or which workload changed it;
3. when and in which environment; and
4. which approved request or deployment authorised it.

Adobe Target provides an activity Change Log and audit endpoints for supported activity actions. Use those records, but do not assume product logs replace organisational change evidence. A useful incident timeline connects the platform record to code, approval and resulting measurement.

Operational scheduling deserves the same control

Automation often fails through timing rather than code. An ingestion succeeds after segmentation has already started. A report runs before classification finishes. A destination export overlaps with a source refresh.

Adobe Experience Platform Job Schedules can expose supported batch dependencies across ingestion, Profile, segmentation and activation. Combine that platform view with external orchestrator and receiver evidence.

Every scheduled automation should declare its predecessor, safe buffer, deadline, retry policy and owner.

AEM configuration is not a place for secret improvisation

Environment-specific AEM and Cloud Manager configuration should distinguish ordinary configuration from secrets. Values belong in the supported environment and deployment mechanisms, not committed into source or pasted into untracked local instructions.

The same rule applies across the stack: source control should contain the shape and reference of configuration, while secret stores contain credentials. Promotion between environments should be repeatable and reviewable.

What to measure

• legacy capabilities with no validated replacement;
• integrations still using retired authentication or endpoints;
• percentage of write automations with preview and post-change validation;
• credentials without a current owner or rotation evidence;
• semantic variance between migrated and baseline outputs;
• automated assets without dependency mapping;
• failed schedules and unsafe overlaps;
• manual temporary controls beyond expiry; and
• mean time to identify the change that caused an incident.

Adovo’s view

API migration is an operating-model exercise disguised as a development task.

Map business capabilities before replacing calls. Separate reads from high-risk configuration writes. Give credentials and dependencies owners. Validate semantic parity, not just successful responses, and keep evidence that connects each change to an approved intent.

More automation without those controls does not create scale. It creates a faster and less attributable way to make the same mistake everywhere.

Primary documentation and further reading

• Adobe Experience Platform API authentication
• Adobe AEM OpenAPI guide