Adobe Experience Cloud
AEM is not the problem—unmanaged content operations are
When AEM feels slow or overcomplicated, the root cause is often an unmanaged content operating model: unclear ownership, workflow sprawl, weak taxonomy and customisation without lifecycle discipline.
June 4, 2026
When an AEM estate becomes slow, expensive or difficult to change, the platform is an easy target. Sometimes it deserves the criticism. More often, it is exposing decisions the organisation never made.
Who owns a component after launch? Which team can change a taxonomy? How many approval paths are genuinely required? Who removes old workflows, permissions and integrations? What is the supported way to launch a new market? Which content must be archived?
Without clear answers, AEM becomes the place where years of exceptions accumulate. Replacing it may change the interface and commercial model. It will not automatically change those habits.
A platform becomes the shape of its operating model
AEM is flexible enough to support multiple sites, assets, workflows, permissions, integrations and delivery patterns. That flexibility is useful. It also means the platform rarely prevents an organisation from encoding a poor process.
One team adds a workflow for legal review. Another creates a similar workflow for a region. An agency builds a component for a campaign and nobody retires it. Permissions are granted directly to individuals because group design takes longer. Asset folders mirror the organisation chart rather than how people search. Tags multiply without ownership. Scheduled jobs and custom queries work at launch but degrade as content volume grows.
Each decision is locally reasonable. Together they create an estate that no one can explain end to end.
The problem is not “too much AEM.” It is too little product management around AEM.
Workflow is not governance
Organisations often translate every governance concern into an approval step. The result is workflow sprawl: long queues, unclear status, abandoned instances and editors moving coordination into email or chat.
A workflow should automate a stable, repeatable decision. It should not compensate for ambiguous authority.
Before building or preserving a workflow, ask:
- What risk does this control?
- Who has the authority to approve?
- What evidence must the approval retain?
- Is the decision required for every item or only a risk class?
- What happens when the approver is unavailable?
- How will old instances be completed or purged?
- What service level does publishing depend on?
If the team cannot answer those questions, adding another step makes uncertainty slower rather than making the content safer.
Adobe community discussions show the operational consequences of scale: workflow backlogs can delay scheduled publishing, and accumulated workflow instances can contribute to performance problems. These are technical symptoms, but the durable fix includes controlling when workflows are created and who owns their lifecycle.
Content structure needs a steward
Components, templates, content-fragment models, metadata schemas and tags form the language of the platform. When that language grows without governance, authors cannot tell which option is current or safe.
The organisation needs a lightweight design authority with real decision rights. Its job is not to review every page. It owns the shared grammar:
- approved components and their lifecycle;
- content models and backwards-compatible change;
- global and local taxonomy;
- accessibility and brand constraints;
- shared asset metadata;
- deprecation and migration; and
- evidence that a requested exception is worth permanent complexity.
This authority must include content operations and engineering. A schema that is elegant in code but unusable for authors is not governed well. Neither is a flexible author feature that creates an unsupported delivery contract.
Permissions reveal organisational ambiguity
AEM permissions can involve identity product profiles, local groups, repository paths and inherited access-control entries. Direct grants and nested exceptions are tempting because they resolve today’s request. Over time, nobody can confidently explain why a person can or cannot perform an action.
Use role-based groups aligned to stable responsibilities, not named projects or individual people. Test effective access with representative users. Review privileged groups and dormant access. Give temporary access an expiry path. Document which layer grants entitlement and which layer grants action.
The goal is not a perfect permission diagram. It is the ability to answer, quickly and with evidence: who can view, edit, approve, publish, delete and administer this part of the estate?
Custom code needs product economics
AEM receives criticism for implementation cost because customisation can expand quietly. The discipline should be simple: custom capability must pay rent.
For every custom component, integration or console extension, record the user, business outcome, owner, support path, test coverage and retirement condition. Track usage. If a component is rarely used, overlaps a supported capability or repeatedly blocks upgrades, remove it.
This is not an argument for zero customisation. Enterprises have differentiated needs. It is an argument against permanent customisation without permanent ownership.
Performance problems are often delayed design feedback
Repository traversal, unbounded queries, asset-processing workflows, replication queues and large-scale bulk operations may be invisible in early environments. They emerge when content, traffic and concurrency grow.
Treat performance as an operating signal. A query warning is not merely a tuning task; it may show that a reporting feature asks the repository to do work it was not modelled to do. A workflow backlog may show an approval design that cannot handle campaign peaks. Slow asset processing may reflect unnecessary renditions or missing metadata controls.
Resolve the immediate technical issue, then examine the process that keeps producing it.
A practical recovery sequence
Do not begin with a transformation programme. Begin with evidence.
Map demand. Identify the highest-volume author journeys, release paths, asset operations and support requests. Talk to authors doing the work, not only platform owners.
Create an estate inventory. Record sites, templates, components, models, workflows, launchers, scheduled jobs, indexes, integrations, groups and direct permissions. Add owner, usage and lifecycle status.
Stabilise production risks. Address workflow backlogs, traversal, unsupported changes, excessive privileges, fragile integrations and missing recovery procedures.
Reduce choices. Retire unused components and workflows, consolidate taxonomies, replace direct grants with roles and create paved paths for common page and campaign types.
Establish product governance. Give a cross-functional owner authority over roadmap, architecture, content standards, service levels and deprecation.
Measure the operation. Track author lead time, publishing failure, support demand, component reuse, workflow age, platform incidents and upgrade effort.
This sequence creates value even if the organisation later replatforms. It also produces the evidence needed to know whether replacement is justified.
When the platform really is the constraint
There are legitimate reasons to move: unsupported versions, a delivery model that no longer fits the channel strategy, commercial terms that are unsustainable, missing regulatory capability, scarce skills, or a level of architectural debt that is more expensive to unwind than replace.
The test is whether the constraint remains after the operating model is made explicit. If a required capability still cannot be delivered at acceptable cost and risk, replatform with a stronger case. If the same ownership gaps would follow the content into any CMS, fix them first or fund them as part of the move.
Adovo’s view
An enterprise CMS is not a website tool. It is a shared production system for content, brand, risk and customer experience.
Treat AEM as a product with named ownership, a controlled language, measurable service levels and a lifecycle for custom capability. That will not make every problem disappear. It will make problems legible—and legible systems are far easier to improve than estates built from undocumented exceptions.