Patching & service packs
Who this page is for
| Audience | Why it matters to you |
|---|---|
| Platform engineers | Executors |
| Tech leads | Cadence owners |
What arrives and when
| Artefact | Cadence | Contains |
|---|---|---|
| Service Pack (6.5.x) | ~Quarterly | Cumulative fixes + security + occasional feature/API deltas |
| Security bulletins/hotfixes | As needed | Targeted fixes — some are drop-everything |
| Java/OS patches | Your platform cadence | The JVM under AEM is part of the platform |
Policy that works: stay within one SP of current (N or N−1). The gap compounds — three skipped SPs make the fourth a migration project, and security posture decays meanwhile (vulnerability governance).
SP installation is a release
Treat an SP exactly like a code release through the pipeline environments:
1. Read release notes for: API changes, overlay-affecting UI changes, index changes, config default changes
2. Dev: install, full regression of YOUR code (SPs update /libs — your overlays and superType chains are the risk surface)
3. Stage: install + soak a week: authors work, synthetics run, perf sanity
4. Prod: maintenance window ([windows](/ee-operations/maintenance-windows.html)), author then rolling publish,
post-install verification incl. reindex/queue checks the notes call outThe overlay audit (the recurring SP gotcha)
Every SP, diff your overlays (/apps copies of /libs paths — repository structure) against the new /libs versions: an overlay pins OLD product UI/behaviour over patched code. Keep the overlay inventory small and documented; each one is a standing SP-upgrade tax.
Emergency security patches
Compressed timeline, same rails: dev smoke (hours not days) → stage synthetic pass → prod window. The severity of the CVE sets the clock; it never justifies skipping the stage pass — a broken patch install during an active threat is the worst of both worlds.