Adobe Experience Manager

Content Fragment Models provide custom types with a good range of field types (text, number, date, reference, enumerations, JSON, tags, content references). Sling resource types allow nearly unlimited structural flexibility. However, the model editor is GUI-only and schema-as-code requires custom tooling. The split between Content Fragments, Experience Fragments, and page components creates modeling confusion.

Fragment References and Content References provide solid relationship modeling. References can be filtered by model type. However, relationships are unidirectional — there's no native bidirectional linking. Graph traversal requires custom queries or manual reverse-reference maintenance. JCR path-based references are fragile when content is moved.

Experience Fragments provide true component-level reusable content. Content Fragments support nested fragments and variations. The component architecture in Sites (HTL + Sling Models) is deeply composable. AEM excels here because the entire system was built around structured, component-based content from the start.

Content Fragment Models support required fields, min/max constraints, and regex patterns. Custom validation requires Sling Validators or custom OSGi services — functional but heavy for simple rules. No native cross-field validation. The validation UX in the CF editor is basic compared to modern headless CMS solutions.

JCR-based versioning provides full version history with diff capabilities. Timewarp allows viewing the site at any point in time. Content Fragment versioning with comparison. Launch capabilities for time-based publishing are genuinely powerful — coordinated publishing across many pages at a scheduled time is a real differentiator.

AEM's authoring environment is one of the strongest in the industry. True in-context editing with the Universal Editor (Cloud Service) or classic page editor. Drag-and-drop component placement. Layout container for responsive authoring. The gap between edit and published experience is minimal. Universal Editor is a significant improvement over the legacy Touch UI editor.

CoralUI RTE is functional but dated compared to modern editors. Extensible via plugins but plugin development is cumbersome (OSGi + Java). Paste handling is acceptable. The inline editing experience is good, but the RTE lacks modern features like collaborative editing, slash commands, or portable text output. The Text component is showing its age.

AEM Assets is a full enterprise DAM — arguably the strongest media management of any CMS. Smart cropping with AI, dynamic media renditions, video processing, 3D asset support, asset metadata schemas, Collections, and deep Creative Cloud integration. Asset Compute microservices for custom processing. This is a genuine differentiator and often the reason enterprises choose AEM.

AEM uses page-level locking rather than real-time co-editing. MSM live copy relationships provide a form of collaborative governance but not simultaneous editing. Annotations and review workflows exist but feel enterprise-heavy rather than modern collaborative. No presence indicators or real-time conflict resolution. This is a clear weakness compared to modern headless CMS solutions like Sanity.

Workflow engine is deeply integrated and highly customizable. Granite workflow with visual workflow editor. Multi-step approval chains, role-based routing, deadline escalation, parallel steps. Integration with Adobe Workfront for marketing workflows. Full audit trail. This is enterprise workflow done right — powerful but also complex to configure.

Content Fragment GraphQL API is solid — persisted queries, filtering, pagination, nested fragment resolution. Sling JSON exporter for custom REST endpoints. However, the GraphQL schema is auto-generated from CF models with limited customization. No custom query language like GROQ. The API is capable but not as developer-friendly as purpose-built headless APIs.

Fastly CDN built into Cloud Service with automatic purge on content publish. Edge Delivery Services (formerly Franklin/Helix) provides a radically different edge-first delivery model with sub-second TTFB. CDN invalidation is granular per-page. The combination of traditional AEM delivery + Edge Delivery Services gives genuine flexibility.

Adobe I/O Events provides a modern event system for Cloud Service — content publish events, asset processing events, custom events. Webhook registration via Adobe Developer Console. However, event coverage is still growing, filtering is limited compared to purpose-built webhook systems, and the Adobe I/O indirection adds complexity.

Content Fragments are truly headless — GraphQL API serves to any channel. Experience Fragments can export to email, mobile, third-party systems. Content Services JSON export. However, the traditional Sites renderer (HTL/Sling) is web-coupled. The headless story is real but you need to design for it from the start — retrofitting existing Sites content for multi-channel is painful.

ContextHub provides rule-based segmentation directly in AEM. Deep integration with Adobe Target for behavioral targeting and Adobe Audience Manager / Real-Time CDP for advanced segments. The Adobe ecosystem gives AEM the strongest segmentation story of any CMS — but only if you're paying for the full Adobe stack.

Component-level personalization via Targeted Content. ContextHub-driven rules with real-time evaluation. Adobe Target integration for server-side and client-side personalization. Preview per segment in author mode. This is one of AEM's genuine strengths — few platforms can match the depth of personalization when integrated with the Adobe stack.

Via Adobe Target integration — full A/B, MVT, auto-allocation, auto-target (ML-powered). Statistical significance built in. Traffic allocation controls. The testing capability is genuinely best-in-class, but it requires Adobe Target licensing, which is a separate and significant cost. Without Target, AEM has no native experimentation.

Adobe Target Recommendations provides ML-powered content and product recommendations with configurable algorithms. Criteria-based, behavioral, and hybrid approaches. However, this requires Target Premium licensing — a significant additional cost. Without it, recommendations are manual curation only.

Oak Lucene provides capable full-text search with custom index definitions. QueryBuilder API for programmatic search. However, relevance tuning requires Oak index configuration — not accessible to content teams. No built-in faceting UX. Search quality is adequate for content lookup but weak for site-search experiences without external tooling.

Good integration options with Elasticsearch, Solr, and Algolia via OSGi connectors. Content indexing via Sling event listeners or Oak observers. The architecture supports external search well — most enterprise AEM implementations use external search engines. Adobe Experience Platform connector for search analytics.

Adobe Sensei provides some AI capabilities — smart tagging for assets, auto-crop. However, native semantic/vector search in AEM content is limited. No built-in NLQ or embedding support for Sites content. AI search requires external integration. The GenAI features announced are still early and mostly focused on content generation rather than search.

Commerce Integration Framework (CIF) provides a commerce abstraction layer with product catalog components, cart, and checkout. CIF Core Components give a starter kit. However, CIF is a connector framework, not a native commerce engine — it requires a backend (Adobe Commerce / Magento, or third-party). The product content experience in AEM is good but it's a shell over external commerce.

CIF provides deep Adobe Commerce (Magento) integration with GraphQL federation. Real-time product data in author and publish. Third-party commerce integration possible via CIF extensibility, with commercetools and Salesforce Commerce Cloud connectors available. Adobe Commerce integration is genuinely deep — product data in the editor, catalog-driven components.

Product-associated Content Fragments allow rich product descriptions managed in AEM alongside commerce catalog data from the backend. Asset management for product media is excellent (AEM Assets). Variant modeling relies on the commerce backend. Product content enrichment is a strength, but product *data* modeling stays in the commerce engine.

Basic page analytics via Page Insights component showing impressions and conversions. Content Fragment usage tracking. However, meaningful analytics require Adobe Analytics integration — AEM itself provides limited insight. Asset reports in AEM Assets are more useful (usage, expiry, download tracking).

The Adobe Analytics integration is the deepest analytics-to-CMS integration in the industry. Launch (tag management) built in. Context-aware analytics variables. Data layer integration. Connection to Adobe Experience Platform for unified customer profiles. If you're in the Adobe stack, the analytics story is unmatched. If you're not, you're paying for what you don't use.

Sensei powers smart tagging and auto-crop for assets. Content Insight annotations for page-level performance. GenAI Assistant (early) for content suggestions. However, content gap analysis, content scoring, and content health dashboards are not native — they require Adobe Analytics + custom dashboard work.

Multi Site Manager (MSM) is the gold standard for multi-site in the CMS industry. Live Copy with configurable rollout triggers, inheritance control at component level, blueprint management, per-site configuration overlays. This alone justifies AEM for large multi-site organizations. No other platform matches MSM's depth for managing 50+ sites from a shared blueprint.

Language Copy creates localized site trees with inheritance. Translation workflows integrated at the platform level. Locale-specific content branching via MSM. Translation memory and side-by-side comparison. The localization framework is deeply integrated and production-proven at scale. Field-level localization is supported for Content Fragments.

Translation Integration Framework (TIF) connects to major TMS providers — Smartling, Lionbridge, RWS, Translations.com. In-platform translation project management. Human + machine translation workflows. Batch operations for multi-page translation jobs. The TMS integration is mature and well-documented.

MSM blueprints with brand-level Live Copies provide best-in-class multi-brand governance. Brand-specific design systems via editable templates and style system policies. Centralized component governance with brand override capability. User group isolation per brand. This is where AEM's enterprise DNA is genuinely valuable.

Adobe GenAI Assistant is rolling out across Experience Cloud including AEM. Early capabilities include content variation generation, copy suggestions, and image generation via Firefly. However, it's early — brand voice controls are limited, the integration into authoring workflows is still maturing, and it's mostly an overlay rather than deeply embedded in the content model.

Sensei provides auto-tagging, smart crop, alt text suggestions for Assets. Auto-translation suggestions. Color palette extraction. These are genuinely useful in production. However, workflow-level AI (auto-routing, content QA, automated compliance checks) is limited. The AI features are asset-focused rather than workflow-focused.

Content Fragment GraphQL API is well-designed with auto-generated schemas from models. Persisted queries are a nice pattern. However, AEM has multiple overlapping APIs (Sling, Assets HTTP, CF GraphQL, Content Services) with inconsistent patterns. Error handling varies by API. Documentation is extensive but scattered. There's no single coherent API surface — it's grown organically over 15 years.

Persisted GraphQL queries are CDN-cached for excellent read performance. Sling has configurable caching at multiple levels. However, non-cached API calls hit the JCR directly and performance degrades with complex queries. Rate limiting is environment-dependent (Cloud Service has platform limits). Pagination is supported but the cursor implementation varies by API.

AEM Headless SDKs for JavaScript, Java, and iOS/Android. AEM SPA editor SDKs for React and Angular. However, SDK coverage is narrow compared to headless-native platforms. No Python, Ruby, Go, or .NET SDKs. The JS SDK is functional but less polished than Contentful's or Sanity's. The Java SDK is strong but reflects AEM's Java-centric heritage.

Adobe Exchange marketplace has extensive connectors — DAM integrations, commerce connectors, translation services, analytics tools. The Adobe ecosystem (Analytics, Target, Campaign, Workfront, Marketo) provides deep first-party integrations that no other CMS vendor can match. Third-party connector quality varies but the breadth is significant.

OSGi provides a powerful plugin/bundle system. Sling Models for backend logic. HTL for templating. App Builder for serverless extensions in Cloud Service. Content Fragment extensions. Custom workflows. The extensibility is extremely deep but requires Java/OSGi expertise. App Builder is the modern extensibility play — serverless, Adobe I/O Runtime, custom UIs — but it's still maturing.

IMS (Adobe Identity Management) provides SSO across Adobe products. SAML 2.0 for enterprise SSO. Cloud Service uses IMS authentication with Adobe-managed identity. Service credentials for API access. MFA enforced via IMS. Token-based auth for headless API access. The authentication story is enterprise-complete but tied to Adobe's identity layer.

JCR-based ACLs provide granular permissions down to property level. CUGs (Closed User Groups) for content-level access on publish. User Groups and permission inheritance. Rep:policy nodes allow extremely fine-grained access control. However, the permission model is complex — debugging access issues requires JCR expertise and tools like CRX/DE.

Adobe holds SOC 2 Type II, ISO 27001, ISO 27018, FedRAMP (Tailored), HIPAA readiness, PCI DSS compliance. Data residency options across multiple regions. GDPR tooling including data deletion APIs and consent management integration. This is one of the strongest compliance portfolios in the CMS space — critical for regulated industries.

Adobe has a dedicated security team and bug bounty program. Regular security bulletins published. However, AEM has a history of CVEs — dispatcher misconfiguration vulnerabilities, default servlet exposure, and serialization issues have been reported over the years. Cloud Service significantly improves the posture by managing the attack surface, but the legacy reputation persists.

Cloud Service is the mandated path forward — fully managed on Azure. AMS (Adobe Managed Services) still available for on-prem customers. No self-hosted option for new Cloud Service customers. No multi-cloud choice. This is enterprise managed hosting done well, but with zero deployment flexibility. You run where Adobe tells you to run.

99.9% SLA for author and publish tiers. Status page with incident history. Cloud Manager provides environment health dashboards. Incident communication is professional but not always timely — large enterprises have reported lag between incident start and acknowledgment. CDN-level availability is higher than origin.

Cloud Service auto-scales publish tier based on traffic. Author tier scales with environment size. CDN edge handles traffic spikes. Proven at massive scale — Adobe runs some of the largest websites in the world on AEM. However, scaling configuration is not self-service — you work with Adobe on environment sizing. Publish tier autoscaling has documented limits.

Cloud Service provides automated backups with managed RTO/RPO. Content can be exported via packages, content transfer tool, or API. However, full environment export for vendor migration is painful — JCR content, OSGi configs, custom code, and dispatcher rules create a complex export surface. Data portability is a weakness despite functional backup/restore.

AEM SDK provides a local quickstart JAR for development. Hot-deploy via FileVault for content packages. However, the local SDK is resource-heavy (4GB+ heap), slow to start (2-5 minutes), and doesn't fully mirror Cloud Service behavior. Frontend developer workflow has improved (webpack-based with hot reload) but the full-stack local dev experience is painful compared to modern platforms.

Cloud Manager provides built-in CI/CD with quality gates, performance testing, and security scanning. Environment management (dev/stage/prod) is built in. However, Cloud Manager is the only deployment path — you can't use GitHub Actions or Jenkins to deploy directly. Content-as-code is limited — dispatcher configs and OSGi configs are code, but content model changes require packages.

Adobe's documentation is extensive — thousands of pages covering Sites, Assets, Forms, and developer APIs. Searchable, versioned by AEM version. However, quality is uneven — some areas are excellent (CF GraphQL, MSM) while others are thin or outdated. The sheer volume makes navigation difficult. Community resources (blogs, forums) fill significant gaps that official docs leave.

The AEM Headless JS SDK includes TypeScript definitions. GraphQL schemas can be used to generate types via standard tooling (graphql-codegen). However, AEM's core is Java — backend development is entirely Java/OSGi. The SPA Editor SDKs have TypeScript support but the type coverage has gaps. There's no schema-to-TypeScript pipeline for Content Fragment Models. Frontend is becoming more TS-friendly but the platform's heart is Java.

Cloud Service delivers continuous updates — monthly feature releases, weekly maintenance updates. This is a significant improvement over the old 6.x annual release cycle. Adobe pushes updates automatically, which means you're always current. The cadence is genuinely fast for an enterprise platform this complex.

Release notes published per monthly release with feature summaries. However, breaking changes are sometimes buried in maintenance release notes rather than prominently flagged. Migration guides exist for major changes but are often published after the fact. Deprecation notices could be more prominent.

Adobe publishes a high-level roadmap at Summit and via the Experience League. Feature preview programs exist (early access). However, the roadmap is strategic, not tactical — you rarely know what's coming in the next 2-3 releases. No public voting or feature request board. Adobe's roadmap is set by product strategy, not community input.

Cloud Service auto-updates mean breaking changes are pushed to you — you adapt on Adobe's timeline, not yours. Deprecation windows exist but are sometimes short. API deprecations are generally well-communicated. However, the forced upgrade model means you must maintain CI/CD pipeline readiness at all times. Best Practice Analyzer helps identify compatibility issues proactively.

Large established community. Active AEM Community on Experience League forums. AEM GEMS webinar series. Strong conference presence (Adobe Summit, adaptTo). Multiple active Slack/Discord communities. However, the open-source contribution aspect is limited — AEM is proprietary, so community engagement is usage-focused rather than code-contribution-focused.

Adobe staff actively participate in Experience League forums. AEM GEMs provides regular deep-dive webinars. However, issue resolution through community channels can be slow — complex questions often go unanswered or redirect to paid support. GitHub engagement is limited since AEM core is closed-source. The community helps with knowledge sharing but can't fix platform bugs.

The largest partner ecosystem in the DXP space. Hundreds of certified implementation partners worldwide — Accenture, Deloitte, Cognizant, Perficient, and every major SI has an AEM practice. Adobe Partner Program with certification levels. The partner ecosystem is both AEM's strength (you can always find an implementer) and its tax (partners drive complexity to justify their engagement size).

Abundant blog content, YouTube tutorials, conference recordings, and books. Multiple active bloggers and content creators. However, a significant portion of content is for AEM 6.x — Cloud Service-specific content is growing but the legacy content can mislead. Training courses available via Experience League and third-party (Udemy, LinkedIn Learning).

AEM developers are available but command premium rates ($150-250/hr for senior specialists). The talent pool is concentrated in enterprise consulting firms. Freelance AEM developers are scarce. Cloud Service expertise is a smaller subset of the total AEM talent pool. The Java requirement further narrows the pipeline. Hiring AEM talent is consistently cited as a top challenge by customers.

Steady enterprise adoption — AEM is not growing explosively but maintains strong position in enterprise. New Cloud Service migrations from AMS/on-prem provide a steady pipeline. Some notable migrations away from AEM to headless solutions, but also new logos coming in for the full Adobe stack. G2 reviews are mixed — high capability ratings with low ease-of-use scores.

Adobe is a $230B+ market cap public company with Experience Cloud as a core revenue pillar. Zero acquisition risk. Stable leadership. Massive R&D investment. AEM is not going anywhere — the question is never viability, it's whether the investment is justified for your use case. Financial stability is as strong as it gets in the CMS market.

Consistently positioned as a Leader in Gartner Magic Quadrant for DXP. Strong in Forrester Wave. However, competitive pressure from headless solutions is real — organizations are increasingly choosing composable alternatives over monolithic DXP. Net migration direction is mixed: some moving to AEM for the Adobe stack, others leaving AEM for lighter solutions. AEM's positioning is stable but the market is shifting around it.

AEM pricing is fully opaque. No public pricing page. Contact sales required. Enterprise pricing is negotiated individually. Overage structures, included API calls, storage limits, and environment counts are all buried in contracts. This is the worst pricing transparency of any platform in this framework. You literally cannot estimate AEM cost without engaging Adobe sales.

Annual licensing in the $200K-$1M+ range depending on traffic, environments, and features. Additional costs for Assets, Forms, Commerce (CIF). Adobe Target, Analytics, and other Experience Cloud products are separate licenses. The per-solution licensing model means the cost compounds rapidly as you adopt more Adobe capabilities. Costs are unpredictable at contract renewal — significant increases are commonly reported.

Significant features require additional product licenses. Personalization requires Adobe Target. Analytics requires Adobe Analytics. Commerce requires CIF + commerce backend. Workfront for marketing workflows. The base AEM Sites license delivers content management — anything beyond basic delivery requires additional spend. The upsell architecture is aggressive.

Multi-year contracts are standard. Annual terms available but at premium pricing. Downgrading is contractually difficult. Exit requires significant planning. Adobe's contract structure is designed for enterprise commitment, not flexibility. Startup programs exist but AEM is not typically a startup platform.

Weeks to months before first meaningful content is published. Environment provisioning via Cloud Manager takes hours. SDK setup takes a day. First component takes a week for an experienced developer. First integrated page with real content and styling is typically 2-4 weeks. For a new AEM team, first value is measured in months. This is the slowest time-to-value of any platform in the framework.

Enterprise AEM implementations typically run 6-18 months. Even basic AEM Sites projects with experienced teams take 3-4 months minimum. Complex multi-site, multi-language implementations commonly exceed 12 months. Reference architectures exist (WKND, AEM Guides) but the gap between reference and production is enormous. Timeline predictability is low — scope creep is endemic.

AEM specialists command the highest rates in the CMS market. Senior AEM architects bill $200-300/hr via SIs. Even mid-level AEM developers are $120-180/hr. The Java + OSGi + JCR knowledge requirement means generalist web developers cannot be productive without months of training. The specialist premium is 40-80% above general web development rates.

Cloud Service hosting is bundled in the license — no separate infrastructure cost. This is actually a relative improvement over AMS where hosting was a significant additional expense. However, the licensing cost already includes the hosting premium. Additional environments (dev, stage, RDE) have limits that can require add-on licensing.

Cloud Service significantly reduces ops burden vs. on-prem or AMS — no JVM tuning, no dispatcher management, no OS patching. However, you still need Cloud Manager expertise, deployment pipeline management, environment monitoring, and Adobe I/O configuration. A part-time AEM ops engineer is realistic for Cloud Service. AMS still requires dedicated ops team.

Maximum vendor lock-in. Content is in JCR (proprietary repository), components in HTL+Sling (proprietary templating), workflows in Granite (proprietary engine). Content Fragment export via API is possible but component content, configuration, and workflow logic have no standard export path. Migrating away from AEM is a 6-12 month project requiring content re-architecture. This is the highest exit cost in the CMS market.

AEM requires learning JCR, Sling resolution, OSGi, HTL, Content Fragments vs Experience Fragments vs page components, dispatcher, Cloud Manager, client libraries, editable templates, and more. The mental model is unlike any other web platform. Even experienced Java developers need months to become productive. The concept count is the highest of any platform in this framework.

Experience League provides structured learning paths. WKND tutorial is a solid getting-started experience. Certification programs available (AD0-E116, AD0-E132). However, the gap between tutorial and production is enormous. Training typically requires 2-4 weeks of dedicated learning before any productivity. SI partners often provide their own training — a sign that official resources aren't sufficient.

AEM's core is Java + OSGi — not React, not Node.js, not any mainstream frontend framework. SPA Editor supports React/Angular for frontend, but backend remains Java/OSGi/Sling. Edge Delivery Services uses vanilla JS. HTL is AEM-specific templating that transfers nowhere. Skills from AEM development transfer poorly to the rest of the web ecosystem. This is the weakest framework familiarity score in the framework.

AEM Project Archetype generates a solid project structure with core, ui.apps, ui.frontend, and dispatcher modules. WKND serves as a comprehensive reference. Core Components provide production-ready base components. However, the archetype generates a complex multi-module Maven project — overwhelming for newcomers. The distance from generated project to production is significant.

OSGi configuration surface is enormous — hundreds of configurable services. Run modes for environment-specific config. Dispatcher config (Apache + dispatcher module) is notoriously complex. Cloud Manager environment variables. Sling mapping for URL management. Replication agents. The configuration surface area is the largest of any platform in this framework by a wide margin.

Content Fragment Model changes are relatively safe — fields can be added without breaking existing content. JCR's flexible node structure accommodates schema evolution well. However, changing component dialog structures requires careful backward compatibility. Content migration for structural changes requires custom Groovy/Java migration scripts. No automated migration tooling.

In-context editing works well for traditional Sites — the editor IS the preview. SPA Editor provides preview for React/Angular SPAs but setup is complex. Universal Editor is simplifying this for headless, but it's still newer and adoption is growing. For headless CF-only implementations, preview requires custom frontend work to connect to author-tier APIs.

AEM requires the most specialization of any CMS in the market. Java, OSGi, JCR, Sling, HTL, dispatcher, Cloud Manager, and the AEM-specific patterns for components, templates, and workflows. Skills are not transferable — an AEM developer moving to a headless CMS needs to relearn almost everything. Certification is expected for production work at most enterprises.

Minimum viable production team: 2 backend devs, 1 frontend dev, 1 AEM architect, 1 DevOps/Cloud Manager specialist = 5 people minimum. Realistic enterprise team: 8-15+. A solo developer cannot ship a production AEM site in any reasonable timeframe. The platform demands role specialization that is unmatched by any competitor.

Content authors need training on the AEM authoring UI — not intuitive for users coming from WordPress or similar. Template policy configuration requires developer involvement. Workflow configuration needs developer support. Asset management in AEM Assets is relatively intuitive but still requires training. Marketing teams cannot self-serve beyond basic content editing without ongoing developer support.

Cloud Service auto-updates are a major improvement — no more painful 6.x version upgrades. However, auto-updates mean you must continuously ensure compatibility. Best Practice Analyzer helps identify issues. Custom code must stay within supported APIs (Javadoc-annotated). The upgrade burden has shifted from infrequent-but-painful to continuous-but-manageable.

Cloud Service handles security patching automatically — no manual intervention. Patches are rolled out by Adobe as maintenance releases. This is a genuine benefit of the managed model. However, third-party bundles and custom code are your responsibility. For AMS/on-prem customers, patching is manual and can be disruptive.

Adobe is forcing the migration from AEM 6.5/AMS to Cloud Service. EOL timelines are pushing enterprises onto the new platform regardless of readiness. The Content Transfer Tool helps but large migrations are still months-long projects. For existing AEM customers, this forced migration is the single biggest pain point — it's not optional, it's not cheap, and the timeline is Adobe's, not yours.

Cloud Service manages core platform dependencies — you don't manage the JVM, OSGi container, or Sling. Custom code dependencies are managed via Maven. AEM API dependencies are versioned and stable. However, third-party OSGi bundle compatibility with Cloud Service can be problematic. The Maven dependency tree for a typical AEM project is large.

Cloud Manager provides environment health dashboards, log access, and basic alerting. New Relic integration available for APM. However, deep monitoring requires additional tooling — New Relic, Datadog, or Splunk for comprehensive observability. Dispatcher and CDN monitoring have separate tools. The monitoring story is adequate but fragmented.

Content operations in AEM at scale are demanding. Link management requires attention — moved pages can break references. Tag taxonomy management grows complex. Workflow maintenance as editorial processes evolve. MSM Live Copy conflict resolution. Content Fragment model evolution across sites. Language copy synchronization. The operational surface area is proportional to AEM's capability — enormous.

Oak query performance requires index management — slow queries can degrade author performance. Dispatcher caching rules need regular tuning. CDN invalidation patterns affect site performance. JCR repository size affects backup and clone times. Cloud Service has improved auto-optimization but query performance and caching still require expertise.

Enterprise support tiers with P1-P4 severity levels. Dedicated TAMs for largest accounts. Response times are generally met but resolution quality varies — complex issues can bounce between support teams. The support experience is best for well-known issues and weakest for edge cases in custom implementations.

Experience League forums have active participation from both community and Adobe staff. However, Cloud Service-specific answers are a subset of the total content. Complex architectural questions often go unanswered or receive generic responses. The community is better for common patterns and worse for edge cases.

Bug fix turnaround varies significantly by severity. Critical production issues get fast attention. Feature requests move slowly — AEM's roadmap is Adobe-driven, not community-driven. Regressions in Cloud Service updates do occur and are generally fixed within 1-2 maintenance cycles. The hotfix process for Cloud Service is opaque — you can't request targeted patches.

Editable templates with template policies give excellent landing page control. Content authors can build pages from approved component palette with drag-and-drop. Style System enables visual variations without code changes. Experience Fragments for reusable page sections. Edge Delivery Services adds a fast, document-based authoring option. This is one of AEM's core strengths.

Launch capabilities for campaign scheduling. Integration with Adobe Campaign for email. Workfront integration for campaign planning. Targeted Content for campaign-specific personalization. However, AEM itself is not a campaign management tool — it provides content execution within the Adobe Campaign/Workfront ecosystem. Without those additional products, campaign management is basic scheduling only.

Sitemap generation, meta tag components, canonical URL management, redirect mapping via Sling mappings or dispatcher rules. Structured data can be rendered via components. AEM provides solid SEO foundations. However, SEO analysis, scoring, and recommendations are not built in — you need third-party tools (Yoast equivalent doesn't exist for AEM). URL management can be complex with JCR-based paths.

AEM Forms provides form handling but is a separate product/license. Core Components include a basic form component. CTA management via component configuration. Conversion tracking via Adobe Analytics integration. Lead capture requires Forms or custom development. Performance marketing features exist across the Adobe stack but not natively in AEM Sites.

Content Fragments can model rich product content with variants, attributes, and media. AEM Assets excels at product media management. However, AEM is not a PIM — product data modeling is handled by the commerce backend, with AEM providing content enrichment. The content-commerce boundary is clear but means product content lives in two systems.

CIF provides category page components, product carousels, cross-sell/upsell components. Search merchandising via commerce backend integration. Promotional content through standard CMS capabilities. However, actual merchandising logic lives in the commerce engine — AEM provides the presentation layer, not the merchandising intelligence.

CIF provides deep Adobe Commerce integration with GraphQL federation — product data available in author, cached at edge, real-time on publish. commercetools connector available. The commerce architecture is well-designed for content-commerce blending. However, non-Adobe commerce integrations require more custom work. The synergy is strongest within the Adobe ecosystem.

CUGs provide granular publish-tier access control. LDAP/SAML integration for employee authentication. Group-based content visibility. Department-level content isolation via ACLs. The access control model is enterprise-complete. However, audience-based dynamic content visibility is limited without Adobe Target integration.

AEM can serve as a knowledge base — taxonomy via tags, full-text search via Oak. However, it lacks purpose-built knowledge management features — no knowledge base templates, no article feedback mechanisms, no built-in FAQ patterns, no knowledge graph. AEM is a content management system, not a knowledge management platform. Purpose-built tools (Confluence, Notion) serve this need better.

AEM can build a portal but it's not designed for employee experience. No notification system, no social features (likes, comments on content), no employee directory, no personalized employee dashboard. Building an intranet in AEM is possible but you're building everything from scratch using general CMS capabilities. Better served by SharePoint, LumApps, or purpose-built intranet platforms.

MSM with per-site configurations provides genuine tenant isolation. Content tree separation, user group isolation, template policies per site, OSGi config per site. Multiple brands can operate independently with centralized governance. This is AEM at its strongest — the multi-tenant architecture is battle-tested at enterprises running 100+ sites.

Core Components serve as a shared foundation. Blueprint pages provide shared content with brand-specific Live Copies. Template policies control which components are available per brand. Style System enables brand-specific visual treatment of shared components. The shared-with-override model is the most mature of any CMS platform.

Centralized blueprint governance with brand-level autonomy. Rollout configurations control inheritance behavior. Cross-brand approval workflows. Template policies enforce brand-level component availability. User groups provide administrative isolation. This is genuinely the gold standard for multi-brand governance — no other platform matches AEM's depth here.

Additional sites within an AEM environment have low marginal infrastructure cost — MSM handles many sites efficiently. However, licensing scales with traffic across all sites. Each additional site adds content operations burden. The per-brand increment is moderate — better than running separate instances but the base cost is so high that the efficiency is relative.