Readiness Phase

In this phase of the AEM as a Cloud Service Migration Journey, you will familiarize yourself with AEM as a Cloud Service, review the notable changes that it has 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 need to undergo in order to migrate to AEM as a Cloud Service, as well as the benefits of doing so.

Objective

This document helps you understand what factors you must consider in order to 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 leveraging 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 wish 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 will point to Fastly and not to AEM instances in any environments.
Long Running Jobs Avoid executing long running Jobs such as Sling Schedulers or Cron jobs, as the AEM instances executing in the containers can come and go at any point of time.
Rethink these functionalities to offload them to Adobe I/O.
Switch to Asynchronous Operations Configuring Asynchronous Operations To improve the overall performance of your environments, certain operations are executed in async mode. The async jobs will be queued and executed 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 As there is no guarantee of how much disk space is allocated and the instances in containers come and go, 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 OOTB 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 please refer to 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 will 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 under /home. It is always recommended to make the changes on author and distribute them. 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.
Backup 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 prior to 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 leverage 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.

We recommend you consult the Deprecated Features to familiarize yourself with the features and capabilities that have been marked as deprecated in Experience Manager as a Cloud Service and see what the impact is for your AEM deployment.

Plan for a Review of your AEM Installation

Once 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, in order to gauge the level of changes required in order to move it to the cloud.

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

image

Next, we will 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 will require refactoring in order to be compatible with AEM as a Cloud Service.

You will need to 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 will directly influence the timelines and overall project success. Therefore, it is recommended to uncover as much as possible to plan the delivery or to initiate the conversations needed to 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 thus far. You can do this by generating Best Practices Analyzer reports from the Stage and Production instances, then uploading 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 in order to 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 to 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

On this page