AEM 6.0: Adobe Finally Invests in the People Who Build It

Four years in, our verdict on Adobe’s experience platform has been consistent to the point of ritual. The capability was never in question. The cost of wielding it was. Build weight, scarce specialist talent, and a development model that made front-end work an exercise in Java archaeology have been the honest counterweights in every evaluation we have covered.

AEM 6.0, arriving this quarter, is the release that finally aims at that side of the cost equation. It aims with three coordinated changes. A rebuilt content repository, Oak, addressing scale. A touch-optimized authoring interface replacing the aging classic UI. And, most consequentially for the costs we bill against, Sightly, a new templating language designed to separate markup from logic and let front-end developers work in something recognizable as HTML.

Platform releases that add capability are routine in this tier. Releases that attack cost of ownership are rare enough to deserve the careful read. Here it is, for both audiences an AEM decision must serve.

For developers: Sightly, and the end of scriptlet archaeology

The problem Sightly exists to solve is visible in any mature AEM codebase. Templates written in JSP with Java scriptlets woven through the markup. Presentation and logic tangle until neither reads alone. The front-end developer, the person fluent in responsive, component-driven practice, cannot safely touch the templates without a Java chaperone.

Sightly’s design reverses the arrangement. Templates are valid HTML with declarative attributes. Logic lives behind them in a defined interface. The markup layer becomes readable, and editable, by the people whose craft is markup.

Two things follow, and both are cost lines. Handoffs clean up. Design-system work, the atomic component thinking gaining ground everywhere, maps onto Sightly components without the translation loss the scriptlet era imposed. And review improves. Component code that non-authors can read is component code that gets reviewed, which our maintainability rules ranks among the cheapest quality tools that exist.

Add automatic output escaping, a security default the scriptlet era left to habit. Sightly reads as the platform absorbing, at last, the front-end maturity the wider industry reached years ago.

Migration is opt-in per component. Old templates keep working. Our advice for existing sites is the opportunistic-refactor pattern from every migration we have coached. New components in Sightly from day one. Old ones converted as work touches them. No ceremony projects.

For authors and administrators: the touch UI, and its transition tax

The authoring interface rewrite brings the platform’s daily screens into the touch-first, card-based present. That matters for the tablet-carrying marketing users the platform courts, and for the basic dignity of the people who live in these screens. The adoption lesson our CMS coverage applies at every tier: systems people enjoy get used.

The honest transition notes. The classic and touch interfaces will coexist awkwardly for a while. Feature parity between them is close but not complete this release. And retraining a large author base mid-flight is a real line item that enterprise rollout plans should schedule rather than absorb. The WordPress 3.8 lesson, at enterprise scale.

Underneath both audiences, the Oak repository rebuild is the infrastructure story. Better scale behavior, better clustering, and the foundation Adobe clearly intends to build its next several releases on. Repository moves reward careful planning and staging servers. Upgrade projects should treat 6.0 as a true platform move, not a version bump. The sites that budget it that way will collect the improvements without the war stories.

What the migration decision looks like from an owner’s chair

For the organizations holding existing AEM sites, the upgrade question deserves its own paragraph of advice, because 6.0’s repository change makes this a genuine platform move with genuine planning shape.

The sequencing that de-risks it, from the moves we are now scoping. Inventory the customization surface first. The overlays, hotfixes, and bespoke components piled up since the original build. Each is a line item, and the census is where estimates become honest.

Stage the repository migration against production-shaped content volumes. Oak’s behavior under your actual asset load is the fact that matters, not the datasheet’s.

Run the authoring interfaces in parallel deliberately. Classic for the workflows with parity gaps, touch for the teams ready to move, with the retraining program scheduled rather than assumed.

And treat the Sightly adoption as the opportunistic track above rather than a migration gate, because coupling the two multiplies risk without multiplying benefit.

Budget shape: quarters, not sprints, weighted toward verification. The sites that emerge will be cheaper to run than the ones they replace, which is the cost line this whole release exists to move. Owners who deferred upgrades through the 5.x era because each one felt like penance should re-examine. This is the first version where the destination pays for the trip.

What this changes for evaluations

Does 6.0 move the threshold question our Marketing Cloud analysis installed, is your operation above or below the suite line? Not directly. License gravity and maturity demands stand.

What it moves is the build-cost term inside the above-threshold math. Sightly shrinks the specialist bottleneck by letting standard front-end talent contribute safely. The modern stack shortens onboarding. And sites built on readable components will age better than the scriptlet generation did, which our maintenance economics price directly.

For organizations already on the platform, the release is the strongest upgrade case yet. For evaluators at the threshold, the cost side just improved enough to re-run stale numbers. And for the pattern watchers: a platform vendor spending a major release on developer experience and maintainability, rather than demo features, is behaving like a company that expects to be judged on deployed reality. That is the behavior we have spent four years asking for. Credit accordingly, verdict updated, file open.

The demo, as always, will be excellent. For the first time, the year-three codebase might be too. We will judge the Sightly bet when the first sites built on it reach maintenance age, and the criterion is already written. Did front-end talent actually contribute safely, at market rates, without the Java chaperone? Our money is gently on yes.