AEM as a Cloud Service
Cloud, CMS, DevOps & Cloud Solutions, Digital Marketing

Migration to AEM as a Cloud Service


The migration of AEM Project from on-premise AEM version to another takes a considerable amount of time depending on what you need to accomplish. This migration involves various approaches and steps which most of us are generally familiar about. But as you know Adobe came up with latest offering of AEM in the form of AEM as a Cloud Service (AEMaaCS) and if migration need to be done from on-premise AEM version/AMS hosted AEM version to AEM as a Cloud Service (AEMaaCS) then there are many additional new things that you need to be aware of.


This article provides the insights around this type of migration to AEMaaCS and helps to avoid possible pitfalls related to the process. Let’s start with knowing some notable changes in AEMaaCS that you need to know before proceeding with migration.


Notable Changes in AEMaaCS

  • /apps and /libs are immutable at runtime this means you cannot do the changes in apps or libs code using CRXDE as these are now read-only and if you try to do so then will get error. If any change requires then that must be part of code and then deployed on cloud.
  • OSGi bundles and settings must be repository-based so you need to make any OSGi configurations to be part of code base via as a part of CI/CD pipeline build process.
  • Changes to publish repository are not allowed directly. Any content change need to publish via Author. Code and configuration changes must go via GIT and CI/CD pipeline build process.
  • Custom runmodes are not allowed and if you have some custom runmode in project then that must be revisit and make to abide with OOTB runmodes available on AEMaaCS. Below are supported runmodes in AEMaaCS-
  • Replication Agents has been removed in AEMaaCS and thus any replication in AEMaaCS should happen via Replication Service.
  • Classic UI support has been removed in AEMaaCS so any custom Classic UI code must be refactored to Touch UI. For this AEM Modernizer tool can be used to speed up the conversion.
  • Asset Handling and Delivery is different in AEMaaCS. Assets need to upload on Binary Storage Cloud from there author and publish services access those assets. DAM Assets Upload workflow is also not available in AEMaaCS, instead of this Assets Microservices are used to create rendition. If you have any custom workflow for rendition then you need to implement that again as per guidelines provided in AEMaaCS.
  • Publish-Side Delivery in AEMaaCS happens via default CDN (Fastly) provided by Adobe for AEMaaCS. If you already have set a CDN and want to also use that then you need to contact Adobe to integrate with Fastly CDN.


Migration Phases to AEMaaCS

For migrating the content/code to AEMaaCS there are three phases involved as described below-

  • Planning Phase

This phase involves various activities that you need to do as a first step before moving to the execution phase of migration. Some important activities are as follow-

    • Familiarize yourself with AEMaaCS features.
    • Go through the notable changes introduced in AEMaaCS as described above.
    • Make yourself aware of removed as well as deprecated features/api of AEMaaCS land their alternates.
    • Assessing cloud service readiness by comprehensive analysis of your existing codebase against the removed/deprecated features of AEMaaCS. For checking the readiness you can use the Cloud Readiness Analyzer (CRA) Tool.
    • Review the outcome of what level of code changes and estimates are requires to make it compatible with AEMaaCS. Once done, then proceed with resource planning by identifying the resources, create team having well defined roles and responsibilities.
    • Identify the Key Performance Indicators (KPIs) for AEMaaCS which is used to measure the performance of the site accessibility and assets handling. These KPIs also help team to focus on those areas which impact the performance.


  • Execution Phase

In this phase you need to perform activities like-

    • Transfer the on-premise AEM version contents to AEMaaCS. For this you can utilize the Adobe’s Content Transfer Tool.
    • Refactor the existing code to make it compatible with AEMaaCS. To speed up the code refactoring its recommended to use the various Adobe’s utilities like-
    • You can perform content transfer and code refactoring activities in any order but in order to render the content successfully on cloud you need to follow correct project structure. Below figure shows a standardized maven project structure that you can follow during code refactoring-


    • AEMaaCS recommends to have code quality test coverage to be atleast 50%. Please make sure to have atleast this level of code quality standard during refactoring otherwise build will failed in Cloud Manger build pipeline.
    • Once you are done with refactoring and customization works and ready for Go-Live, then there are few things as specified below that you need to follow for successful and smooth execution-
      • Freeze further code and content refactoring until go-live.
      • Ensure all required content transferred to AEMaaCS by using Content Transfer Tool.
      • Validate the functioning of site running on updated and re-factored project.
      • Ensure that you have done with performance and security testing.
      • Finally do the Cut-Over


  • Post Go-Live Phase

Once the go-live happened then there are few things that we need to take care of post go-live to ensure that everything is working as expected. Below are some important points that you should be aware of-

    • If there occurred some issue post go-live and you want to debug the issue by using thread dump, then you need to contact Adobe Support by specifying the time window for which thread dump require. This Adobe Support is require because as of now on AEMaaCS although thread dump is collected on going basic but there is no way available to get the dump by self-serve manner.
    • You can also download the logs by going to Cloud Manager interface and then access the particular author/publish service under the Environment Card available on Cloud Manager’s Program.
    • You can also use Adobe IO CLI to access the logs via api. For example-
      • To download the log use command    aio cloudmanager:download-logs ENVIRONMENTID SERVICE NAME [DAYS]
      • To tail the log use command   aio cloudmanager:tail-log ENVIRONMENTID SERVICE NAME

For more detail and other commands, refer page aio-cli-plugin-cloudmanager

    • You can access Developer Console on AEMaaCS to generate status information for Bundles, Components, Configurations, Oak Indexes, OSGi Services, and Sling Jobs. You can also see the result of resolution of JavaPackages and Servlets. To access Developer Console, you need to have Developer Role access on Cloud Manager. Developer Console is available on all the dev, stage, as well as prod environments.
    • Any code level debugging can be done in CRXDE on development environment only. On stage and production environments CRXDE is not accessible.


Migration Tools

Adobe provided various tools that helps to accelerate the migration activities. Below are the list of those tools-


  • Cloud Readiness Analyzer (CRA) Tool

    • This tool is used in Migration’s Planning Phase to analyze the readiness of existing code to be compatible with AEMaaCS.
    • This tool can be downloaded from Software Distribution Portal and then install in source AEM version Package Manager.
    • Once installed, it can be access via path Tools –> Operations –> Cloud Readiness Analyzer.
    • CSR tool execution is recommended to be done by admin user or by user who are part of administrators group.
    • This tool internally usage Pattern Detector Tool to analyze and generate the report. Generated report can also be downloaded in CSV.
    • CRA is supported on AEM instances with version 6.1 and above.
    • It’s recommended to execute the CSR tool on stage’s author environment.
    • Using the CSR tool you can get the various useful detail like-
      • Application functionality that must be refactored.
      • Repository items that must be moved to a supported location.
      • Legacy user interface dialogs and components that must be modernized.
      • Deployment and configuration issues.
      • AEM 6.x features that have been replaced by new functionality or that are currently not supported on AEM as a Cloud Service.


  • Content Transfer Tool

    • This tool is used in Migration’s Execution Phase to move the content from source AEM version to AEMaaCS.
    • This tool can be downloaded from Software Distribution Portal and then install in source AEM version Package Manager.
    • Once installed, it can be access via path Tools –> Operations –> Content Transfer.
    • To use this tool, you will need to be an admin user on your source instance and belong to the AEM administrators group in the AEMaaCS instance you are transferring content to.
    • This tool supports differential content top-up where it is possible to transfer only changes made since the previous content transfer activity.
    • It’s recommended to run the Revision Cleanup and Data Store Consistency Check activities before running the Content Transfer Tool. This way you will have less junk data and thus transfer would be fast.
    • Before going live on Cloud Service, you need to do frequent differential content top-ups to shorten the content freeze period for the final differential content transfer to avoid delay.
    • The minimum system requirement for Content Transfer Tool is AEM 6.3 + and JAVA 8. If you are on a lower AEM version, you will need to upgrade your content repository to AEM 6.5 to use this tool.
    • This tool can be used with File Data Store, S3 Data Store and Shared S3 Data Store. It currently does not support Azure Blob Store Data Store.


  • AEM Dispatcher Converter

    • This tool can be downloaded from Software Distribution Portal.
    • As in AEMaaCS configuration must be part of GIT repository, so this tool helps you to convert your existing non-cloud based AEM’s dispatcher configuration to be compatible with AEMaaCS.
    • This tool works on the assumption that the provided dispatcher configuration folder’s structure as described below.


  • AEM Modernizer Tool

    • This tool helps to convert legacy current AEM features to the current supported capabilities.
    • You can download the latest version of this tool from aem-modernize-tools.
    • With the help of this tool you can easily do the conversion of-
      • Static templates to editable templates
      • Design configurations to policies
      • Foundation Components to Core Components
      • Classic UI to Touch-Enabled UI


  • Asset Workflow Migration

    • This tool is used to automatically migrate Asset Processing Workflows from on-premise or AMS deployments of AEM to Processing Profiles and OSGi Configurations for use in AEM Assets as a Cloud Service.
    • To know more about how to install and build the code from Asset Workflow Migration, please refer page aem-cloud-migration.


Comparing AEMaaCS Capabilities against AEM 6.5

One of the key questions that comes to everyone’s mind is with changes in Architecture & deployment model in AEMaaCS, will it able to support all the features that comes handy with AEM 6.5 version? Here is the quick comparison matrix to answer those questions, AEMaaCS does not have feature parity with AEM on-premise version.




Although based on above details migration activities seems easy to proceed with by using the various tools but this does not conclude that these tools fully meet analysis or upgradation of code. For example, Cloud Readiness Analyzer helps to augment the manual analysis and provides the greatest chance of catching all upgrade issues. If you not use this, then also there is chance to miss some issues.

Also you need to think of what features are currently available (as shown above) and meet your requirement. For example, AEMaaCS doesn’t yet support AEM Screens, AEM Forms or Commerce. So, if you are using any of these features then it will be missed after migration. If AEMaaCS meetup your requirements then you are good to go with migration.

About The Author