Why AEM Cloud migrations become harder than expected

An AEM Cloud migration is often described as a platform upgrade with a content move attached. That description is tidy, commercially convenient and usually wrong.

The real change is broader: the application must fit a cloud-native deployment model; content and assets must survive extraction, transfer and validation; operational habits built around mutable servers must change; and the organisation must decide who owns the platform after the programme team leaves. A migration can be technically successful and still leave authors slower, release teams frustrated and the business carrying the same structural debt on newer infrastructure.

The hard part is not moving AEM. It is deciding what should be allowed to move with it.

The migration is four programmes hiding inside one

Most plans have a single line called “AEM migration.” In practice, there are at least four connected programmes.

The first is application modernisation. AEM as a Cloud Service separates mutable content from immutable application code and routes production changes through Cloud Manager. Runtime modifications that were tolerated on older estates no longer fit the operating model. Custom indexes, OSGi configuration, package structure, dispatcher rules and deployment assumptions all need to be examined rather than copied.

The second is content and asset migration. Adobe’s own guidance recommends proof migrations because extraction and ingestion time depends on repository volume, blobs, bandwidth, memory, disk I/O and the state of the source estate. Missing renditions, malformed nodes, obsolete versions and inconsistent taxonomy are not abstract data-quality issues. They affect processing, validation, author downtime and cutover confidence.

The third is delivery engineering. Teams move from maintaining named servers to working with repeatable pipelines, environment parity, automated quality gates and a platform that can replace running instances. Deployment becomes more disciplined, but only if the codebase and team practices are ready for it.

The fourth is operating-model change. Authors, administrators, engineering, security, release management and business owners need a shared model for access, support, content governance and change. Cloud infrastructure removes some operational work. It does not remove the need to operate the product.

If the business case funds only one of these four, the others reappear later as delay, scope change or production risk.

Why the estimate is usually optimistic

Migration estimates are commonly based on page counts, repository size and a high-level scan of custom components. Those numbers matter, but they do not describe the effort required to understand the estate.

Two sites with the same number of pages can have completely different migration profiles. One may use a disciplined component library, clean content models and current integrations. The other may depend on overlays, direct repository writes, custom workflows, old service users, duplicated templates, hard-coded paths and undocumented publishing procedures. The second estate is not merely “larger.” It has more unknown behaviour.

The estimate also misses decision latency. Which old campaigns can be archived? Who can approve taxonomy changes? Can a custom workflow be removed, or does a regional team still depend on it? Is an integration genuinely required at launch? Waiting for these answers can consume more elapsed time than rewriting the code.

A credible estimate therefore measures uncertainty, not just inventory. It identifies the decisions, owners and evidence required to retire uncertainty before the critical path reaches cutover.

Content debt is still debt

Moving every page and asset can feel safer than deciding what to leave behind. It is often the riskier choice.

An uncurated repository increases extraction time, validation effort, search noise, storage and asset-processing work. It also transfers unclear ownership into the new environment. Once the migration finishes, users reasonably assume the content is current and supported because the programme chose to bring it across.

The right question is not “Can the transfer tool move this?” It is “Should this content remain part of the governed digital estate?”

That leads to a disposition model before migration:

• retain and migrate because the content has a current owner and purpose;
• transform because the content is valuable but does not fit the target model;
• archive because it must be retained but not actively served; or
• delete through an approved retention process.

This is editorial and legal work as much as technical work. It needs named business owners, not a spreadsheet quietly assigned to the migration team.

Customisation has to earn its place again

Legacy AEM implementations often contain customisations built for valid historical reasons: product gaps, deadlines, acquisitions, agency preferences or requirements that no longer exist. A migration is the moment to challenge each one.

The useful test is not whether custom code still runs. It is whether it still creates differentiated business value that outweighs its lifecycle cost.

Every retained customisation should have:

• a current business owner;
• an explicit reason the supported platform capability is insufficient;
• automated tests around the business behaviour it protects;
• an owner for upgrades, security and production support; and
• a planned retirement trigger.

If nobody can provide those answers, compatibility work is preserving uncertainty rather than preserving value.

The people risk is larger than the server risk

Cloud migrations often focus on engineering readiness while authors are introduced to the target environment late. That is backwards. The authoring operating model determines whether the platform will be used as designed or bypassed through manual workarounds.

Authors need to validate real journeys: creating a campaign, reusing an asset, requesting approval, scheduling a release, localising a page, correcting a live issue and understanding why publication failed. Training should be based on those tasks, not a tour of the interface.

Access design also needs attention. AEM access can span identity entitlements, local groups and repository permissions. “The user has an Adobe profile” does not necessarily mean the user can perform the required operation. Roles should be tested end to end with representative users before launch.

A safer migration shape

We prefer a migration to move through evidence gates rather than calendar phases.

Establish the baseline. Record platform versions, repository health, content volumes, workflow inventory, indexes, integrations, release frequency, lead time, incident history and author pain points. If the baseline is vague, claimed improvement will be vague too.

Run code and content discovery together. Code scans reveal technical incompatibility; content profiling reveals what the code actually has to serve. Neither view is sufficient alone.

Prove the migration early. Use a representative slice containing difficult assets, permissions, workflows, localisation and integrations—not the cleanest microsite. Measure extraction, ingestion, validation, reprocessing and author freeze time.

Reduce before rebuilding. Archive content, remove unused components, retire redundant workflows and narrow integration scope before target-state implementation.

Test operations, not only features. Include rollback, failed deployment, permission error, stale content, asset reprocessing, support escalation and emergency publishing scenarios.

Rehearse cutover as a business event. Define content freeze, delta transfer, validation ownership, go/no-go criteria, rollback conditions and communications. A technically available website is not sufficient if authors cannot safely resume work.

What to measure

Migration success should not be a binary “live/not live” measure. Track a balanced set of outcomes:

• percentage of content with a named owner and disposition decision;
• custom code and workflow reduction;
• deployment lead time, failure rate and recovery time;
• migration validation exceptions by type and recurrence;
• author task completion time and support demand;
• search and asset-processing quality;
• platform cost against an agreed workload baseline; and
• production incidents attributable to migrated debt.

These measures prevent the programme from declaring victory while the operating burden simply changes shape.

When a like-for-like move is reasonable

There are cases where aggressive transformation during migration is the wrong call. A regulatory deadline, expiring infrastructure contract or severe operational risk may make a tightly controlled compatibility move necessary. That can be a sensible decision if the deferred modernisation is explicit, funded and owned.

The danger is calling a constrained first move “transformation” and assuming the debt disappeared. It did not. It was scheduled for later, whether the roadmap admits it or not.

Adovo’s view

The best AEM Cloud migrations are not the ones with the largest rewrite. They are the ones that make the estate easier to understand and operate.

Move less content, preserve less accidental customisation, prove difficult paths early and make ownership visible. Cloud capability then becomes leverage. Without that discipline, the organisation gets a modern platform carrying an old operating model—and wonders why the migration feels harder after go-live than it did before.

Primary documentation and further reading

• Adobe AEM Cloud migration journey