Implementing AEM Launches for Scheduled Content Go-Live

When marketing teams in Sydney need a new campaign page to appear at midnight local time but the staging environment sits in a data centre halfway across the world, the gap between intent and execution becomes painfully obvious. Content authors want precision; infrastructure wants predictability. AEM's Launch feature exists precisely to bridge that gap, letting teams prepare, preview, and schedule complex page hierarchies for activation without disrupting the live site.

Launches in Adobe Experience Manager give developers and content authors a parallel workspace where changes can be refined, tested, and staged before they reach production. Unlike simple page publication, a launch captures an entire content tree, manages dependencies through rollout configurations, and exposes a clear activation timeline. For organisations running global brands, retail networks, or multi-regional portals, this capability turns chaotic release windows into controlled, repeatable operations.

The mechanics deserve a closer look, particularly for teams attending sessions covering integrations and architecture at recent developer gatherings. What follows is a practical walkthrough of building scheduled go-lives with AEM Launches, including the regional considerations that matter for teams operating across Australian time zones.

Understanding the launch hierarchy

A launch is not a single page; it is a snapshot of a content subtree rooted at a source path. When a launch is created, AEM clones the relevant nodes into a separate, isolated branch where edits can occur without affecting the production tree. This isolation matters when legal copy, pricing, or promotional content must be locked down ahead of an embargo, such as the lead-up to an EOFY retail campaign that drops at midnight across multiple states.

The hierarchy has three primary actors: the source pages, the launch path where edits live, and the rollout configuration that governs how those edits propagate back to production. Developers working with AEM 6.5 and later versions can also reference the step-by-step guide on upgrading from version 6.0 to understand how launch APIs evolved across recent releases. In practice, configuring these three elements correctly determines whether a scheduled go-live completes in seconds or drags on for hours.

Time itself becomes part of the structure. A launch carries a production-ready flag, a go-live timestamp, and optional post-launch flags that tell the system whether to retain or delete the launch data after promotion. Setting these timestamps with the production date in AEST rather than UTC is a common trap that catches teams distributing content across Sydney, Brisbane, and Perth operations.

Rollout configurations and live copy relationships

Rollout configurations define which node properties and child pages move with a launch promotion. They are essentially blueprints that answer the question: when content in the launch branch changes, what should happen to the corresponding production nodes? A typical configuration might allow structural changes, page additions, and component edits while blocking deletes or template swaps that could destabilise a live site.

Live Copy relationships underpin this behaviour. Each page in the launch maintains a link back to its source, so the system can synchronise additions, removals, and modifications cleanly. Architects building multi-brand sites for Australian retailers often create separate rollout blueprints per brand or region, because what works for a Melbourne-focused apparel catalogue rarely suits a Queensland-based services portal with different compliance requirements.

Custom rollout configurations also handle exclusions. A common pattern is to block promotion of certain components, such as analytics tags or personalisation rules, during a launch window. This prevents a staging-only tracking pixel from polluting production analytics while the launch is still staging. Developers usually define these rules in CRXDE or via Maven-provisioned scripts, then reference them by name when creating each launch through the Sites console or the Java API.

Building the scheduled go-live workflow

The actual implementation combines a workflow model with a scheduled trigger. The standard approach involves creating a workflow launcher that listens for nodes of type cq:Launch reaching a specific state, then chains the promotion and activation steps. For teams operating across time zones, this workflow becomes the only reliable way to ensure that a midnight launch in Sydney fires on time regardless of where the author happens to be sitting.

The workflow itself typically contains four steps. First, the rollout executes, copying launch changes to the production source. Second, a production-ready flag propagates down the tree. Third, an activate tree step pushes the updated content to the publish instance. Finally, a notification step emails the marketing owner or posts to a Slack channel, confirming that the go-live has completed. Each step can be guarded with conditional logic to skip activation if a validation check fails.

For Australian teams running quarterly campaigns, scheduling these workflows through the OSGi scheduler or an external cron service is often preferable to relying solely on the built-in calendar. It allows for daylight saving adjustments that do not break during the AEDT to AEST transition each April. A small Groovy script or OSGi component can read the launch metadata, calculate the correct UTC trigger time, and pass it to the workflow launcher for execution.

Handling regional and compliance requirements

Operating a digital presence across Australian states introduces compliance nuances that affect how launches are staged. Privacy disclosures in Victoria differ slightly from those required in New South Wales, and financial services content often requires legal sign-off that varies by jurisdiction. A launch-based workflow lets a Sydney team author content, route it through a Brisbane-based legal reviewer, and only then promote it to production without exposing intermediate states to end users.

Authentication and agent configuration also vary by region. When the publish farm includes servers hosted in different availability zones or geographic locations, the replication agents must be tuned to handle latency and failover. AEM's agent queues can be configured with regional priorities so that launches targeting a Sydney audience replicate first to the Sydney edge, then fan out to other nodes once initial activation confirms.

There is also the matter of daylight saving itself. While Queensland and Western Australia do not observe daylight saving, New South Wales, Victoria, the ACT, and Tasmania do. Any hardcoded time logic in custom launch code must account for these variations, or campaigns will fire an hour early or late twice a year. The safest pattern is to store go-live times in UTC and let the front-end deliver locally formatted timestamps to end users.

Testing the launch before production

A launch that fails at the promotion stage can leave a site in an inconsistent state, so pre-flight testing is non-negotiable. The most reliable approach involves creating a duplicate launch against a staging publish instance, running the workflow manually, and validating that all expected pages and components land correctly. This dry run also surfaces any replication agent misconfigurations that might cause silent failures during the real event.

Automated tests should cover component rendering, asset references, and any conditional logic that depends on launch metadata. For sites using Content Fragments for headless delivery, validating that fragment references resolve correctly after rollout is critical; the post on AEM Content Fragments for headless CMS delivery covers several edge cases that apply here, particularly around nested fragment references. A simple grep-based check across the activated tree can confirm that no broken path references survived the promotion.

Load testing matters as well. A large launch activating hundreds of pages in rapid succession can saturate replication queues, especially if the publish tier sits behind a load balancer that is not sized for burst traffic. Running the test launch during a maintenance window and watching queue depth, heap usage, and response times reveals whether the production environment can absorb the activation spike or whether agents need throttling.

Monitoring and post-launch validation

Once a launch goes live, the work is not over. Monitoring replication agents for failed queue entries, checking dispatcher caches for stale content, and verifying that any CDN purge completed are all part of the post-launch checklist. AEM exposes queue statistics through the JMX console, and teams serious about reliability export these metrics to Prometheus or a similar monitoring stack for alerting.

Validation should also confirm that the launch was cleaned up appropriately. If the post-production flag was set to retain, the launch branch remains in the repository and can be reused for follow-up campaigns. If it was set to delete, the system removes the branch after promotion to keep the content tree tidy. Either way, a quick audit of the author instance ensures that no orphaned launches accumulate over the year, especially during high-volume periods like the pre-Christmas retail rush that Australian e-commerce teams know well.

Finally, document each launch. Capture the source path, the configuration used, the go-live time, and any anomalies encountered. This log becomes invaluable when troubleshooting the next campaign and when training new team members. A shared runbook, updated after every major go-live, turns institutional knowledge into a repeatable asset that survives staff changes and project turnover.

For teams ready to deepen their practical knowledge, the recordings and slides from previous CIRCUIT sessions offer a solid next step. The patterns covered here work best when combined with hands-on experience and peer review, so consider setting up a sandbox environment, walking through the workflow end to end, and sharing the results with your engineering group.