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.
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.
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.
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.
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.
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.
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 procedures. 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.
A comprehensive project plan includes:
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 to life 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 the post-upgrade warranty/support period. If you do it with internal resources, make sure to allocate enough resources to address any issues identified in 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 a critical differentiation factor between a successful or not-so-smooth upgrade.
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.
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.
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.
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.
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 procedures. 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.
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 codebase should be fully validated and ready for deployment to the stage environment.
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 codebase should be fully validated and ready for deployment to the stage environment.
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 to life 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 the post-upgrade warranty/support period. If you do it with internal resources, make sure to allocate enough resources to address any issues identified in 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 a critical differentiation factor between a successful or not-so-smooth upgrade.
No comments:
Post a Comment
If you have any doubts or questions, please let us know.