AEM as a Cloud Service Migration: What the Move Actually Involves

Most migration guides are a numbered list that ends at "go live". This one covers the parts that consume the schedule: what the Content Transfer Tool will and will not do, what a cloud build rejects outright, and where projects actually stop.

The shape of the work

A migration to AEM as a Cloud Service has four workstreams that run in parallel, not in sequence:

1. Code — restructuring the repository and fixing everything the cloud will not accept.
2. Content — extraction, ingestion, validation, top-ups.
3. Integrations — the third-party systems your AEM talks to.
4. Operating model — Cloud Manager pipelines, quality gates, observability, and how your team works when it cannot log into a server.

The fourth is the one that gets left out of plans and then delays go-live.

Step 0: assessment

Run Adobe's Best Practices Analyzer / AEM Analyzer against production before anything else. It produces the list that drives your estimate. Alongside it, inventory by hand:

• Custom OSGi bundles, their authors, and whether anyone still understands them
• Third-party integrations and who owns each remote system
• Custom Oak index definitions
• Anything that writes to the repository at runtime
• Workflow customisations and custom launchers
• Content volume: node store size and data store size, because these drive the transfer plan

Repository restructuring

AEM as a Cloud Service separates mutable from immutable content and enforces it at build time. Legacy 6.5 projects almost always ship one content package that mixes both.

The target structure:

• ui.apps — immutable. Components, templates, client libraries, anything under /apps.
• ui.content — mutable. Content, tags, and editable configuration.
• ui.config — OSGi configuration, per run mode.

What breaks:

• Runtime writes to /apps. On 6.5 this worked. On Cloud Service /apps is immutable at runtime and the code has to be redesigned, not relocated. This is genuine rework, not repackaging.
• Mutable nodes inside an immutable package. The build rejects it. There is no override.
• nt:file and binary content in ui.apps that should be in the data store.
• Custom index definitions that need to move into the codebase under /oak:index and be deployed through the pipeline rather than created by hand.

Expect this workstream to take longer than the estimate. It is unglamorous, it touches everything, and it cannot be parallelised past a certain point because the packages depend on each other.

Content transfer: the Content Transfer Tool's real constraints

CTT works well. The failures come from planning against assumptions rather than against its documented limits.

Disk space. The requirement is data store size + node store size × 1.5 in free space on the source. A 20 GB segment store needs roughly 94 GB free before extraction starts. The tool caps its own data store use at 64 GB. Projects discover this at 2am on extraction night more often than they should.

Migration sets are capped at ten per project in Cloud Acceleration Manager, concurrently. Plan the split of your content up front — by site, by locale, by DAM branch — rather than discovering the cap mid-programme.

The extraction key expires after 14 days from creation or renewal. Long-running programmes need this diarised.

Minimum source version is AEM 6.3 with Java 8. Older sources need an intermediate upgrade first, which is its own project.

CTT does not merge. There is no merge ingestion. If your content lives across multiple source instances, you consolidate onto one source before you transfer. This surprises organisations with separate author instances per brand and it can add months.

CTT does not analyse content. It does not differentiate published from unpublished, and it will not prune for you. Content cleanup is a separate, manual exercise — and it is worth doing before transfer, because you pay for the volume in time on every rehearsal.

Only groups required by content permissions transfer. Users, and groups not referenced by permissions, are handled separately.

Custom indexes must exist before ingestion. CTT will not create them. Indexing after the fact on a large repository is slow enough to blow a cutover window.

The Author downtime nobody plans for

The ingestion phase scales the entire Author deployment down. Author is unavailable for the duration, and no Cloud Manager pipeline may run concurrently.

That is a planned outage, and its length is a function of content volume — which you only learn by rehearsing. Rehearse ingestion at full content volume at least twice before the real cutover. The first rehearsal tells you the duration. The second tells you whether your fixes held.

Top-ups

Top-up ingestion moves content that changed between the initial extraction and cutover, which is how you avoid a content freeze measured in weeks.

The rules that catch people:

• Content structure cannot change between the initial extraction and the top-up. Restructuring during the freeze window invalidates the top-up.
• With wipe=false and versions included, version purging must be disabled on the source for the duration.
• If you do want version purging, use top-ups with wipe=true instead.

Decide the version strategy early. Changing it late means re-running extraction.

Integrations: where migrations actually stall

Content transfer is a solved, tool-driven problem with documented limits. Integrations are not.

The pattern we see repeatedly: a ten-year-old integration into a system whose owning team has been reorganised twice, with no documentation, no test environment, and a hard-coded hostname that worked because AEM sat inside the same network. On Cloud Service it does not, and now it needs an allowlist, a service account, a rewrite, or all three — from a team that does not know it is on the critical path.

Inventory integrations in week one. Contact each owning team in week two. The lead time on someone else's change request is the thing you cannot compress later.

The operating model change

After cutover your team works differently, and if that is not planned for, velocity drops for a quarter.

• No shell. Debugging is log-driven. Set up log forwarding to a stack your engineers can actually query, before go-live.
• Cloud Manager is the only deploy path. Quality gates block releases — Security Rating below B fails outright, and coverage below 50% pauses the pipeline. Clear the gate debt during migration, not after. See Cloud Manager CI/CD pipelines.
• Adobe updates on Adobe's schedule. Custom code must survive updates you did not plan. This is a standing argument for using Core Components over bespoke ones wherever the design allows.
• Asset processing moves off Author. Rendition generation runs in asset compute microservices. Custom rendition logic needs porting.

A realistic sequence

Phase	Work	Typical duration
Assessment	Analyzer run, code and integration inventory, sizing	2–4 weeks
Restructure	Repository split, immutability fixes, index definitions into code	6–12 weeks
Pipeline	Cloud Manager setup, quality gate remediation, build-time work	3–6 weeks, overlapping
Integrations	Rework and remote-team lead times	8–16 weeks, overlapping
Content rehearsal 1	Full-volume extraction and ingestion, timed	2–3 weeks
Fix and rehearsal 2		3–4 weeks
Cutover	Final top-up, DNS, validation	1 week
Stabilisation		4–8 weeks

Six to twelve months end to end. The ranges overlap because the workstreams run in parallel; the critical path is almost always integrations.

Getting help

We run migrations as fixed-scope engagements starting with the assessment, and we will tell you if the honest answer is AEM 6.5 LTS rather than a migration you cannot finish in time. See Adobe Experience Manager services or request a quote.

Common questions

How long does an AEM cloud migration take?

Six to twelve months for an enterprise estate, driven by custom code volume, integration count and content volume in that order. A single site with light customisation can be faster.

Can we migrate content without downtime?

Not entirely. The Author deployment scales down during ingestion, so there is a planned Author outage. Publish-side downtime can be avoided with a parallel run and a DNS cutover. Top-up ingestion keeps the content freeze short.

What does the Content Transfer Tool not move?

It does not merge from multiple sources, does not analyse or prune content, does not differentiate published from unpublished, does not create custom indexes, and transfers only the groups required by content permissions.

Do we have to rewrite our components?

Not necessarily, but you will rewrite anything that writes to the repository at runtime, anything that depends on server-local state, and custom rendition logic. Components built on Core Components generally port with modest effort; deeply bespoke component libraries do not.

What usually goes wrong?

Third-party integrations, by a wide margin — because the fix depends on a team that does not report to you. After that: quality-gate debt discovered at the first cloud release, and content volume that made rehearsal ingestion longer than the cutover window allowed.

Should we move to Edge Delivery Services at the same time?

Usually not in the same cutover. EDS and AEM Sites can coexist on one domain and consume each other's content, so migrating first and adopting EDS progressively afterwards carries far less risk than doing both at once. See Edge Delivery Services.

---

Related reading: Adobe Experience Manager services · AEM 6.5 end of life · Cloud Manager CI/CD pipelines · What AEM costs