AEM 2026.10.0 Ops Checklist: Egress IPs, OpenTelemetry, Java 25

The 2026.10.0 release of Adobe Experience Manager as a Cloud Service, which went live on 29 October 2026, is easy to read as a feature story. For the people who keep an AEM program running, the more useful part is the short list of platform notices: CDN egress IP allowlists, the move from built-in New Relic APM to OpenTelemetry, and deprecated Java APIs. With 2026.11.0 planned for 19 November 2026, you have about a week and a half of lead time to decide who owns each one.

Key takeaways

• Three platform notices in 2026.10.0 need a named owner: CDN egress IP allowlists, the transition from built-in New Relic APM to OpenTelemetry, and deprecated Java APIs.
• The AEM Cloud Service SDK now supports Java 25 for local development, so developer machines can move ahead of everything else.
• The agent features (Governance Agent, CX Enterprise Coworker, Cloud Migration Agent skill) suit a small supervised pilot, not a program-wide rollout.
• The Composite data type for Content Fragments is a prerelease feature. Model it in a sandbox, not in production.
• The next feature release, 2026.11.0, is planned for 19 November 2026. Use that date as your deadline for finishing the notice review.

What the 2026.10.0 platform notices actually ask of you

The release overview groups three items under a single instruction: review them. Nothing in the overview text says any of them breaks a running site today, and it would be wrong to claim that. What the notes do say is that these are platform changes to prepare for, which is a different category from a feature you can ignore until it suits you.

That distinction matters because release notes get read by whoever is closest to the product, usually a content or product owner. Egress IPs, telemetry pipelines and Java API deprecations sit with network, platform and engineering people who may never open the page. A feature announcement gets forwarded in minutes. A notice about an allowlist can sit unread until something stops working on a Friday.

So the first job is routing. Someone needs to read the three linked notices in full on Adobe's documentation site, because the overview only names them. Then each goes to the person who owns the affected system.

How to prepare for the CDN egress IP allowlist notice

The notes name the topic and point to a notice. They don't spell out the details in the overview, so the details belong to Adobe's page, not to this post. What you can do now is the part that has nothing to do with the specifics: find out where an IP allowlist exists in your estate.

Think about the systems your AEM site talks to or fronts. A payments or CRM endpoint that only accepts known source addresses. A partner API behind a firewall. An origin that serves assets or feeds to your site. Each of those is a place where someone, years ago, typed in an address and forgot about it. If the notice changes anything about the addresses involved, those are the places where the change would surface, and usually as a failed request rather than a warning.

A practical approach:

1. Ask your security and network contacts for every allowlist that mentions your AEM environments.
2. Record who administers each one and how long a change takes. Some partners take days.
3. Read the notice and compare it against that list.
4. Schedule any needed change in a non-production environment first, then production.

Don't wait for the first failed integration to learn that a vendor needs a week's notice for a firewall edit. The cheapest fix in this whole release is a spreadsheet you build now.

Moving from built-in New Relic APM to OpenTelemetry

The notes describe this as a transition from the built-in New Relic APM to OpenTelemetry. They don't give a timeline in the overview, so treat the linked notice as the authority on what changes and when.

Who cares? Anyone who looks at performance data to decide whether the site is healthy. If your on-call rota leans on APM dashboards, if you have alert thresholds tuned over a year of traffic, or if your incident reviews quote response-time graphs, the data source behind them is the thing in motion.

OpenTelemetry is a vendor-neutral standard for traces, metrics and logs. The general appeal is that you can send telemetry to the tool you choose rather than one bundled with the platform. The general cost is that you now own decisions the bundled option made for you: where the data goes, what you keep, what you pay to store it.

Before anything changes, do an inventory. List each dashboard and alert that depends on the built-in APM. Mark the ones people actually open and the ones nobody has looked at since the person who built them left. Retire the second group instead of migrating it. Then decide which of the first group you need rebuilt on the new source, and who verifies they match.

Don't treat this as purely a tooling task. The question that decides success is whether your team can still answer 'is the site slower than normal?' on the day after the switch. If the answer depends on historical baselines held in the old tool, plan how you will carry or recreate that baseline.

Java 25 and the deprecated Java APIs

Two separate Java items sit in the notes, and they pull in different directions. The AEM Cloud Service SDK supports Java 25 for local development. Separately, the notes ask you to review a notice on deprecated Java APIs.

The SDK item is the easy one. It means a developer can run the local AEM instance on Java 25. It does not, by itself, tell you what runtime your cloud environments use or what your build pipeline expects, and the overview doesn't say. Check Adobe's documentation for that before you change anything in your build configuration.

The deprecation item needs real attention from whoever leads your code base. Deprecated usually means still working, scheduled to go. The danger is the slow kind: a custom component or service that quietly calls a deprecated API, passes every test today, and becomes a forced rewrite later at a bad moment.

Here is a sensible order of work:

• Read the deprecation notice and write down the APIs it names.
• Search your custom code and any in-house libraries for those APIs.
• For each hit, note whether the code is live, on a roadmap to be replaced anyway, or dead.
• Fix the live ones in the normal sprint cycle. Delete the dead ones.
• Try Java 25 locally on one developer's machine, run the build, and write down anything that breaks.

A team with a clean, well-tested code base can do all of this alone in a day or two. A team that inherited a large estate of customisations from a previous agency may want help mapping what is actually used. That is a reasonable place to bring in outside hands, covered below.

Agent features: what to pilot and what to leave alone

The release highlights several AI-assisted capabilities. The AEM Governance Agent can help prioritise vulnerability findings. New capabilities in CX Enterprise Coworker let developers inspect workflows and investigate Dispatcher behaviour using natural-language prompts. The Cloud Migration Agent skill adds migration patterns and beta validation, and the unified AEM MCP Server now supports Cloud Migration capabilities. The notes also point to an Agents in AEM beta program and say beta releases may contain defects and can change without notice.

That last warning is worth taking at face value. Adobe states beta releases come without warranty and that features and APIs in beta are subject to change. So what do you do with them?

Pick one low-stakes use per capability and run it where a wrong answer costs nothing.

For the Governance Agent, the use is ordering a backlog of vulnerability findings. Keep your existing process as the authority. Let the agent propose an order, have a security engineer compare it against their own, and note where they disagree. If you learn something, good. If it never disagrees with a human, you have learned whether it adds anything. For security findings specifically, confirm fixed versions and remediation steps against Adobe's official security bulletin, not against an agent's summary.

For CX Enterprise Coworker, ask it questions you already know the answer to about a workflow or a Dispatcher behaviour. Judge the quality of the answers before you ask it anything you don't know.

For the Cloud Migration Agent skill and the MCP Server, the audience is narrow: teams still moving from an older AEM setup. If you finished migrating years ago, skip this.

What to avoid: handing any of these production credentials or write access on the strength of a demo. And don't count the time saved until you've counted the time spent checking.

Content and media changes worth a look

The feature side of the release is real but narrower in effect than the platform items, so it deserves a proportionate response.

The Sites prerelease adds a Composite data type for Content Fragments. According to the notes, Content Fragment models can use it to group related fields and repeat them as a list inside a fragment, and the composite content is stored in the fragment itself, so GraphQL and the OpenAPIs deliver it in one response without resolving references. Because this is a prerelease, don't build a production content model on it. Try one model in a sandbox, perhaps a repeating block of related fields such as a set of linked details your front end currently stitches together from several references, and see whether the single-response behaviour simplifies your queries. Keep the result as a note for when the feature matures.

On the Assets side, Dynamic Media with OpenAPI capabilities now supports multiple captions and multiple audio tracks for video assets, letting you associate language-specific tracks with one primary video and manage them from a unified interface. It also offers AI-generated video captions. If you publish video in several languages, the practical test is simple: take one existing video, add two languages, and see whether your editors can manage the tracks without help. Have a native speaker check any AI-generated captions before they go live. The release also lists branded video playback and a GIF-based countdown timer for Dynamic Media email templates, which matter mostly to marketing teams running campaigns.

The notes say Limited Availability and Beta features remain listed until they reach general availability, so read each entry's status before you plan around it.

A rollout plan with owners and a deadline

With 2026.11.0 planned for 19 November 2026, here is a compact schedule. Dates are yours to set; the order is the point.

To measure whether this worked, don't count tickets closed. Count surprises. After 2026.11.0 lands, how many production incidents came from something the notices had already told you? The target is zero. Also track how long a monitoring question takes to answer before and after the telemetry change, because that is the number your on-call people feel.

Where an implementation partner helps and where you can go alone

Most of this is internal housekeeping. Reading notices, listing allowlists, trying an SDK on a laptop and piloting a tool in a sandbox are all work a competent in-house team can do without outside help, and paying for them would be a poor use of budget.

A partner earns their fee in a few specific places. Mapping a large, inherited code base against a deprecation list, when nobody on staff knows what the custom code does. Redesigning observability when the platform's bundled option is going away and you have no established standard for telemetry. Running a migration if you're still on an older setup and want a second pair of eyes on the approach. And reviewing a content model before you commit to a new data type, since models are expensive to unpick once editors have filled them.

If you decide to look for help, write the brief around outcomes: the notices you must address, the date you need them handled by, and what counts as done. Our Adobe Experience Manager RFP template gives you a structure for that, and the AEM partners directory lists firms you can compare against your brief. If you're still weighing options, compare puts shortlisted firms side by side.

What not to do

A few mistakes recur in releases like this one.

Don't act on a summary, including this one, when the instruction lives in a linked notice. Read the notice. Don't change production first; every item above has a safe place to be tried before it matters. Don't treat beta and prerelease features as settled just because they appear in a release's highlights. And don't let the agent features distract you from the plain items, because a forgotten allowlist will hurt more than a missed AI feature ever will.

The quiet work is the valuable work this month. Assign the three notices, put the dates on a calendar, and let the headline features wait their turn.

Sources

• Adobe Experience League: Current Release Notes for Adobe Experience Manager as a Cloud Service — Release notes for 2026.10.0, released 29 October 2026, last updated 4 November 2026; 2026.11.0 planned for 19 November 2026.