AEM as a Cloud Service vs AEM 6.5 On-Prem

If you learned AEM on 6.x, or you are about to migrate, the biggest surprise is that AEM as a Cloud Service (AEMaaCS) isn't just "AEM hosted by Adobe." It changes how you deploy code, configure environments, process assets, move content and debug problems. This post compares the two side by side so you know what changes for developers, operations and architects.

The Core Idea

The mental shift: with 6.5 you manage instances. With Cloud Service you manage code and configuration, and Adobe manages the instances.

Architecture Differences

Immutable vs Mutable Content

On Cloud Service the repository is split in two:

• Immutable: /apps and /libs. Your code and configuration are deployed through the pipeline, and cannot be changed at runtime. You can't edit a component in CRXDE on a production environment
• Mutable: /content, /conf, /home and similar. Authors and processes can change them freely

This is why the archetype separates ui.apps (immutable) from ui.content (mutable). Anything that needs to be written at runtime must live in a mutable area.

Repoinit scripts handle the structure and permissions that your code needs in the mutable repository (for example creating a folder, a service user or an ACL). They are declarative, run at startup, and replace many things people used to do with manual packages.

Replication

6.5 uses replication agents you configure. Cloud Service uses Sling Content Distribution through an Adobe-managed pipeline, with no agents to create. We covered this in detail in the previous post. Reverse replication isn't initially supported, so any design that depends on it needs rethinking.

Dispatcher and CDN

• 6.5: you install and configure Dispatcher yourself (or AMS does), and you choose and run your own CDN
• Cloud Service: a CDN is included in front of Dispatcher, and Dispatcher configuration is deployed with your code. It's built on the Dispatcher SDK, with a validator and some immutable files you can't change. You now have two cache layers to reason about

Assets Processing

• 6.5: the DAM Update Asset workflow does renditions, metadata extraction and custom steps inside AEM
• Cloud Service: assets upload directly to cloud storage, Asset Compute handles renditions through processing profiles, and a post-processing workflow handles the rest. We covered this in the Assets series

Search and Indexing

Oak indexes are deployed as code and managed through the pipeline, using index definitions with versioned names. You can't tweak indexes by hand on a running environment. Adobe also manages the platform's own indexes, and Cloud Manager checks index definitions during deployment.

Development Differences

Environments and Run Modes

OSGi configuration is organized by run mode (author, publish, and environment types such as dev, stage and prod) in .cfg.json files. Secrets and environment-specific values are supplied through Cloud Manager environment variables and referenced from configuration, rather than being written into code.

Code Quality Gates

Cloud Manager pipelines run code quality checks (static analysis, security and performance tests) as part of every deployment. Failing critical checks stops the pipeline. This is a real change from 6.5, where code could be installed regardless of quality.

Java and APIs

• Use the AEM SDK API (the aem-sdk-api dependency), which exposes only the supported, cloud-compatible APIs
• Avoid deprecated and internal APIs. Some 6.5 APIs aren't available
• Java versions follow what the SDK and Cloud Manager support, so check Adobe's current requirements before upgrading your build

What You Can No Longer Do

• Install packages by hand on Stage and Production
• Edit /apps or /libs at runtime
• Use replication agents or reverse replication
• Rely on workflow launchers for new asset processing
• SSH to servers or change JVM settings
• Use a CRXDE Lite editing workflow outside local development

Operations Differences

What Stays the Same

Not everything is different, and that's reassuring:

• The authoring experience: the Sites editor, DAM, templates and workflows look and behave the same way
• Core development model: Sling, OSGi, HTL, Sling Models, components and dialogs work as you know them
• Content structure: pages, assets, tags and content fragments are the same
• Skills: a 6.5 developer is productive on Cloud Service quickly, once the deployment model is understood

Which Should You Choose?

For new projects, Cloud Service is the default recommendation, with continuous updates, automatic scaling and the newest capabilities, such as GraphQL-based headless delivery and tight integration with Edge Delivery Services.

Staying on 6.5 (including long-term support releases, where available) may make sense when you have:

• Regulatory or hosting constraints that prevent use of a managed cloud service
• Heavy dependence on customizations that don't map to Cloud Service yet
• A migration still in planning, where you must keep a stable system running meanwhile

Check Adobe's current lifecycle and support policies before committing to a long-term plan on either version.

Migration: What the Tooling Helps With

Adobe provides tools to assess and move to Cloud Service:

A typical migration checklist:

1. Run BPA and review the findings
2. Restructure the project (repository modernization) and move to the AEM SDK API
3. Refactor replication agent use, workflow launchers for assets and any runtime /apps changes
4. Convert Dispatcher configuration and validate it with the SDK
5. Convert indexes
6. Move content with the Content Transfer Tool (expect multiple passes: initial, then top-ups)
7. Set up Cloud Manager pipelines, then test on Dev and Stage
8. Plan a content freeze and cutover

A Quick Mapping for 6.5 Developers

What's Next

Whichever platform you're on, a fast site depends on how efficiently Publish serves requests. In the final post of this series, we look at Publish instance performance tuning: finding bottlenecks and fixing them with caching, queries, code and configuration.

Next in this series: [Publish Instance Performance Tuning]