15 Years of Adobe Experience Manager: How a Swiss CMS Became a Global Platform

Today marks 15 years since Adobe officially acquired Day Software – the moment that turned a niche Swiss content management system into what we now know as Adobe Experience Manager.

If you’ve been working with AEM for a while, consider this a nostalgic deep dive: a look back at where the platform came from, why Adobe bought it, and how it evolved into the ecosystem we rely on today.

Before Adobe: The Day CQ Era

Long before AEM became Adobe’s flagship enterprise platform, it lived a very different life as Communiqué (CQ), a CMS developed by Day Software in Basel, Switzerland.

The early days were… let’s call them “inventive”:

• Version 1 & 2 were powered by CGI scripts,
• a C-based plugin for Netscape Enterprise Server,
• and ECMAScript applications.

Only with CQ3 did the system shift to a Java-based architecture, with CQSE acting as a dedicated HTTP service.

Up to CQ4, the entire content store still lived on the file system. That changed in 2005 with the release of CRX 1.0 – the Java Content Repository that, in upgraded form, continues to power AEM nearly 20 years later.

If you’ve ever watched Lars Trieloff’s 2018 talk on CQ/AEM history, you know how many of these early decisions still influence the platform today.

CQ5 – the Reinvention That Set the Foundation

When Day unveiled CQ5, the product felt almost brand new. Many features we now consider “standard AEM” were groundbreaking at the time.

The Visual Authoring Interface & Sidekick

A drag-and-drop, component-driven WYSIWYG editor in 2008 was a huge leap forward compared to most CMS tools of that era.

Workflow Engine

The idea that business processes could be visualized and executed within a CMS blew people’s minds. For many enterprises, this was the killer feature.

Tags

Hard to imagine AEM without taxonomy. CQ5 was the release that introduced tagging.

DAM

The first browser-native Digital Asset Manager – complete with image cropping and rotation. No Flash required.

Clustering (the short-lived kind)

CQ5 introduced active-active and active-passive clustering for both author and publish. In practice? Almost nobody used publish clusters successfully. Author clustering worked “in theory”, but the stability challenges were legendary.

CRXDE & CRXDE Lite

These tools gave developers direct access to the repository. CRXDE Lite today still looks uncannily similar to its original form.

The Pre-Adobe Timeline: CQ Releases at a Glance

• CQ 3.5 (2002)
• CQ 4.0 (2005) — introduction of CRX
• CQ 4.1 (2006)
• CQ 4.2 (2008)
• CQ 5.0 (2008) — internal preview
• CQ 5.1 (2008) — Sidekick, DAM, Tags, Workflows, CRXDE Lite
• CQ 5.2 (2009) — MSM, improved DAM
• CQ 5.3 (2010) — Communities, testing features, better translation

By 2010, CQ had become a powerful—but quirky—enterprise CMS with huge potential and many rough edges.

Adobe Steps In: The Acquisition That Changed Everything

In July 2010, Adobe announced it would acquire Day Software for $240 million — a bargain compared to the $1.8 billion spent on Omniture just a year earlier.

At that point, Adobe.com was already running on CQ, and Adobe was clearly assembling the pieces of what would become the Adobe Marketing Cloud:

• Scene7 (2007),
• Omniture (2009),
• and now CQ.

For many of us working with CQ back then, the acquisition was a turning point. Suddenly it became obvious: this platform had a real future.

From Adobe CQ to Adobe Experience Manager

CQ 5.4 (2011):

• CRX2
• stronger community features
• mobile support enhancements

CQ 5.5 (2012):

• integrations with Creative Suite, Scene7, Search&Promote
• mobile app authoring
• undo/redo
• early Content Fragments as custom features

Rebranding

Adobe briefly tried names like Adobe WCM and Web Experience Manager before finally settling on Adobe Experience Manager during the 5.6 release cycle.

AEM 5.6 (2013):

• Introduction of TouchUI
• Improved personalization
• DAM video capabilities

The product was evolving rapidly, but the biggest shifts came next.

AEM 6.x — The Era of Architectural Overhaul

AEM 6.0 (2014) — The Big Rewrite:

• Switch from Jackrabbit to Apache Oak
• Removal of CQ-style clustering
• The (overly optimistic) MongoMK option
• TouchUI expansion
• Smart Tags for Assets

This release triggered one of the most painful migration waves in AEM history.

AEM 6.1 (2015):

• ContextHub
• Vanity URLs
• Mobile apps SDK
• AEM Desktop App

AEM 6.2 (2016):

• Stability improvements
• Full release of Content Fragments
• SSL support
• Modernized UI

AEM 6.3 (2017) — The First Truly “Stable” AEM 6 Version:

• Core Components go GA
• New datastore/segmentstore architecture
• Experience Fragments
• SPA Editor
• Sensei-powered features in DAM

AEM 6.4 (2018):

• Repository restructuring
• Workflow UI modernization
• Better translation tools

AEM 6.5 (2019):

The longest-living version of AEM ever released.
Six years of service packs. Dozens of new features. Still widely used.

AEM as a Cloud Service (2020): A New Generation

First teased at adaptTo() 2019, AEM Cloud launched in early 2020 and fundamentally reimagined how AEM is deployed and operated.

Key innovations:

• autoscaling for author and publish
• built-in CDN
• cloud-native workflows
• microservice-based asset ingestion
• new search capabilities (including recent RAG-based search)

For Adobe, this was the strategic path forward: a fully managed, continuously updated version of AEM.

AEM 6.5 LTS — The Last of the “Classic” Line

Sometimes referred to as AEM 6.6 internally, this version allows organizations to continue running AEM on-prem or in AMS with modern Java versions (17/21).

And yes — iconic screens like:

• /crx/de
• /crx/packmgr
• /etc/replication.html

…are still virtually unchanged since the CQ5 era. A true time capsule.

The Future: Edge Delivery Services & Document Authoring

Today, Adobe’s big bets for the future of content are:

Edge Delivery Services (EDS)

A faster, more modern, edge-first delivery layer that decouples rendering from the traditional AEM runtime.

Document Authoring

A simplified authoring workflow that prioritizes content-first creation over complex UI interactions.

Many see EDS as the eventual “spiritual successor” to AEM for delivery — while classic AEM continues to serve enterprise use cases.

Conclusion

Over the past 15 years, AEM has transformed from a quirky Swiss CMS with CGI scripts and file-based storage into a global, cloud-native content platform trusted by the world’s largest organizations.

From Sidekick to Edge Delivery Services.
From CRX 1.0 to Oak.
From monolithic CQ5 to auto-scaling Cloud Service.

And despite all the changes, one thing remains true: AEM keeps evolving — and continues to shape how enterprises deliver digital experiences at scale.