AEM as a Cloud Service migration: what changes and what to plan for
AEM as a Cloud Service is not simply AEM 6.5 hosted in the cloud. It is a different architecture, a different deployment model, and a different operating paradigm. Organisations that approach migration as a lift-and-shift consistently encounter scope they did not anticipate.
What changes at the architecture level
AEMaaCS separates author and publish into independently scalable services. The repository is immutable at the infrastructure level: you cannot make runtime changes to the installation. Custom code must be OSGi-compliant in a stricter sense, and the APIs available have changed. Anything relying on deprecated APIs that still worked in AEM 6.5 will break.
The lack of write access to the repository at runtime eliminates a class of customisation that many AEM implementations rely on: runtime configuration stored in the repository, custom Sling models that wrote to the JCR outside content paths, and integrations using direct repository access. These need to be redesigned, not just migrated.
Dispatcher configuration is a migration in itself
AEMaaCS uses a cloud-managed Dispatcher with a configuration model different from on-premise Dispatcher. Configuration is managed through the Cloud Manager pipeline, not through direct file system access. Organisations with complex Dispatcher configurations should treat Dispatcher migration as a separate workstream with its own discovery and testing phases.
CI/CD is not optional
AEMaaCS requires deployment through Cloud Manager. There is no manual deployment path to production. If the organisation does not have a mature CI/CD pipeline for AEM code, building one is a prerequisite for the migration. Cloud Manager quality gates will fail deployments that do not meet defined quality thresholds.
Content migration requires a strategy
Content migration from on-premise AEM to AEMaaCS is not a simple export-import. The content strategy, what to migrate, what to archive, what to restructure before migration, requires business decisions that take time. A content audit before migration planning is not optional. It determines whether the migration succeeds or carries forward years of accumulated content debt.
