What Does an AEM Migration Cost?

AEM migration cost is driven by four factors: the age and cleanliness of the codebase, the size and shape of the content repository, the number of systems integrated with AEM, and the level of testing and parallel running the organisation requires. In effort terms: a small, well-built site moves in 8-12 weeks with two to three people. A typical enterprise implementation takes 4-9 months with a team of four to six. A heavily customised multi-site platform can take 9-18 months. Code remediation, not content transfer, is usually the largest share of the work.

Any figure quoted before someone has read your Best Practices Analyzer report is a guess. What follows is how the effort is composed, so you can size your own project honestly.

What are the main cost drivers?

• Codebase age and quality. A project built on a recent Maven archetype with current APIs migrates in a fraction of the time of one carrying a decade of deprecated API usage, copied Adobe library code, and patterns Cloud Service forbids. The Best Practices Analyzer report is a proxy for this: a few dozen findings is routine, thousands signal a remediation programme.
• Repository size and shape. Raw gigabytes matter less than structure: number of assets, depth of version history, count of orphaned or unpublished trees. A pruned repository migrates in days; an unpruned one adds weeks of transfer, validation, and reconciliation.
• Sites, languages, and MSM structure. Each site, language copy, and Live Copy relationship multiplies testing scope. Blueprint and rollout configurations must be verified working after migration, not assumed.
• Integration count. Every system touching AEM (SSO, PIM, DAM sync, analytics, personalisation, search, custom ETL against the JCR) is a workstream: reconnect, retest, and often redesign, because integration patterns that assumed server access or replication listeners do not carry over.
• Testing maturity. Teams with automated regression coverage on critical journeys migrate with confidence and small QA effort. Teams without it either fund a manual regression cycle per environment or accept risk at cutover. This driver is invisible in early estimates and large in real ones.
• Organisational factors. Approval chains, content freeze tolerance, release windows, and the number of environments to keep in sync add calendar time even when engineering effort is flat.

Why is code remediation the largest share?

Because AEM as a Cloud Service enforces constraints that 6.x never did, and every violation in the codebase is a task.

The repository is immutable at runtime under /apps, so anything that wrote there in production must be redesigned. The dispatcher configuration must be translated into Cloud Service's validated structure, and hand-grown filter and vhost rules rarely pass on the first attempt. Oak index customisations become code, deployed through the pipeline with a naming convention, and each custom index must be rebuilt and its queries re-verified. Asset workflows are replaced by asset microservices, so custom DAM Update Asset steps move to post-processing workflows or disappear. Custom replication listeners, reverse replication, filesystem writes, and long-running stateful jobs all need rework because instances are ephemeral and scaled automatically. Finally, all of it must pass Cloud Manager's code quality gates before it deploys at all.

Each item is small. The cost is that a mature 6.x codebase contains hundreds of them, and a share are discovered only when something fails in a Cloud environment. Discovery, not typing, is the expense.

What does content migration involve?

The mechanics are well served by Adobe's Content Transfer Tool: extract a migration set, transfer it, then run differential top-ups so authors keep working on the old system until cutover. A long content freeze is unnecessary with a properly planned top-up schedule.

The effort hides elsewhere. Version history should be pruned before transfer, not carried wholesale. Users and groups do not simply copy: author access moves to Adobe IMS, and permission models built on local users need mapping. Migration surfaces every content quality problem the old system tolerated: broken references, assets referenced but unpublished, trees nobody owns. Treat content migration as a data migration with reconciliation counts (pages in, pages out, assets in, assets out, per site) rather than a copy job. Teams that skip reconciliation find the gaps after go-live, through authors.

Large DAMs move in waves, ordered by business criticality, and the wave plan is a real planning artefact, not an afterthought.

What team shape do you need?

A typical migration runs with:

• One architect who owns remediation decisions, the dispatcher translation, and the cutover design. This is the role that prevents the project from rediscovering known problems slowly.
• Two to four AEM developers working through the remediation backlog and the pipeline setup.
• One QA engineer, ideally building automated regression on the critical journeys first, since that suite pays for itself across every environment promotion.
• A content or authoring lead on part-time allocation, owning reconciliation checks, author validation, and training.
• A project owner for sequencing, freeze negotiation, and integration scheduling with third parties.

The phase pattern is consistent: assessment (2-4 weeks), remediation and pipeline adoption (the bulk of the project), content migration with a parallel run, then cutover and hypercare (2-4 weeks). What the team no longer needs after go-live is dedicated AEM infrastructure engineering, which is where the long-term saving sits.

Which risk factors blow up the effort?

• Late discovery of custom authentication on publish. Closed user groups carry over, but registration and login flows built on locally administered users need a redesign and can surface as one in month four. Look for them in week one.
• Search parity. Custom Oak indexes must be rebuilt, redeployed, and re-tuned. Queries that were fast on 6.5 can traverse on Cloud Service until the index definitions are correct. Budget verification time per query surface.
• Cache behaviour at go-live. The dispatcher and CDN rules are new, and a cache hit ratio that drops at cutover shows up as a performance incident. Load-test against the real Cloud Service dispatcher configuration, not the old one.
• Scope creep. The recurring failure mode is bundling a redesign into the migration. Migrate as-is, then redesign on the new platform. Two medium projects in sequence finish; one double-sized project drifts.
• Uncertified connectors. Third-party integrations may not have a Cloud Service compatible release, and vendor timelines are outside your control. Inventory them in the first week and open the vendor conversations immediately.
• Undocumented server state. Config edits made through the OSGi console over the years exist nowhere in Git. They stop working in Cloud environments, and reconstructing intent takes archaeology. Assume some exist; go looking early.
• Content freeze politics. Top-ups reduce the freeze to days, but only if the schedule is agreed with the business early. A freeze negotiated in the cutover week costs calendar weeks.

How do you keep the cost down?

Run the Best Practices Analyzer before any planning, and let its findings, not optimism, set the estimate. Prune content, versions, and dead sites before transfer rather than paying to move them. Fix remediation items on 6.5 in advance where patterns allow, since cleaner code is worth having even if the migration slips. Build automated regression on the five most valuable journeys before touching anything else. Keep redesign out of scope. Each of these moves work earlier, where it is cheap, and the projects that follow this shape land inside the ranges above.

akenside.ai scopes and delivers these migrations as part of its Adobe Experience Cloud consulting.