Previous Article
AEM Edge Delivery Services vs AEM Sites: Which Should You Choose?
4 November 2026
Short answer: moving from AEM 6.5 to AEM as a Cloud Service is a modernisation project, not a simple upgrade. Your code has to be restructured for an immutable, auto-scaling cloud platform, your content is moved with Adobe's Content Transfer Tool, and your team changes how it builds, deploys and operates AEM. Most projects take three to twelve months, depending on how much custom code, how many sites and how much content you have. The biggest risks are custom code that does not fit the cloud model, underestimated content volume, and SEO losses at go-live.
This guide explains what changes, the steps of a typical migration, what drives cost and timeline, the risks to plan for, and how to decide when to move.
Why companies are moving to AEM as a Cloud Service
AEM 6.5 is installed and run by you or a managed services partner. You plan upgrades, apply service packs, size servers and manage scaling. AEM as a Cloud Service (often shortened to AEMaaCS) moves that work to Adobe.
- No more upgrade projects. Adobe updates the platform continuously, so you are always on the current version. The large, risky upgrade every few years disappears.
- Automatic scaling. Publish capacity scales with traffic, so campaign spikes do not need extra servers planned in advance.
- Built-in CDN and security. A managed CDN, automated security updates and Adobe's compliance certifications are part of the service.
- Access to new features. Edge Delivery Services, the Universal Editor, asset microservices and much of Adobe's newer AI tooling are built for the cloud platform first.
- Support timelines. Adobe publishes support dates for each on-premise version. Check Adobe's current support policy for AEM 6.5 so you plan a migration on your own schedule, not in a hurry before support ends.
Adobe also offers AEM 6.5 LTS for organisations that must stay on-premise or on managed services. It is a valid option for some, but it is still an upgrade you operate yourself, and it does not include the cloud-only features above.
What actually changes
The cloud platform runs AEM in containers that start, stop and scale automatically. That one fact drives most of the changes your team must make.
| Area | AEM 6.5 | AEM as a Cloud Service |
|---|---|---|
| Upgrades | Planned upgrade projects and service packs | Continuous, automatic updates from Adobe |
| Code structure | Code and content can be mixed in packages | Separate immutable code (/apps, /libs) and mutable content packages |
| Deployment | Package Manager, manual or scripted | Cloud Manager pipelines only, with quality gates |
| Configuration | Edited on servers, custom run modes | Stored in code, a fixed set of run modes, environment variables in Cloud Manager |
| Asset processing | DAM Update Asset workflow on the author server | Asset microservices in the cloud, with processing profiles |
| Publishing | Replication agents | Sling Content Distribution, managed by Adobe |
| Search indexes | Changed directly on the server | Custom indexes deployed as code with a naming convention |
| Scaling | Fixed number of servers | Automatic, so code must not rely on local files or a single server |
| Users and login | Local users, LDAP or SAML | Adobe IMS for authors; publish-side login needs its own design |
| Logs and monitoring | Direct server access | Cloud Manager logs, log forwarding and the Developer Console |
None of this changes how authors experience pages day to day, but almost all of it changes how developers build and run the platform.
The migration, step by step
1. Assess readiness
Start by running Adobe's Best Practices Analyzer on your AEM 6.5 author environment. It produces a report of everything that will not work on the cloud platform: deprecated features, code in the wrong place, custom indexes, replication agents, workflow launchers on assets and more. Upload the report to Cloud Acceleration Manager, Adobe's web tool for planning the migration, to see the findings grouped by effort.
Alongside the tool, audit the things it cannot see: integrations with other systems, custom authentication, scheduled jobs, how much content and how many assets you have, and which sites and pages bring the most traffic.
2. Plan and set up
Decide the scope, order and timeline. Will you move everything at once, or one site or brand at a time? Will you clean up unused templates and components now? Is this also the moment to move some public pages to Edge Delivery Services?
Then provision your Cloud Service programme and environments (development, stage and production) in Cloud Manager, set up the Git repository and pipelines, and give developers local AEM SDK environments.
3. Refactor the code
This is usually the largest piece of work. Adobe provides tools that do much of the mechanical part:
- Repository Modernizer restructures your project into the separate code and content packages the cloud requires.
- Index Converter turns custom Oak index definitions into the format the cloud expects.
- Dispatcher Converter rewrites Dispatcher configuration into the cloud structure.
- AEM Modernization Tools convert static templates to editable templates and older foundation components to Core Components.
The rest is engineering judgement: replacing replication agents and custom asset workflows, removing anything that writes to the local file system, moving server-side configuration into code, adapting long-running jobs so they survive container restarts, and updating integrations. Code must also pass the quality gates in Cloud Manager pipelines, so existing code-quality problems will surface here.
4. Move the content
Content and assets are moved with Adobe's Content Transfer Tool. It runs in two phases: extraction from AEM 6.5 into a cloud migration set, then ingestion into your Cloud Service environment. Because authors keep working during the project, you run a large initial transfer early, then smaller top-up transfers to bring across new and changed content before go-live.
Clean up first. Removing old versions, unused assets and abandoned sites makes every transfer faster and cheaper to test. Users and groups also need mapping to Adobe IMS, and asset processing should be checked after ingestion.
5. Test
Test the platform the way people use it:
- Functional testing of every template, component, form and integration.
- Author testing with real authors: editing, workflows, translation, publishing and asset upload.
- Performance and load testing, including cache behaviour at the CDN and Dispatcher.
- SEO checks on URLs, redirects, canonical tags, sitemaps, metadata and structured data.
- Security and access testing of permissions and any logged-in areas.
6. Go live and stabilise
Freeze content briefly, run a final top-up transfer, switch DNS to the cloud CDN, and watch traffic, errors and Core Web Vitals closely for the first weeks. Keep the AEM 6.5 environment available for a short period as a fallback and for reference, then decommission it.
What drives cost and timeline
Migration costs vary widely, so be wary of any fixed figure quoted before an assessment. These are the factors that make a migration bigger or smaller:
- Custom code. The number of custom components, services, workflows and overlays of Adobe code is the biggest single factor. Heavy overlays and old patterns take the longest to fix.
- Integrations. Each connection to CRM, commerce, search, identity, analytics or internal systems needs reviewing and retesting.
- Content and asset volume. Large repositories take longer to transfer and test, especially with many versions and large media files.
- Number of sites and languages. Multi-site and translation setups add configuration and test effort.
- Code quality. Cloud Manager quality gates will expose existing technical debt, and some of it must be fixed to deploy.
- Scope changes. Redesigns, Core Components adoption or moving to Edge Delivery Services add value, but also add work.
As a rough guide, a single site with modest customisation often migrates in three to four months. A typical enterprise platform with several sites and integrations takes four to eight months. Large multi-brand, multi-region platforms with heavy customisation can take nine to twelve months or more.
On running costs, the cloud licence replaces separate spending on servers, hosting, upgrade projects and much of the operations work. Compare the total cost of ownership over several years, not just the licence against your current hosting bill.
The risks, and how to manage them
| Risk | What goes wrong | How to prevent it |
|---|---|---|
| Underestimated code changes | Refactoring takes far longer than planned | Run Best Practices Analyzer first and size the work from its findings, not from guesswork |
| Slow content transfer | Transfers run late and delay go-live | Clean up content first, test a full transfer early, and plan top-ups |
| SEO traffic loss | Changed URLs, missing redirects or lost metadata hurt rankings | Keep URLs, map every redirect, compare crawls before and after launch |
| Broken integrations | Forms, search or CRM sync fail after launch | List every integration up front and test each one end to end |
| Asset processing surprises | Renditions or metadata differ from AEM 6.5 | Recreate custom processing as processing profiles and test with real files |
| Author disruption | Long content freezes or unfamiliar tools slow the team | Keep freezes short with top-up transfers, and train authors before launch |
| Skills gap | The team knows AEM 6.5 but not Cloud Manager or cloud patterns | Bring in experienced Cloud Service developers early and pair them with your team |
| Scope creep | Redesign ideas pile up and the migration never finishes | Migrate first, improve second, unless a change clearly reduces migration effort |
Is now the right time to migrate?
Migration is usually a good idea now if:
- Your next AEM 6.5 upgrade, server refresh or hosting renewal is coming up.
- Your site struggles under traffic peaks or is slow to scale.
- You want Edge Delivery Services, the Universal Editor or Adobe's newer AI features.
- Your team spends too much time on infrastructure instead of features.
It may be worth waiting, or considering AEM 6.5 LTS, if you have strict data-residency or hosting rules that the cloud cannot meet, or a major business launch in the next few months that cannot share attention with a migration.
Frequently asked questions
Is moving to AEM as a Cloud Service an upgrade?
Not in the usual sense. The authoring experience feels familiar, but the code structure, deployment, configuration and operations all change. Plan it as a migration project with its own budget and timeline.
How long does an AEM 6.5 to Cloud Service migration take?
Most projects take three to twelve months. Small sites with little customisation sit at the short end; large, heavily customised multi-site platforms sit at the long end.
Can authors keep working during the migration?
Yes. The Content Transfer Tool supports an initial transfer followed by top-up transfers, so authors keep working on AEM 6.5 and only a short content freeze is needed before go-live.
Will we lose SEO rankings when we migrate?
You should not, if you keep URLs stable, redirect anything that changes, and carry over metadata, canonical tags, sitemaps and structured data. Compare a crawl of the old site with the new one before switching DNS.
Do we need to rewrite all our components?
Usually not. Many components move with structural changes only. Components that overlay Adobe code, write to the file system or rely on deprecated features need more work. Moving to Core Components is recommended but can be done in stages.
Can we move to Edge Delivery Services at the same time?
Yes, and some teams do this for their highest-traffic public pages. It adds front-end work, so many teams migrate the platform first and move selected sections to Edge Delivery Services afterwards.
How Being Idea can help
Being Idea helps companies plan and deliver AEM 6.5 to Cloud Service migrations. We run the readiness assessment, size the work from real findings, refactor code with experienced AEM Java and front-end developers, manage content transfer, and protect SEO through launch. For regulated organisations we plan around approval and audit needs, as described in our guide to AEM for banking and insurance websites. You can hand us the whole migration or add dedicated AEM developers to your own team. Tell us about your AEM platform and we will reply within one business day.