What Nobody Tells You Before Migrating to AEM as a Cloud Service?
If your team is planning (or mid-way through) a migration from on-prem AEM or AMS to AEM as a Cloud Service, here's a rundown of the things that tend to blindside people beyond what's in Adobe's official migration docs.
1. The "no full read/write access to the repo" shift is bigger than it sounds
On-prem, you got used to poking around CRXDE Lite, hotfixing content in prod, or running ad-hoc Groovy scripts against the JCR. Cloud Service locks that down hard no CRXDE Lite in prod, no direct repo shell access. Everything has to go through code, content packages, or the Cloud Manager pipeline. Teams that relied on "just SSH in and fix it" workflows need to rebuild that muscle memory around proper CI/CD and content sync tooling months before cutover, not during it.
2. Cloud Manager's code quality gates will fail builds you didn't know were broken
Cloud Manager runs static analysis (Sonar-based rules) on every build, and it's stricter than most teams expect. Common failures:
- Deprecated APIs (
ResourceResolverFactory.getAdministrativeResourceResolver, old Sling APIs) - Synchronous calls to external services in request-processing code
- Hardcoded paths/config instead of OSGi configs
- Missing Sling Model
@Exporterbest practices
Run a Cloud Manager readiness scan early in the migration, not right before go-live the backlog of violations is usually bigger than anticipated.
3. Dispatcher config now lives in your Git repo, and it's validated at build time
The dispatcher config that used to be tweaked and reloaded independently is now part of your codebase, deployed through the pipeline, and validated with strict rules (no overly permissive filters, no wildcard allow rules, mandatory cache headers config). If your on-prem dispatcher rules were "grown organically" over years, budget real time to rewrite and re-test them — this is one of the most underestimated migration tasks.
4. Author and Publish are now fully separate environments with async replication realities
Content sync between Author and Publish is handled differently in the cloud (via the content pipeline and on-demand replication), and Publish instances autoscale/recycle. Any custom code that assumes a persistent Publish instance (in-memory caches that never expire, local file writes, session state) will break in unpredictable ways under autoscaling. Audit for statefulness assumptions before migration, not after users start reporting weird bugs.
5. Asset processing changes Dynamic Media and the Asset Compute Service
If you're using AEM Assets, on-prem custom workflows (image processing, PDF generation, thumbnail rendition) mostly need to be re-implemented as Asset Compute microservices, not carried over as-is. This is often a bigger lift than the component code migration itself, especially for teams with heavily customized DAM workflows.
6. Test your third-party integrations against the new network model
Outbound calls from AEM Cloud Service go through a different network topology (dev/stage/prod environments have separate egress IPs, and there's no static IP guarantee unless you configure it). If any downstream systems (PIM, CDP, payment gateways) IP-allowlist your AEM servers, get that sorted with your network/infra team early it's a common last-minute blocker before go-live.
Bottom line: the code migration is usually the least surprising part. The environment model, dispatcher-as-code, and stricter governance are what actually eat the timeline. If you're scoping a migration, add 20-30% buffer specifically for these operational shifts, not just the engineering work.
Anyone here gone through this migration recently? Curious what caught your team off guard that isn't in Adobe's official checklist.