Top 10 considerations while upgrading your Adobe Experience Manager (AEM) implementation

Upgrading to the latest version of Adobe Experience Manager (AEM) is not a straightforward and simple task. AEM is often used in large enterprise implementation having high impact deployments and significantly large users accessing and getting served by the implementation. Further, most AEM implementations have custom applications and/or customization within AEM which adds to the complexity of an upgrade.

In a standard upgrade process, following typical steps need to be done:

1. System Scan
2. Planning Upgrade
3. Pre-Upgrade Activity
4. Upgrade Execution
5. Post-Upgrade Activity
6. Upgrade Verification

Below diagram depicts this high-level upgrade process:

Upgrading requires some careful consideration before starting or even planning an upgrade of an existing AEM implementation.

Content Bloom has the experience when it comes to AEM upgrades, to make the process easier, we’ve compiled the following list to help explain the AEM upgrade process:

(Note: At the time of writing, the latest version of AEM is 6.3)

Process: Check if it would be a direct one step upgrade or it would be a two-step upgrade

• If the existing version of AEM is 5.4 or later, then upgrade to AEM 6.3 can be done directly
• If existing version of AEM is 5.3 or earlier, then upgrade to AEM 6.3 would be done in two phases:
  • Upgrade AEM 5.3 (or earlier) to AEM 6.2
  • Then upgrade the AEM 6.2 to AEM 6.3

Operating System: Analyze the pre-requisite of AEM and identify if there is a need to upgrade the existing Operating System.

Java Runtime: Analyze and identify if JRE need to be upgraded. For AEM 6.3, the minimum requirement is 1.7.x (64-bit)

Content Repository: Analyze if the existing implementation uses CRX2 repository.
If yes, then it will require a migration to Oak (CRX3) repository. A tool (crx2oak) can be used for this migration from CRX2 based repository to Oak repository.

Custom Application Services: This requires an end-to-end analysis of the custom implementation and accordingly need to plan specific upgrade steps

Custom Application Content: Most of the content can be migrated using migration tools, but still there may be custom application content, which cannot be handled through the upgrade. In this scenario, the content should be backed up and then moved manually to new updated repository.

Downtime: The upgrade will require downtime for the Author tier and Publish tier and this need to be planned and communicated well

Additional Space Consideration: If the upgrade need to be done from 5.6 or earlier version (TarPM based repository), then account for additional space requirement for new TarMK based repository as TarPM is not supported post AEM 6.1

Repository Consideration: Analyze and choose the right repository to upgrade to. AEM 6.3 support following repository options:

• TarMK – use it if high performance is mandatory
• MongoMK – use it if high scalability where you need to handle growing amount of data

Context Hub Configuration: After the successful upgrade, you’ll need to recover any Context Hub Configurations.