In this post, let us explore the architecture of AEM as a Cloud platform and the key considerations and approaches to migrate the existing AEM platform to AEM as a Cloud Service SaaS platform. Please note the details discussed below are more of my personal view and do not reflect the direct view of Adobe or my current organization; validate different perspectives with Adobe before onboarding to AEM as a Cloud Service.

Adobe Experience Manager (AEM) is now available as a Cloud Service. Refer to Introduction to Adobe Experience Manager as a Cloud Service | Adobe Experience Manager for more details on AEM as a Cloud Service values.

AEM as a Cloud Architecture:

The architecture of the AEM as a Cloud Service platform varies from current AEM platforms — either customer-owned on-premises or hosted solution or Adobe Managed Service platform.

Below is the high-level architecture of the AEM as a Cloud Service platform (I am not going to dive deep into how the platform is managed internally)

Most of the elements are now enabled as services, e.g.

CDN Service: Fastly CDN, CDN in AEM as a Cloud Service | Adobe Experience Manager comes to OOTB for AEM as a Cloud Services platform. Customers can bring their CDN, but Adobe recommends OOTB CDN. As the “AEM as a Cloud Services” is licensed based on the number of requests, the customer should enable the request report if they bring their own CDN. Refer to Adobe Experience Manager as a Cloud Service | Product Description for more details on AEM as a Cloud Services licensing model. The new License Dashboard | Adobe Experience Manager will help us to review the content request details.

Replication Service: The legacy replication has been replaced with Apache Sling: Content Distribution (org.apache.sling.distribution).

CI/CD Service: Cloud Manager-based CI/CD pipeline management, some enhancements to the Cloud Manager currently enabled for AMS.

Identity Management Service: Integration with Adobe IMS to manage the authors, Admins, and Dev users.

Content Repository Service: The Node and Datastore are enabled through Content Repository Service.

Assets Compute Service: — Asset Compute Service is a scalable and extensible service of Adobe Experience Cloud to process digital assets. It can transform images, videos, documents, and other file formats into renditions, including thumbnails, extracted text and metadata, and archives. The asset processing is externalized through asset microservices.

Author Tier: The author Tier comprises a single author cluster with two or more nodes (the default program enables 2 Authors). It scales automatically depending on the authoring activity. The author servers are managed as containers; existing servers are Downsized, or new servers are added based on the authoring demand.

Publish Tier: Publish Tier consists of 2 or more nodes with a single publish farm (the default program enables two publishers); they can operate independently. It scales automatically depending on the load. The publishers are enabled as a container’s existing servers are downsized, or new servers are added based on the load from end users.

Preview Server: Each AEM Cloud Service environment includes a Preview instance — a specialized Publish instance that content authors can publish before publishing to the Publish instances that serve the live site. It allows a preview of the website’s final experience before it reaches the Publish Tier & is available publicly.

RDE (Rapid Development Environments): RDEs allow developers to swiftly deploy and review changes, minimizing the time needed to test features that work in a local development environment. Once the changes have been tested in an RDE, they can be deployed to a regular Cloud Development environment through the Cloud Manager pipeline. Each program will be enabled with an RDE environment that developers can use to test features quickly, bypassing the Cloud Manager CI/CD pipeline process.

Backup and restore: AEM as a Cloud service enables customer-specific backup and restore capabilities additional to the Availablity Zone/region-wide backup and restore. Refer to Backup and Restore in AEM as a Cloud Service | Adobe Experience Manager for more details on backup and restore capabilities.

Thinks to consider while enabling the AEM as a Cloud Platform:

Default Program: Default program will have 1 Adobe-managed code repository (Git), 1 Stage + Production environment, 1 Development environment, 1 RDE environment, 1 Deployment & 1 Code Quality Pipeline for Each Environment. Ensure you are enabling the required additional environments to meet your needs (each program can have N number of Dev environments)— Each additional Dev environment costs an additional amount; there is no concept of QA or UAT environments; you may need to enable additional Dev environments and designate that based on your use cases.

Multi-Region: By default, the publish servers are enabled in a single region across multiple availability zones; you can enable muti-region to support the publish tier based on your need. Multi-region support must be enabled as an additional add-on, which costs an additional amount. Refer to Creating Programs and Environments — Cloud Manager API (adobe.com) for currently supported regions.

Concurrent Users: The Content Authors are licensed based on the concurrent users accessing the AEM author, by default, two different options based on your license model — up to 20 Concurrent Users with AEM Sites licensed up to 5 million Content Requests or up to 40 Concurrent Users with AEM Sites licensed for 5 million or more Content Requests. Additional Concurrent Authors are- licensed in a bundle of 20 users that cost an additional amount. Ensure that the required concurrent authors are enabled to support your requirements.

Storage — Content Repository Service: The Authors, publishers, Dispatchers, and Preview servers across an environment use the same binary storage- in an on-prem or AMS platform, every server will have a dedicated binary storage, but in AEM as a Cloud, the binary storage is shared across all the servers. There is no coping of binaries between Authors and publishers; the binary less replication is used. So, while enabling the AEM as a Cloud, you need to understand the storage requirements; by default, Stage and Prod environments enabled with 1 TB of storage and Dev environments with 200 GB, the additional storage can be enabled at the extra cost is for every 1 TB of storage. Your storage requirement based on the current platform might be (~ Size of Current Author+ ~ Size of one of the Current Dispatchers).

Each Publisher is enabled with its segment store; the author cluster uses Mongo DB storage.

The Segment Storage and MongoDB storage are enabled as part of the base AEM as a Cloud program.

Security/Compliance: Cloud Service provides edge filtering to block disruptive Layer 3 and 4 attacks and protects against Layer 7 threats. The WAF product is not enabled currently but will be enabled shortly; you should enable WAF as an add based on your security needs; the WAF solution costs additional. Refer to aem-cloud-service-security-overview.pdf (adobe.com) for further details on AEM as a Cloud Service Security.

AEM as a Cloud enables a HIPAA-ready platform; the HIPAA-ready platform is enabled through an additional add-on, “Enhanced Security.” The Enhanced Security add-on costs extra, and you can enable the add-on based on your security needs.

Observability: Refer to Infrastructure and Service Monitoring in AEM as a Cloud Service | Adobe Experience Manager for more details on observability. Customers can use the New Relic Application Performance Monitoring suite that provides real-time performance data collected and charted for analysis and troubleshooting. By using the monitoring suite, customers can directly observe various metrics such as JVM performance metrics, transaction time for Java™, background external calls, and database calls (my current understanding is customers will not be able to bring their own New Relic License to replace the default one)

The logs can be forwarded to the customer’s own Splunk account. The logging data is equivalent to what is available through the Cloud Manager log downloads. Still, customers may find it convenient to use the query features available in the Splunk product. The network bandwidth associated with logs sent to Splunk is considered part of the customer’s Network I/O usage.

Migration Approach:

Identifying a migration approach that meets your business/technical needs is critical. Two major approaches can be followed — Lift & Shift, Reimplementation, and Relaunch. The lift and shift are more of migrating the current functionalities without changing the AEM as a Cloud platform. Still, at the same time, the code, configuration, and content must be adapted to meet the minimal AEM as a Cloud platform guidelines and quality requirements. In the Reimplementation and Relaunch approach, the functionalities are simplified and rebuilt from scratch by following the AEM as a Cloud platform best practice and relaunched on AEM as a Cloud platform. While the Lift and Shift approach may seem simple and easy, the effort required can vary depending on how closely your current platform aligns with the minimal guidelines of AEM as a Cloud platform — For example, migrating an existing platform hosted on an AMS and a latest AEM version might be less complicated compared to the current platform on different hosting option and old AEM version. The approach should be selected based on your business needs and internal dependencies.

Remediation/Cloud Ready:

Let us see some important issues that must be addressed and cloud-specific changes that must be adopted to migrate the code, config, content, and assets to AEM as a Cloud.

BPA Report: BPA can run on any environment but is preferred to run on a Stage environment. The report consists of findings within categories of issues that must be addressed before successfully deploying to AEM as a Cloud Service. First of run the best practice analyzer in your current Stage environment (ensure the Stage environment is close to your Prod environment in code/config/content) to capture all the possible cloud compatibility issues) and address the Critical and Major issues. The BPA report covers most compatibility issues that should be addressed for cloud migration. Some of the issues can be skipped based on your migration approach — for example, the Static template to Editable template migration can be ignored. Later, you can relaunch the pages directly through the existing Editable Template; still, Adobe provides AEM Modernization Tools | Adobe Experience Manager to convert static templates to Editable templates.

Cloud Manager Quality Requirements: Ensure Cloud Manager quality requirements such as security, reliability, Maintainability, and Code Coverage ratings are met — Refer to Code Quality Testing | Adobe Experience Manager for more details on Cloud Manager quality requirements. If you don't use Cloud Manager on the current platform, Adobe provides a sandbox Cloud environment as a pre-migration to test some of these cloud-specific functionalities.

Dispatcher/CDN: The current dispatcher configurations need to be migrated to meet the AEM as a Cloud Dispatcher guideline. The configuration might be close to AEM as a Cloud if you use the latest AMS 2.0 dispatcher configuration guidelines. Still, it may need more changes if you follow the legacy approach. Adobe provides AEM Dispatcher Converter Tool | Adobe Experience Manager to migrate the current dispatcher configuration to AEM as a Cloud and to test.

If you adopt AEM as a Cloud OOTB CDN(Fastly), you need to review your current CDN rules, which OOTB CDN supports. For example, the OOTB CDN won’t allow you to enable Reverse proxy configurations if you have those currently. Also, the caching should be handled through TTL; you should ensure all the URLs have the required TTL’s enabled.

Custom Run Modes: AEM as a Cloud won't allow custom run modes, e.g., uat, as supported by on-prem or AMS versions. Refer to Deploying to AEM as a Cloud Service | Adobe Experience Manager to understand more about AEM as a Cloud standard run modes. Suppose you plan to designate multiple Dev environments for different purposes, e.g., QA, UAT, and the configurations vary. In that case, the approach should use Cloud Manages specific environments variable combined with OSGI configuration to support environment-specific values. Refer to Support Custom Run Modes in AEM as a Cloud | Environment Specific Variables in AEM as a Cloud | by Albin Issac | Tech Learnings | Sep, 2023 | Medium to understand more about supporting custom run mode approach in AEM as a Cloud.

Change Deployment: AEM as a Cloud allows only the changes to be deployed through code deployment; you should manage all the configurations through code, e.g., i18n, service users, OSGI configurations, etc. Customers can access CRXDE lite on the author tiers of the development environments, not stage or production. The immutable repository (/libs, /apps) cannot be written to at runtime, so attempting to do so will result in errors. The Repository Browser can be launched from the Developer Console, providing a read-only view into the repository for all environments on the author, publish, and preview tiers. The Package Manager can be used in environments on AEM as a Cloud Service. Since Package Manager is a runtime concept, it is impossible to install the content or code into the immutable repository, so these content packages should only consist of mutable content (mainly /content or /conf).

CI/CD Pipeline and Code Repository: AEM as a Cloud service only supports the deployment through the Cloud Manager CI/CD pipelines, but you can establish your own CI/CD process around Cloud Manager and your tools; also, Adobe I/O can be used to extend some of the functionalities. AEM, as a Cloud Manager, expects the code to be managed through a single repository on an Adobe-provided git repository; you can have your own code repositories and branching strategy, but finally, all the code should merge to the same Cloud Manager git repository for deployment. I earlier posted some blogs on managing this — Sync External Git Repository to Cloud Manager Repository | by Albin Issac | Tech Learnings | Medium Git submodules — Merge the content of multiple branches across git repositories at build time. | by Albin Issac | Tech Learnings | Medium

Tools: Ensure external tools used currently are supported by AEM as a Cloud; for example, some of the features enabled by ACS Commons are not supported by AEM as a Cloud. If you use any packages from external tools, ensure those are cloud-compatible and embedded through the code repository; refer to Leveraging 3rd Party Packages in AEM as a Cloud | by Albin Issac | Tech Learnings | Sep, 2023 | Medium for more details on including an external package for AEM as a Cloud project.

Additional Considerations:

Classic UI — The Classic UI dialog support is removed, and the components dialog should be converted to Touch UI.
State on the system -The instance’s file system should not be used in AEM as a Cloud Service to store any state of the applications.
Background Tasks and Long Running Jobs —the instance it is running in can be brought down at any time; therefore, the code must be resilient and, most importantly, resumable.
Reverse Replication — Reverse replication from Publish to Author is not supported in AEM as a Cloud Service
Oak Index — Existing Custom Oak Index Definitions should be converted to AEM as Cloud Service-compatible Custom Oak Index Definitions. The Custom Index definitions should be placed into the code repository; The Index Converter can migrate the index definitions.
CIF — If the CIF connector is enabled currently, then the corresponding add-on should be enabled through Cloud Manager; no more package deployment for the CIF add-on.
Immutable — The /apps and /libs areas are immutable because they cannot be changed (create, update, delete) after AEM starts (at runtime). Any attempt to change an immutable area at runtime fails. For example, i18n dictionary translation, OSGI configurations, and Developer Mode in the AEM Site page editor are not supported at run time. However, the same can be performed in the local SDK, and the changes are deployed through code deployment.
DAM Update Asset Workflow — DAM Update Asset Workflow is no longer available as asset processing is now performed via external microservices. If you have any critical custom implementation currently on DAM Asset Workflow, the same should be implemented using asset microservices and processing profiles.
Development: The Developer should use Cloud SDK to develop and test the functionalities locally. Refer to AEM (Adobe Experience Manager) as a Cloud Service — Setting up Local Development Environment in Windows | by Albin Issac | Tech Learnings | Medium for more details on the setup. The local SDK version should be regularly updated to receive the latest product updates; refer to AEM as a Cloud Service SDK | Adobe Experience Manager for more details.

Testing:

Testing is one of the major milestones for AEM as a Cloud Migration; different types of testing should be factored in — Functional, Regression, Performance, Security, SEO, Accessibility and Redirects, etc. You should develop a strategy based on your landscape; if you host multiple sites through a common set of components, it may not make sense to test all the websites at the same level, but conducting selective testing for some categories may make sense.

Migration/Cutover:

You should develop a cutover plan/strategy to address code freeze, content freeze, Content/Asset Migration, delta content/asset migration,

Adobe enables Getting Started with Content Transfer Tool | Adobe Experience Manager to migrate the content from current AEM versions to AEM as a Cloud — the time to migrate the content varies based on your current repository size.

In most cases, you may not be able to enable the content freeze for a long time to support critical content updates; in those cases, you should define the delta content migration approach — the delta content can be managed through multiple approaches, e.g., Delta Content migration through Content Migration Tool, Parallel authoring, record and reapply the changes later, etc.

You should also define the go-live strategy; for example, if you have many sites, it makes sense to batch the sites based on some criteria, e.g., site traffic and criticality, to avoid huge impacts.

Also, you should consider the SSL certificates, Firewall, network changes, DNS changes, etc.

Another important topic is how you manage the current platform while the migration project is in progress — supporting critical changes in the current platform and migrating those changes to AEM as a Cloud.