In the implementation phase of the journey, you will explore the tools through which you can make your code and content ready to be moved over to AEM as a Cloud Service.
In the previous parts of the journey, you’ve went through getting familiar with the changes in AEM as a Cloud Service, as well as determining if your deployment is ready to be moved to the cloud with the readiness phase.
This article continues on with advice on how to use Adobe provided tools to make sure that your code and content are ready to be moved to the cloud.
This document aims to:
Before you start, you must familiarize yourself with Cloud Manager since it is the sole mechanism for deploying code to AEM as a Cloud Service.
Cloud Manager enables organizations to self-manage AEM in the Cloud. It includes a continuous integration and continuous delivery (CI/CD) framework that lets IT teams and implementation partners expedite the delivery of customizations or updates without compromising performance or security.
You can get familiar with using Cloud Manager by consulting the resources below:
Onboarding to Experience Manager as a Cloud Service to understand self-help resources about onboarding for Experience Manager as a Cloud Service.
Integrating Git with Adobe Cloud Manager to learn about using a Single Git repository to deploy code.
Adobe Experience as a Cloud Service Configuration to learn about Managing Products and User Access in Admin Console.
The exact steps of your transition to Cloud Service depend on the systems you have purchased and the software development life-cycle practices you follow.
The following figure shows the main steps involved in the phase that involves converting your code and content for use with AEM as a Cloud Service:
We will start detailing the tools you need to use in order to achieve this in the chapters below.
To migrate content from your current AEM instance to your Cloud Service instance, you can use Adobe’s Content Transfer Tool.
With this tool, you can specify the desired content subset that you want to transfer from your source AEM instance to your AEM Cloud Service instance.
Content Migration is a multi-step process that requires planning, tracking, and collaboration between different teams.
For a complete detail on how the tool works and how we recommend you use it, see the Content Transfer Tool documentation.
It is time to start refactoring the existing features to be compatible with Cloud Services.
In order to do this, you need to take a look at the documentation detailing the basic tooling you will need to start refactoring your code:
Additionally, you can also:
Watch this video to understand how to install the Dispatcher SDK locally:
Watch this video to understand how to configure Dispatcher SDK:
Developing and running code in AEM as a Cloud Service requires a change in the mindset. It should be noted that code must be resilient, especially as an instance might be stopped at any time. Code running in Cloud Service must be aware of the fact that it is always running in a cluster. This means that there is always more than one instance running.
Certain changes are required for AEM Maven projects to be cloud compatible. AEM as a Cloud Service requires a separation of content and code into distinct packages for deployment into AEM:
/libs are considered immutable areas of AEM as they cannot be changed after AEM starts (that is to say at runtime). This includes create, update or delete operations. Any attempt to change an immutable area at runtime will fail.
Everything else in the repository, (for example,
/tmp) are all mutable areas, meaning they can be changed at runtime.
You can learn more by consulting the Recommended Package Structure documentation.
Adobe provides several tools to help accelerate some of your code refactoring tasks. Understanding these tools and the problems they solve will reduce migration complexity and time.
Once you have set up the local development environment, get familiar with the AEM as a Cloud Service SDK by consulting the documentation.
To manage your on-going code development on your active AEM along with the code refactoring tasks as part of your transition journey, we recommended you schedule a code freeze period until you have completed restructuring your Maven project to be compatible with AEM as a Cloud Service.
Once the project restructuring is done, you can resume new code development based on this new structure. This reduces Cloud Manager pipeline failures during code deployment and testing.
The Content Transfer and Code Refactor tasks do not have to be done sequentially. These tasks can be done independent of each other. However, the correct project structure is required to ensure that the content successfully renders in your Cloud Service environment.
The Cloud Manager pipeline supports execution of tests that run against the stage environment.
Follow the best practices in the documents below regarding code quality testing:
Preparing the source system for migration involves system and AEM administrator level tasks. You can start by verifying that the content repository is in a well maintained state by checking the revision cleanup and the data store garbage collection task status. If you are running AEM version 6.3 (as the Content Transfer Tool is compatible from version 6.3 onwards), it is recommended to perform offline compaction, followed by Data Store Garbage collection.
Data consistency check is recommended across all AEM versions to ensure that the content repository in a good state to initiate migration activities.
System administrator level access is required to install and configure AZCopy
It is also recommended you review any unused Assets, Pages, AEM Projects, Users and Groups to save time on migration. See the Content Repository Health section.
Once access to a production clone is established proceed to check the health of the repository. As mentioned in the previous section, the goal is to clean and compact the repository on the source before starting the migration. This step will potentially save much time otherwise spend on troubleshooting issues once the migration starts.
|Action Item||Key Takeaways|
|Users, Groups and Permissions||You need to understand the volume of users, groups, and complexity around memberships. Look for opportunities to clean up any unused users, groups in the source before migration.|
|Incomplete Asset processing||Try to complete the processing of assets in the source system before starting the migration to avoid potential concerns in AEM as a Cloud Service post migration.|
|Content Health||It is recommended to query for bad content and purge it before you start the migration. For example, look for assets or pages that do not have original renditions or that are stuck in workflow processing. Also see Asset Health.|
The Content migration strategy and timeline section further details how to extrapolate the gathered data and create a migration plan.
Gathering data can help you plan the migration activities and associated tasks. The extraction and ingestion times are particularly useful because the data points can be associated with a specific size of the migration set. As such, these data points can be extrapolated to come up with a plan:
One more important datapoint is the amount of time it takes to complete the user mapping, if this is coupled with the content migration. You can take this data point into consideration for more realistic estimates, since it will be added to the overall extraction timeline and it may not be required to run it during top-ups.
These data points can also help you Establish KPI’s and other migration related tasks.
Based on the data points you gathered (see above), you can create a migration plan that can be integrated into a macro project plan. This step will enable all the key stakeholders to visualize and plan around the migration activities.
The following table illustrates a typical migration plan:
|Migration Iteration||Start Date||Estimated End Date||Dependencies||Estimated Duration (in days)||Additional Details / Action Items|
As you can see in the table above, it is helpful to follow a specific naming format to identify the migration iterations, for example: PRDCLONE for the source AEM environment , AUTHOR/PUBLISH for the AEM as a Cloud Service environment, CSSTAGE-AUTHOR for the AEM as a Cloud Service instance, and so on.
Some important details that influence your migration plan:
The Total Number of Extractions required
Total Number of Ingestions required
You can use the migration tracker to note down the times for both the initial and top up runs. These data points will help you formulate realistic content freeze requirements before the final top-up.
The tracker will also help you to:
The following table illustrates a functional migration tracker:
|Source (Environment / Instance / URL)||Destination (Environment / Instance / URL)||Migration Set Name, Type (Initial or Top up)||Migration Set Size (MB)||User Mapping (Yes / No)||Extraction Duration (Start, End, Time taken)||Ingestion Duration (Start, End, Time taken)||Issues / Resolutions / Details|
The following section shows the important steps and associated tasks that can be used to formulate a content migration strategy and timeline.
Once you’ve fully understood how to assess if your AEM installation is ready to be moved to the cloud, as we as learn how to use the tools needed to make it ready, it’s time to move on to the go-live phase.