8 Tips for a Smooth Upgrade to Adobe Experience Manager (AEM) 6.5

Adobe Experience Manager’s (AEM) arrival of AEM 6.5 offers a ton of engaging features and advantages, numerous organizations are gauging the upsides of upgrading to deliver the right experience to their customers, in the right channel, and at the right time.

However, an upgrade isn’t something to take lightly, it might include a fairly significant undertaking, depending on your current applications and configuration. But if implemented in the right manner, upgrading to the AEM 6.5 will offer a multitude of benefits.

Post the AEM 6.5 release, many of the AEM users, have already decided about the upgrade plan but might be still worrying about how to start? In this blog, we have listed a number of best practices for ensuring a smooth upgrade.

1. List down the AEM Upgrade Scope and Requirements

AEM deployment has a high impact serving millions of users. It becomes more complex if custom applications are deployed on their instance. AEM upgrade process needs to be well planned to have a fool-proof and detail analysis. All the phases must have key defined deliverables.

So, let us first find out the upgrade scope and requirement in the discovery phase.

Below are a few key elements which need special focus and require analysis both in the post and the pre-upgrade phase:

• Operating System
• Java Runtime: JRE 11 is supported by AEM 6.5. JRE 1.8 is the only version currently supported by Oracle till AEM 6.4.
• Hardware
• Content Repository (CRX or Oak): As we know from AEM 6.1, CRX2 is not supported. So, this is a high impact activity. This must be analyzed carefully.
• AEM Component / Content
• AEM Services
• Custom Application Services
• Customer Application Content
• Dispatcher
• Advance Caching strategy

When upgrading, it is always possible that you also need to upgrade other components in your technical stack, such as OS or JVM.

2. Find out the AEM Upgrade Complexity with Pattern Detector

AEM 6.5 release is an upgrade release on top of the AEM 6.4 codebase. A big focus of the AEM 6.5 release is to keep all the new features backward compatible. If you start with Pattern Detector, you will be in a better position to decide the path you want to take to reach a compatible state.

Pattern Detector helps you to predict accurately by giving a warning for an upgrade. However, there are some scenarios or use cases, where it generates false positives.

Hence it is always recommended to analyze this report with due diligence. Currently, Pattern Detector has the following scope:

• OSGi bundles exports and imports mismatch
• Sling resource types and supertypes (with search-path content overlays) over usages
• Definition of Oak indices (Compatibility)
• VLT packages (overuse)
• rep: User nodes compatibility (in context of OAuth configuration)

3. Assessing the AEM Upgrade Complexity due to Deprecation

Suppose multiple customized applications are running on your AEM instance. In that case, it is always recommended to spend some time to determine the dependencies and the efforts which are expected in an upgrade.

As recommended by Adobe, you are first suggested to run the Pattern Detector to assess the complexity. This will also help in identifying unavailable APIs that are in use by the custom codebase.

In addition, you should also review “Deprecated and Removed Features” for the version you are upgrading. For Example, while upgrading from AEM 6.2 to 6.5, it is important to review the AEM 6.3 deprecated and removed features in addition to those of AEM 6.5. These steps ensure a smooth transition and deliver robust dxp digital experience or digital experience solutions.

4. Backward Compatibility in AEM 6.5

If you have AEM 6.3, you don’t need to change the code or do customization while doing the upgrade. In exceptional cases, where the features can’t be kept backward compatible, those that are incompatible for bundle and content, can be mitigated by installing a Compatible Package for AEM 6.4/6.3.

Compatible Package allows you to run AEM in a compatible mode and defer custom development against the new AEM features. Once the package is installed, routing can be enabled or disabled using a switch in the OSGI configuration.

Please note that the Compatible Package is only a temporary solution to defer development required for being AEM 6.5 compatible, and it’s recommended only as a last option.

5. Pre-Upgrade Maintenance Tasks

Before starting an upgrade, it is recommended to identify or list down certain maintenance activities. Below are a few important activities which must be taken care of:

• Full Backup of AEM
• Back up changes to /etc
• Generate the quickstart.properties file
• Configure workflow and Audit Log Purging
• Disable custom login modules
• Disable custom schedule jobs
• Rotate Log files
• Upgrade the Database Schema if needed
• Execute Offline Revision Cleanup
• Stop any Cold Standby Instances
• Remove Updates from the /install directory
• Execute Datastore Garbage Collection
• Install, configure, and Run the Pre-Upgrade Task

6. Create a Test Plan and strategy

A comprehensive testing strategy should be developed. A test plan should be prepared to test the upgrades. You should also identify the critical functional areas of AEM which should be covered by your test plan.

The upgrade should first start from a lower environment and accordingly testing should be done on the upgraded code base and application in the lower environment.

Any bug should be fixed in an iterative fashion until the code is stable, only then you should plan to perform the upgrade in a higher environment.

7. Rollback strategy

Most of the time, an AEM customer forgets about this activity. In case your upgrade does not meet the requirement, you should plan a rollback strategy so that there should not be a production impact.

Your rollout documents should include:

• Information about full backup of AEM and all its component, properties etc
• Technical Instruction
•  Communication instruction
• Contact Details of all stakeholders

8. Post AEM upgrade Checks

A post-upgrade checklist should be prepared to test the activities in order to finalize the upgrade. Your check-list must include the following important activities:

• Verify OSGi Bundle
• Verify Oak Version
• Inspect the PreUpgradeBackup folder
• Validation of all the pages
• Apply AEM services pack
• Enable Replication agents
• Enable Custom Scheduled Jobs
• Execute Test Plan

Before starting an upgrade, please make sure that your application codebase is stable and all the test cases will be executed as per the expected upgrade version.

Please note you can directly upgrade from AEM 6.0 to AEM 6.5, but if you are using AEM 5.6.x or any other lower version, you first need to upgrade to AEM 6.0 or to a higher version with SP3, only then you can plan for the AEM 6.5 upgrade.

We recommend you should first upgrade your author instance and based on the success or failure of the same, you should plan for the upgrade of publish instance.

Conclusion

AEM 6.5 release continues to enhance the reliability, stability, performance improvement, and supportability of the system via an upgrade or by adding various features to the existing system.
However, AEM upgrade process needs to be handled very carefully, with proper analysis and planning and should be implemented phase-wise.

The official Adobe documentation states that “Upgrading AEM is a multi-step, sometimes multi-month process.” To be honest, it has always been a multi-month process.

Thus, we recommend you to invest in the time to plan the best course of action, handle pre-upgrade tasks, and define the steps to implementation. This investment will definitely pay off well in terms of both time and costs, keeping away from pointless deferrals and issues down the line that can be averted proactively.