Problems we solve / Moving to AEM as a Cloud Service
Moving to AEM as a Cloud Service
Moving from AEM 6.x or Adobe Managed Services to AEM as a Cloud Service changes how code is built, deployed and run. A successful move starts with knowing exactly what has to change. We assess the platform, size the effort and plan a migration that doesn’t surprise you halfway through.
What it looks like
- AEM 6.5 nearing the end of its support window
- Pressure to move to the cloud without a clear estimate
- Custom code and integrations nobody has inventoried
- Dispatcher and caching rules built for on-premises
- AEM Forms or legacy LiveCycle forms that also need to move
Why it happens
- AEM as a Cloud Service runs as an immutable, auto-updating platform, so some on-premises patterns no longer work
- Older code often uses deprecated APIs or writes to the repository at runtime
- Integrations and scheduled jobs are frequently undocumented
How we diagnose it
- Repository and code analysis with Adobe’s Best Practices Analyzer
- Deprecated API scan
- Dispatcher and CDN review
- Integration inventory
- Migration complexity score
What we usually recommend
- A migration plan with phases, effort and risks
- Which code to refactor, retire or rebuild
- Whether some page families should move to Edge Delivery Services
Adobe technologies involved
- Adobe Experience Manager as a Cloud Service
- Cloud Manager
- AEM 6.5
- Dispatcher
- AEM Forms
- Edge Delivery Services
Common questions
What is the first step in moving to AEM as a Cloud Service?
A readiness assessment: analyze the repository, code, dispatcher and integrations, then score how complex the move will be.
What happens to our AEM Forms when we move to the cloud?
Adaptive Forms and Communications can move to AEM Forms as a Cloud Service. Legacy XFA and LiveCycle forms need their own plan, such as rendering as HTML5 or converting to Adaptive Forms.