Implementation Phase implementation-phase

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.

The Story So Far story-so-far

In the previous parts of the journey, you have gone through getting familiar with the changes in AEM as a Cloud Service, and determined 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.

Objective objective

This document aims to:

Using Cloud Manager using-cloud-manager

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:

Use the Adobe Provided Tools to Make Your Content and Code Cloud Ready use-tools-to-make-code-and-content-cloud-ready

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 must use so you can achieve this in the chapters below.

Content Migration content-migration

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 Adobe recommends that you use it, see the Content Transfer Tool documentation.

Code Refactoring code-refactor

Set Up for Development set-up-for-development

It is time to start refactoring the existing features to be compatible with Cloud Services.

First, look at the documentation detailing the basic tooling, and start refactoring your code:

Also, you can also:

A Change in Mindset a-change-in-mindset

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:

You can learn more by consulting the Recommended Package Structure documentation.

Cloud Migration Tools cloud-migration-tools

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.

Schedule a Code Freeze schedule-a-code-freeze

To manage your on-going code development on your active AEM along with the code refactoring tasks as part of your transition journey, Adobe recommends that 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.

Best Practices for Code Deployment and Testing best-practices

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 for Go-Live preparing-for-go-live

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.

Content Repository Health repository-health

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.

Gathering Data gathering-data

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:

These data points can also help you Establish KPI’s and other migration related tasks.

Migration plan migration-plan

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:

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

Migration Tracker migration-tracker

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:

Content migration strategy and timeline content-strategyand-timeline

The following section shows the important steps and associated tasks that can be used to formulate a content migration strategy and timeline.

Fitment fitment

Proof of migration proof-of-migration

What’s Next what-is-next

After you have 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.