A zero-downtime cutover to AEM 6.5 LTS is achievable, but it requires treating the cutover itself as a distinct project phase with its own runbook, separate from the code and content migration work that precedes it.
Pre-cutover prerequisites
- All custom code migrated and regression-tested on a scratch LTS environment (see the companion articles on Java 17 and jakarta namespace migration)
- A full content and configuration parity check between the current production environment and the new LTS environment
- Dispatcher and CDN configuration validated against the new environment under realistic traffic simulation
- A rollback path defined and tested — not just assumed to be possible
Cutover strategy: parallel run vs. big bang
A parallel-run cutover — standing up the new LTS publish tier alongside the existing production tier and shifting traffic gradually through a load balancer or CDN routing rule — is the more reliable path to zero downtime, though it costs more in infrastructure during the transition window. A big-bang cutover with a maintenance window is simpler to execute but by definition is not zero-downtime.
Traffic shifting sequence
- Route a small percentage of read-only traffic to the new LTS publish tier and monitor error rates and performance
- Gradually increase the traffic percentage while watching application logs, not just infrastructure metrics
- Cut author traffic over last, after publish-side confidence is established, since author-side issues are lower-visibility but higher-impact if authors cannot work
- Keep the old environment warm and ready for rollback until the new environment has run a full business cycle without incident
Communication plan
Even a technically zero-downtime cutover benefits from clear internal communication: a defined go/no-go checkpoint, a named decision-maker for rollback, and a status channel for the cutover window. Most cutover incidents are made worse by unclear ownership during the response, not by the technical issue itself.
Post-cutover validation
Run the same smoke test suite you used in the pre-cutover scratch environment against production immediately after cutover, plus a defined monitoring window (typically 48–72 hours) before considering the old environment safe to decommission.