AEM Cloud Stops Receiving Adobe Updates June 11 If You Use Deprecated APIs — Here's the List and How to Tell

On June 11, 2026, AEM Cloud Service environments still running deprecated Java APIs stop receiving Adobe release updates. They'll keep serving traffic. They'll keep handling authoring. They just go silently un-patched — no security fixes, no bug fixes, no platform updates — because Adobe will hold those updates back from environments that haven't successfully completed a pipeline run on the new API surface.

That's the part that matters and that's the part most teams will miss. Not because Adobe didn't tell anyone, but because the way Adobe rolled this out has at least four surfaces where a team can quietly walk past the warnings.

The Escalation, In Adobe's Own Words

Pulled from Adobe's Deprecated and Removed Features page:

If you read that progression closely, the failure mode at each step is different — and that's where teams lose track.

The Four Quiet Surfaces

Surface 1: The notification email assumes you've been deploying. The Jan 26 email goes to environments where a pipeline "has been recently executed." A long-tail production environment that's been stable for six months — the one running an internal portal, a partner microsite, a staging environment kept around for a single QA flow — never gets the email. The team that owns it doesn't know anything is wrong until June.

Surface 2: The February pause is overridable. Code Quality flags deprecated API usage. The pipeline pauses. A Deployment Manager / Project Manager / Business Owner with the right role can click "override and proceed." Under release pressure (a critical fix, a marketing deadline, an end-of-quarter launch), that override is going to get clicked. The override doesn't fix anything — it just lets the deploy through, and the deprecated APIs stay in the environment. The pipeline emails the override-approver, but the actual engineer who needs to migrate the code might never see it.

Surface 3: April failures are deploy-time, not runtime. When April 14 hits and pipelines start failing the Code Quality step, your running AEM environment doesn't change. It keeps serving requests. Authors keep authoring. The breakage is in your ability to deploy new code. If your team isn't shipping much (a maintenance phase, a feature freeze, a project paused for re-org), the pipeline failures don't fire until someone tries to ship — which might be weeks after the deadline. By then May 4 has passed and your environment is no longer receiving Adobe updates either.

Surface 4: June 11 is the quietest failure of the four. Your environment doesn't crash. Pages don't break. URLs don't 404. Adobe simply stops applying platform updates. Days later, weeks later, the next CVE drops on a dependency Adobe usually patches for you, and your environment doesn't get the fix. Teams typically discover this during the next security audit, not at the moment of failure.

The Actual Deprecated API List

This is the part most blog posts hand-wave. Adobe publishes the list at the public Deprecated and Removed Features page (no paywall, despite what some second-hand summaries imply), and the aem-sdk-api javadoc carries the per-class @Deprecated markers.

Here's the cohort that's in the Feb 26 / Jun 11 wave, weighted by what's most likely to actually be in your codebase:

Top single-team breakers, ranked by my read of likely incidence:

1. Guava (com.google.common.*). Pulled in transitively by countless dependencies — older versions of ACS AEM Commons, older versions of HTL helpers, internal utilities written before the JDK collections caught up. Searching across an AEM monorepo for import com.google.common will usually surface dozens of hits in legitimate utility code.
2. Jetty (org.eclipse.jetty.*). Direct usage is rare, but bundled servlet adapters, embedded test harnesses, and old OSGi HTTP service consumers pick it up.
3. Logback (ch.qos.logback.*). Older custom appenders, especially those written before AEM 6.5, often reach into Logback specifics.
4. Apache Felix Web Console. Apps that exposed custom plugins to /system/console are the affected ones.

There's a longer-runway extended cohort (org.bson.*, org.apache.tika.* (80+ packages), org.apache.commons.lang → Lang3, org.apache.commons.collections → Collections4) that isn't in the Feb 26 wave but is queued up. If you're auditing now, audit those too — you'll save a second sweep.

How to Actually Find Your Usage

Adobe ships the AEM Analyser Maven Plugin (com.adobe.aem:aemanalyser-maven-plugin, current as of v1.6.16+). Run locally before you let CI surprise you:

mvn clean verify -pl all

The output line you care about looks like:

[WARNING] Usage of deprecated package found : org.apache.commons.lang : Commons Lang 2 is in maintenance mode. Commons Lang 3 should be used instead.

Adobe's own guidance is to "treat analyzer warnings as future pipeline failures." That's the right framing. Anything the plugin flags today as a warning will be a build failure on April 14.

For environments where you can't easily run Maven locally — partner CI, infrastructure-as-code-only teams — the Cloud Manager Artifact Preparation step logs an "Analyser warnings have been found" line. If you see that in your build logs and you've been ignoring it, this is the moment to stop ignoring it.

What Happens at the Pipeline Level When You Don't Migrate

The Code Quality step on April 14+ produces something like this:

[ERROR] Build step failed with the following message:
  Code Quality - The following deprecated APIs are in use:
    org.apache.felix.http.whiteboard.HttpWhiteboardConstants  (3 occurrences in com.example.aem.servlets)
    com.google.common.collect.ImmutableList                   (47 occurrences across 12 modules)
  Deployment is blocked. Migrate these APIs and re-run the pipeline.

That's the loud surface. The quiet surface is what happens in the AEM environment itself when you don't:

• Bundle resolution succeeds today because the deprecated packages still resolve from the platform.
• Eventually (release-by-release), Adobe will stop exporting some of these packages from the AEM platform's Export-Package. When that lands, your bundle goes into Installed-but-unresolved state.
• AEM will keep running. Your bundle will be inactive. The components that depend on it will fail to render — but only the affected paths. Customers see broken pages on specific URLs, not site-wide outages. Detection lag is high.

Migration: What's Actually Drop-In and What's Not

What to Google If You're Already Past the Cliff

If you only find this article after June 11, the symptoms in your environment look like:

• Cloud Manager Actions Center: "AEM version update paused" or "environment is no longer receiving AEM updates."
• Pipeline failure: "Build step failed: Code Quality - The following deprecated APIs are in use" (this is the April 14 onwards mode).
• Bundle resolution failure log lines referencing com.google.common, org.eclipse.jetty.*, ch.qos.logback, or org.apache.felix.http.whiteboard.
• Custom servlets returning 404 where they used to return 200 (Whiteboard registration silently dropped).
• Logging output reduced or empty for components that wired Logback directly.

The fix path is the same regardless of when you discover it: run the Analyser, fix the flagged usages, ship a successful pipeline run, regain platform updates. Cloud Manager picks back up automatically.

The Pattern, Beyond AEM

This release shape — multi-step escalation from email, to pause, to override, to fail, to silent un-patching — isn't unique to Adobe. It's the same pattern you see in Microsoft 365 Message Center retirements, in long Salesforce sunset cycles, in Stripe API version moves with brownouts.

What's interesting about it from a monitoring angle is that every surface in the escalation is silent-fail to some part of the team. The Jan email reaches deploy-active environments only. The Feb pause is overridable by approver roles that may not be the migration owner. The Apr failure is deploy-time, not runtime. The May/June cutoffs are about future updates, not current functionality. There is no single point at which a team is forced to know.

The only durable defense is to be watching for this pattern continuously — analyzer output in CI, deprecated-API counts trending over time, the Actions Center for environments that haven't deployed recently. It's the same observation that makes API response-shape monitoring useful at the runtime layer: you can't trust the changelog to reach the engineer who needs to act, and you can't trust the build to fail in the right place at the right time. Some layer needs to be watching, on a schedule, with alerts that route to the people who'd actually do the migration.

That's the work I've been doing on the runtime side at FlareCanary — watching API response shapes and flagging structural drift before dashboards go empty. The build-time analog for AEM is already in your tree (the Adobe Analyser plugin); the question is whether anyone is looking at the warnings.

If you're an AEMaaCS team and June 11 is on your calendar with a question mark next to it, run mvn clean verify against the latest aemanalyser plugin tonight. Anything red is a deploy block on April 14 — which is closer than it sounds.

If you've already hit one of these on a real environment — especially the override-and-forget path or the long-tail-environment path where you got no email — I'd genuinely like to compare notes. Drop a comment.