Readiness Phase

Last update: 2023-11-17

In this phase of the AEM as a Cloud Service Migration Journey, you familiarize yourself with AEM as a Cloud Service. You can review the notable changes introduced and understand what it takes to plan for a successful migration to the cloud.

The Story So Far

The previous document, Getting Started with Moving to AEM as a Cloud Service, outlines a list of phases you must undergo so you can migrate to AEM as a Cloud Service. It also outlines the benefits of doing the migration.

Objective

This document helps you understand what factors you must consider so you can make sure that your AEM installation is ready to be moved to the cloud:

  • Learn about notable changes and deprecated features
  • Understand how to plan for the migration to AEM as a Cloud Service

Review the Notable Changes in the AEM as a Cloud Service Architecture

AEM as a Cloud Service brings many new features and possibilities for managing your AEM Projects.

Along with these improvements, several differences have been introduced between on-premise installations of AEM and Adobe Managed Services, compared to AEM as a Cloud Service.

The list of items in the below table is the subset of the changes most relevant for a migration to AEM as a Cloud Service. You can consult the full list of notable changes here.

What's Changed? Reference Key Takeaways
Separate Mutable and Immutable Filters into corresponding packages AEM as a Cloud Service Notable Changes
AEM Project Structure for AEM as a Cloud Service		 A single package that can be deployed into AEM as a Cloud Service can have sub packages, primarily to contain mutable and immutable content separated into their own packages.
Repo Init Apache Sling RepoInit Documentation Repoinit scripts are the best practice to create any initial node structures, users, groups, or service users. As these scripts can be targeted by run mode and manageable via code package deployment, they provide much flexibility to achieve repository initialization tasks.
Custom Run modes are not allowed Only run modes provided out of the box with AEM as a Cloud Service are supported.
When additional Development environments are added, all of them tie to the "dev" run mode.
Cloud Manager Pipeline Execution is the only way to deploy In AEM as a Cloud Service, access to /system/console is not permitted, hence all OSGi configurations must be part of code, and should be deployed as code.
The OSGi configurations are available in read-only mode for viewing through Developer Console through Cloud Manager
Replication Agents are replaced by Sling Content Distribution The concept of the replication agent is replaced by Sing Content Distribution. If there are customizations that use replication agents, they must be redesigned.
Reverse replication is not supported
CRX/DE and Package Manager CRX/DE is allowed only on the Development environment.
Package Manager is accessible on all author instances but the packages that are going to be deployed must contain only mutable content ( for example: /content or /conf)
Built in CDN and Get your own CDN AEM as a Cloud Service includes the CDN for all environments which is optimized for most use cases.
If you want to set up your own CDN, you must submit a request to Adobe Support for it to be approved.
If it is approved, the CDN points to Fastly and not to AEM instances in any environments.
Long Running Jobs Avoid long running Jobs such as Sling Schedulers or Cron jobs, as the AEM instances running in the containers can come and go at any point.
Rethink these functionalities so you can offload them to Adobe Developer.
Switch to Asynchronous Operations Configuring Asynchronous Operations To improve the overall performance of your environments, certain operations are run in async mode. The async jobs are queued and run when system resources are available.
Token-based authentication and integration strategies Generating Access Tokens for Server-side APIs
Token-based Authentication Tutorial		 It is common that systems external to AEM are trying to perform HTTP operations within AEM.
The recommended approach is to implement the strategies outlined here rather than relying on creating local usernames with passwords in AEM.
File IO / Disk Usage There is no guarantee of how much disk space is allocated, and the instances in containers come and go. Therefore, it is not advisable to use File I/O operations to write or read from the disk attached to the AEM instance.
DAM Update Asset Workflow Asset Compute Service The media processing steps that are part of DAM Update Asset workflow are now replaced by the Asset Compute Service
Asset upload methods and supported workflow process steps in AEM as a Cloud Service Upload API Comparisons and Supported WF Process Steps In AEM as a Cloud Service, either during upload or download of an asset the asset streams directly in or out of binary storage.
Not all workflow process steps are supported in AEMaaCS.
Workflow Launchers Remove any Workflow Launchers that are triggering either out-of-the-box or custom DAM Update Asset Workflow from your code.
All the assets uploaded into AEM as a Cloud Service are going to be processed by the Asset Processing Service. For custom steps, see Post Processing Workflows on how to setup and configure post-processing workflows.
Custom Rendition Steps Processing Profiles Any custom rendition generation, image conversions, or video encodings must be offloaded to the Asset Processing Service by creating corresponding processing profiles.
Content Search and Indexing Content Search and Indexing Changes There are considerable changes to the underlying processing of indexes and when it is kicking in.
Completely understand and refactor the Oak Indexes before managing them in the code that you deploy.
Not all maintenance tasks are configurable AEM as a Cloud Service Maintenance Tasks You can configure only certain maintenance tasks with AEM as a Cloud Service.
Changes to Publish repository Direct changes to the Publish repository are not allowed, except those changes under /home. It is always recommended that any changes made on author get distributed. All code and configuration changes must be deployed through the corresponding Cloud Manager pipeline.
Dispatcher Configurations and Caching Dispatcher in the Cloud
Cache Management
 The Dispatcher configurations must follow a specific structure.
The configurations must be managed as part of code and deployed through the Cloud Manager pipeline.
Back up and Restore AEM as a Cloud Service Backup and Restore
Changes to Authentication IMS Support for AEM as a Cloud Service If you were previously using SAML 2.0 integration on both author and publish before moving to Cloud Service, the main change is that AEM as a Cloud Service Author only integrates with Adobe IMS. However, AEM as a Cloud Service Publish tier can still use SAML or other authentication integrations. AEM as a Cloud Service offers IMS authentication support only for Author, Admin, and Dev users. The IMS authentication does not offer support for external end users of customer sites like site visitors.

Deprecated Features

Adobe constantly evaluates product capabilities, to over time reinvent or replace older features with more modern alternatives to improve overall customer value, always under careful consideration of backward compatibility.

Adobe recommends that you consult Deprecated Features to familiarize yourself with the features and capabilities that are marked as deprecated in Experience Manager as a Cloud Service. See what the impact is for your AEM deployment.

Plan for a Review of your AEM Installation

After you have accustomed yourself with the changes introduced with AEM as a Cloud Service, it is time to start planning for a review of your existing installation. Doing so helps you gauge the level of changes required to move it to the cloud.

The following figure showcases key steps involved during the review phase:

image

Next, you explore what each of these steps means in detail.

Assessing Cloud Service Readiness

The first step is to assess your readiness to move from your existing AEM version to Cloud Service and determine areas that require refactoring to be compatible with AEM as a Cloud Service.

Undertake a comprehensive assessment of your current AEM source code against the notable changes and deprecated features to determine the level of effort expected in the transition journey.

The number of findings can directly influence the timelines and overall project success. Therefore, Adobe recommends that you uncover as much as possible so you can plan the delivery. Or, initiate the conversations so you can redesign any customizations required to be in line with AEM as a Cloud Service best practice.

Best Practice Analyzer

You can accelerate the assessment by running the Best Practices Analyzer against your current AEM version. Having a good understanding of how it works is key to speeding up your assessment planning.

You can read up on how it works by consulting the Best Practices Analyzer documentation.

Create a Cloud Readiness Assessment Report

The next step is creating a report based on all the knowledge gained so far. You create the report by generating Best Practices Analyzer reports from the Stage and Production instances, then upload them into Cloud Acceleration Manager for a digestible report of actionable items.

A typical report should contain these inputs:

  • Documentation detailing the feature set of your particular AEM installation
  • Details on your AEM custom configurations and code
  • Production Dispatcher configurations
  • CDN Configurations (if there are any)

Socialize the Report

After the Best Practices Analyzer reports are complete, share them with the relevant teams so you can confirm your findings and plan for your next steps. Depending on preference, you can also distribute a printed version of the report by using Print Preview.

Reviewing Resource Planning

Once you have estimated the level of effort that is required to move to Cloud Service, you should identify resources, create a team, and map out roles and responsibilities for the transition process.

Establishing KPIs

If you have not established Key Performance Indicators (KPIs) previously, it is recommended to establish KPIs for your AEM implementation to help your team focus on what matters the most.

See Developing KPIs so you can learn how to choose the right KPIs for your business objectives.

What’s Next

Once you understand the scope of the changes required to move to AEM as a Cloud Service, it’s time to Make your code and content cloud ready before actually performing the migration.

Additional Resources

Previous page
Next page

On this page