In this digital age, organizations of all shapes and sizes are investing a lot on improving their overall customer experience. Keeping that in mind, Adobe constantly enhances Adobe Experience Cloud suite to empower marketers with the necessary tools to create and deliver amazing experiences. The foundation of many of those experiences relies heavily on Adobe Experience Manager, and like most platforms, Adobe annually updates its solutions with new features or existing features are enhanced to meet the expectations of evolving digital world. Hence, it’s imperative for organizations to upgrade AEM and avail the latest powerful features in store to deliver amazing omnichannel experiences to customers.
Though upgrading AEM to the latest version has some support from the Adobe, but the upgrade process may be a little challenging and often requires some specialized experience and knowledge to deploy everything smoothly. Also, proper planning is mandatory for upgrading any of the previous AEM, which includes – author training, writing test cases for the upgrade procedure, understanding the new changes around architecture, estimating LOE using AEM provided pattern detector and then finally creating a project plan. Further, the AEM Upgrade needs analysis and execution phases with key deliverables defined for each phase.
Considering the above complexities and problems faced while AEM Upgrade, I have put together this AEM playbook in an attempt to educate you, so you can establish clear goals and phases to upgrade AEM with little or no hiccups. Let’s discuss each and every step in some detail:
1.
Upgrade Overview:
The Upgrade process associated with AEM is a multi-step that often takes a few months to complete. The image below provides an overview of the different processes associated with an upgrade project.
| Planning For Upgrade | Author Training Plan | Develop A Test Plan | Identification Of Architectural Changes Required | Use pattern Detector To Estimate LEO | Prepare A Runbook | Build A Test Plan |
|---|---|---|---|---|---|---|
| Development & QA Requirements | Prepare A Dedicated Code Branch | Assess Usage Of Resource Resolver | Prepare A List Of Queries And Indexes | Enlist Customizations Needed For Update | Overlays Should Be Updated | |
| Maintenance Required For Pre-Upgrade | Make Sure To Have Efficient Resources | Take Backup Of Earlier Resources | Automated Analyzation Of Pre-Upgrade Maintenance | Disable Custom Login | Rotate Logs | |
| Procedure For Upgrade | Cease Authoring | Author Tier Should Be Updated | Segregate A Publish Instance | Upgrade Both Major & Additional Instances | Finalize The Upgrade | |
| Post Upgrade Inspection | Log Files Should Be Examined | Bundles Needs To Be Checked | Reinstall Backup Configuration | Determine Maintenance Tasks | Trouble-shooting Of Issues |
2.
Upgrade Scope and Requirements:
Before initiation of the upgrade, it is important to ensure that you are running a supported operating system, Java runtime, httpd and Dispatcher version. Also, upgrading components need to be accounted for in the project plan before upgrading AEM. The table below describes a list of areas that are impacted in a typical AEM Upgrade project.
| Areas Impacted During AEM Upgrade: | |
|---|---|
| Area Impacted | Description |
| JAVA Version | Every AEM version supports a specific range of JRE versions. If clients JRE version is lower than what is expected by new AEM version, then it needs to be updated. |
| Hardware | Running Pre-upgrade maintenance tasks and regular Maintenace tasks (post upgrade) requires a certain amount of heap memory and disk space. If current hardware doesn’t meet these requirements, then it needs to be updated. |
| Content Repository Migration | If AEM is being upgraded from version < 6.x, then content repository migration is a must. Earlier versions (< 6.x) of AEM used to run on CRX2 repository. AEM 6.1 onwards, content repository has been changed to Oak. |
| Repository Restructuring | Repository structure started changing from AEM 6.4 and is being continued in AEM 6.5 as well. It affects custom content. Though these restructuring duplicates content from their old location in repository to new location, but it needs a serious attention and any custom code referring to old location, needs to be updated, to fetch the content from new location. |
| Maven (POM) Updates | POM files need to be updated as well. POM files must reflect UBER jar version matching with upgraded AEM version and other dependencies versions. |
| Custom Application Code | Custom application code needs to be updated so that it refers to latest AEM Core APIs. Any deprecated AEM APIs need to be replaced with their alternate suggestive APIs. |
| Customizations of OOTB features | If any OOTB feature has been customized by client in previous AEM version, it may not work completely with upgraded AEM version. |
3.
Plan For Author Training:
There are many potential changes required to be introduced to the UI and user workflows during the AEM upgrade. It’s highly recommended to review the functional changes that have been introduced and create a plan to train your author teams to leverage them effectively. Make sure to note any changes to UIs or product features that are commonly used in your organization and after looking through what has changed in upgraded AEM, develop a training plan for your authors.
4.
Create A Test Plan:
Every organization’s implementation of AEM is unique and customized to meet their specific business needs. So, it’s important to determine all the customization made to the system and included in a test plan. The test plan empowers the QA process, which is performed on the upgraded instance. The exact production environment needs to be duplicated and testing should be performed on it after the upgrade to make sure all applications and the custom code still run as desired.
5.
Determine Changes Required For Architecture And Infrastructure:
While upgrading, you may need to upgrade other components in your technical stack such as the operating system or JVM. Also, it’s possible that due to changes in the repository, additional hardware may be required (this is for migrating from pre 6.x instances). Further, changes may be required for operational practices including monitoring, maintenance, and backup and disaster recovery processes.
6.
Assessing Complexity Associated With The Upgrade:
There are two steps involved to assess the complexity of the AEM upgrade. The first is the newly introduced Pattern Detector which is available to be run on AEM 6.1, 6.2 and 6.3 instances. It is the easiest way to assess the overall complexity of an upgrade in the form of reported patterns. The pattern detector report includes patterns for identifying unavailable APIs that are in use by the custom codebase. This test gives a fairly accurate estimate of what to expect during an upgrade for most cases.
The second and more comprehensive step is to perform an upgrade on a test instance that also includes some basic smoke testing. Also, the list of Deprecated and Removed Features should not only be reviewed for the version that you are upgrading to, but also for any versions between the source and target versions.
7.
Prepare An Upgrade and Rollback Runbook:
Though, Adobe has documented the basic process associated with upgrading an AEM instance, but, each organization’s network layout, deployment architecture, and customizations require tailored and fine-tuned procedure. Hence, it’s highly recommended to view all the documentation to construct a project-specific runbook that outlines the specific upgrade and rollback procedures. All instructions should be reviewed and taken into consideration with your system architecture, customizations, and downtime tolerance to determine the appropriate switch-over and rollback procedures that will be executed during the upgrade.
8.
Develop A Project Plan:
Based on the steps described above, a project plan covering the expected timelines for test, development efforts, training, and actual upgrade execution can be built.
A comprehensive project plan includes:
- Finalization of development and test plans
- Upgrading development and QA environments
- Updating the custom code base for AEM 6.5
- A QA test and fix cycle
- Upgrading the staging environment
- Integration, performance, and load testing
- Environment certification
- Go live
9.
Perform Development And QA:
We all know that the development and the testing process go hand in hand. During the customizations, the changes made while upgrade can make an entire section of the product unusable. There is the potential of discovering some new problems even after the redressal of the root issues by developers and testing teams. So, it’s better to keep track of these newly discovered issues in the upgrade runbook to make adjustments to the upgrade process. After testing and fixing, the code base should be fully validated and ready for deployment to the stage environment.
10.
Final Testing:
A final round of testing is highly recommended after the codebase has been certified by the QA team. Also, validation of the runbook on the stage environment must be followed by user acceptance, performance, and security testing. Finding and correcting issues before going live can help to prevent costly production outages. Apart from these, it is also important to perform performance, load and security tests on the system to understand significant changes to the underlying platforms on the new version of AEM.
11.
Performing the Upgrade:
Once the green signal has been received from all the stakeholders, the execution of runbook procedures should begin. The below image depicts the various steps to be taken into consideration while performing the final upgrade.
12.
Post Upgrade Support:
Many clients do ignore the importance of post go-live support. It is very critical to have enough resources planned out for post upgrade support to ensure minimal/zero disruption to your live site(s). If you hired a vendor for this upgrade, make sure to budget for post upgrade warranty/support period. If you do it with internal resources, make sure to allocate enough resources to address any issues identified on production.
As I mentioned earlier, no two upgrades are the same and there will be unique challenges you may have to work thru specific to your scenario. Having an experienced partner like NextRow Digital to help you guide thru and execute may prove critical differentiation factor between a successful or not-so-smooth upgrade.
NextRow Digital is an Adobe Silver Business Solution Partner, specializing in marketing cloud and technology implementations. We are awarded “AEM Specialization” by Adobe, recognizing us a formidable partner in AEM and Adobe Marketing Cloud space. We have a number of deployments and upgrades under our belt, including some for fortune 100 companies. Contact NextRow Digital today @ +1-847-592-2920 or info@nextrow.com, if you need help or assistance with AEM implementations or upgrades or AEM managed services
Disclaimer:
Any views or opinions represented in this blog are personal and belong solely to the blog owner and do not represent those of people, institutions or organizations that the owner may or may not be associated with in professional or personal capacity, unless explicitly stated. All content provided on this blog is for informational purposes only. The owner of this blog makes no representations as to the accuracy or completeness of any information on this site or found by following any link on this site. The owner will not be liable for any errors or omissions in this information nor for the availability of this information. The owner will not be liable for any losses, injuries, or damages from the display or use of this information.
