7.1 AEM Maintenance Releases & Cloud Service Version Updates

7.1 AEM Maintenance Releases & Cloud Service Version Updates

Quick Answer: AEM 6.5 uses customer-planned cumulative Service Packs and applicable hotfixes. AEM as a Cloud Service is updated by Adobe through monthly feature releases and frequent maintenance releases. Adobe announces a maintenance release several days before automatic rollout, validates it with customer code and tests, and uses rolling deployment to avoid planned downtime.

AEM 6.5 Maintenance

AEM 6.5 is a long-lived release line. A Service Pack is cumulative: installing a supported later Service Pack brings forward the fixes from earlier Service Packs in that line. Adobe may also publish security or product hotfixes with explicit prerequisites. Cumulative Fix Packs belong mainly to earlier AEM 6.x maintenance history; do not assume a CFP is the normal current update vehicle for every AEM 6.5 system.

A controlled AEM 6.5 update normally includes:

1. Read the release notes, known issues, prerequisites, and compatibility guidance.
2. Back up repository and configuration state according to the deployment runbook.
3. Test the Service Pack and custom code in a representative lower environment.
4. Verify OSGi bundles, repository indexes, workflows, Dispatcher behavior, and integrations.
5. Roll through author and publish instances with the availability strategy appropriate to the topology.
6. Perform smoke and regression tests and monitor logs after installation.

Package Manager may be part of an on-premises process, but Cloud Manager can govern AEM Managed Services deployments. The important distinction is ownership: AEM 6.5 customers plan and execute the maintenance release, while Cloud Service platform updates are operated by Adobe.

Cloud Service Release Tracks

AEM as a Cloud Service has two product-release tracks:

• Feature releases: generally monthly and described in release notes. They introduce capabilities and product changes.
• Maintenance releases: published frequently to deliver fixes, security updates, and reliability improvements. Adobe's current roadmap describes a regular maintenance cadence; it should not be memorized as a guaranteed daily patch.

A maintenance release is published several days before production rollout. Development environments may update automatically or offer an update action during the transition. This gives teams time to run their application against the upcoming release.

Cloud environments are versioned and the SDK has matching releases. Keep the local Quickstart and the aem-sdk-api dependency reasonably aligned with the cloud release being tested. Avoid copying a made-up future SDK build number into documentation or source.

How a Platform Update Is Verified

A Cloud Service version update is separate from a customer-code deployment. The update process combines the candidate AEM release with the customer's deployed application and validates the result before production rollout.

Blocking checks include customer functional tests and custom UI tests. Adobe also runs product-level validation. If a blocking test fails, the AEM release does not proceed to production and the failure is investigated. Production remains on the current release; Cloud Manager does not rewrite a customer's tests or silently bypass them.

A practical customer workflow is:

• keep functional and UI tests deterministic and focused on critical journeys;
• eliminate brittle selectors and timing assumptions;
• test supported APIs rather than internal implementation details;
• review release notes and deprecation notices;
• reproduce any regression on the matching local SDK or a development environment;
• open a support case with reproducible evidence when the platform update is the likely cause.

Rolling Version Updates

Cloud Service typically updates without downtime. Rolling updates are possible because each running release has its own immutable product code while old and new nodes can reference the mutable repository during the transition. Ready new nodes take traffic while old nodes are removed gradually.

This is not an excuse to make incompatible repository mutations. During either a customer deployment or a platform update, multiple application versions may coexist. Custom code should use supported public APIs and remain tolerant of the content shapes visible during a rolling release.

Customer Responsibilities

Adobe owns infrastructure provisioning, platform binaries, operating-system maintenance, and the rollout mechanism. The customer still owns:

• custom code compatibility and supported API usage;
• functional and UI regression tests stored with the application;
• Dispatcher and application configuration;
• monitoring and triage of customer-code failures;
• current development dependencies and SDK tooling;
• planned migration away from deprecated APIs.

Comparison

For exam scenarios, first identify the hosting model. A request to install a Service Pack through Package Manager points to AEM 6.5; a staged, Adobe-managed version rollout with blocking customer tests points to AEM as a Cloud Service.