Sur cette page
Vous consultez actuellement l'aide de la version:
AEM is often used in high impact deployments that might serve millions of users. In most cases, there are custom applications that are deployed on the instances which adds to the complexity. Any effort to upgrade such a deployment needs to be handled methodically.
This guide helps in establishing clear goals, phases and deliverables when planning your upgrade. It focuses on the overall project execution and guidelines, it has enough details of the actual upgrade steps, but it refers to available technical resources where suitable. It should be used in conjunction with the available technical resources referred to in the document.
The AEM Upgrade process needs carefully handled planning, analysis and execution phases with key deliverables defined for each phase.
This guide focuses on upgrading from 5.6.x to 6.2, and also covers the migration to the Oak based repository. However, note that it is possible to upgrade directly from AEM versions 5.4 and up to 6.2. Customers running 5.3 and below need to upgrade first to version 5.4 or above.
This guide assumes the following source and target topologies:
This is the list of key changes in AEM between 5.6.1. to 6.2 to be considered while planning an upgrade:
- AEM 6.0 introduced the new Jackrabbit Oak repository. Persistence Managers have been replaced by Micro Kernels. Starting from version 6.1, CRX2 is no longer supported. A migration tool called crx2oak needs to be run to migrate the repository from 5.6.1 instances. For more information, see Using the CRX2OAK Migration Tool.
- Periodic garbage collection of revisions and data store garbage collection are now routine maintenance tasks that need to be performed periodically. See Maintaining the Repository for information on how to configure these tasks.
- Indexes are not created automatically. Custom indexes need to be created manually for the queries that you are using.
- Shared data stores between authors and publishers are fully supported.
For more details about what changed in 6.2, see the complete release notes here.
| Component | Impact | Description |
| Operating System | Uncertain, but subtle effects |
At the time of the AEM upgrade, it may be time to upgrade the operating system as well and this might have some impact. |
| Java Runtime | Moderate Impact |
AEM 6.2 requires JRE 1.7.x (64bit) or later. |
| Content Repository (CRX or Oak) | High Impact |
AEM 6.2 does not support CRX2, so a migration to Oak (CRX3) is required. The crx2oak tool is used for this purpose. |
| AEM Components/Content | Moderate Impact |
/libs and /apps easily handled through the upgrade, but more work is needed for /etc. |
| AEM Services | Low Impact |
Most AEM core services are tested for upgrade. This is an aera of low impact. |
| Custom Application Services |
Low to High Impact |
Depending on the application and customization, there may be be dependencies on JVM, operating system versions and some indexing related changes, as indexes are not generated automatically in Oak. |
| Custom Application Content |
Low to High Impact |
Content that will not be handled through the upgrade can be backed up before the upgrade takes place and then moved back into the repository. Most content can be handled through the migration tool. |
Remarque :
The upgrade will require downtime for the Author tier and Publish tier as most AEM upgrades are performed as in place upgrades.
- If you are using version 5.4 or newer, you can upgrade to AEM 6.2 directly. If you are using version 5.3 you need to upgrade to AEM 6.0 first, and then to 6.2
- The exact production environment needs to be duplicated and testing should be performed on it after upgrade to make sure all applications and custom code still run as desired. You need to regress all your customization and execute performance, load and security testing.
- Check the Adobe Support coverage for your AEM version
- Explore the opportunity to leverage new features
- Review the list of deprecated and removed features in the Release Notes
- Review the difference in the JCR API with previous versions
- The upgrade project should include implementation, regression, full testing, downtime, go-live and production operations plans
- Based on observations made in testing there could be ways to optimize the custom code. This might include refactoring the code to traverse the repository, custom indexing, use of unordered nodes in JCR and other optimizations
- Evaluate how long the content migration will take for moving from CRX2 to Oak
- Account for additional space requirements for TarMK based on your upgrade testing.
For more information, see the AEM 6.2 Technical Requirements page.
A comprehensive test plan should be prepared for testing upgrades and should cover the following:
- Testing the AEM implementation and all associated custom code
- Integrations with other Marketing Cloud solutions
- Integration with third party systems
- Performance testing including page load times
- A few key items to cover in the test plan in addition to core functionality testing of the AEM application and customization
- Testing of custom indexes and custom queries
- Search performance for custom queries
- Creating content and authoring
- Touch UI features
- Instance monitoring setup
- Maintenance activities
- Backup process
- Disaster Recovery plan.
| Phase | Key Activities |
Assessment and Planning |
|
Upgrade Preparation |
|
Upgrade Execution |
|
Post Upgrade Activities |
|
| Phase Prerequisite | Review Upgrade Scope and Requirements |
| Phase Deliverable | Impact Assessment Report, Upgrade Schedule, Upgrade Test Plans, AEM 6.2 Development Plan |
- In the assessment and planning stage, the impact and scope of the upgrade is defined and teams are identified for upgrade tasks. Please note that for accurate assessment of the impact and effort to upgrade the custom code, craft new custom indices and other tasks, its best to clone and upgrade a development environment and perform testing beforehand.
- Development effort for moving the AEM implementation is assessed and key areas of developer effort are identified.
- Test plan documents are prepared for testing the upgrade in a staging environment, before upgrading the production environment.
ID |
Task Description |
Assessment |
|
1 |
Review the business and technical requirements associated with the AEM upgrade |
2 |
Review roadmap for projects planned to be on-boarded onto the AEM platform |
3 |
Review of current and go-forward architecture, hardware, infrastructure and server environment |
4 |
Assess downtime tolerance to select appropriate upgrade options |
5 |
Review of standards for taxonomy, tagging, templates, components, pages and content |
6 |
Analyze the current AEM workflow models and custom processes |
7 |
Assess the impact of upgrade on the content structure |
8 |
Validate forward compatibility of templates, components, services and add-ons with new AEM version |
8b |
Perform repository clone analysis to see what parts of repository can be migrated smoothly with the migration tool |
8c |
Its also highly recommended to do a quick upgrade of a developer environment and basic smoke testing to get a better understanding of the level of effort required to get code and indexes up to speed |
9 |
Present recommendations on upgrade strategy, execution plan, potential areas of risk and gaps and mitigation plan to close those gaps. |
9b |
|
10 |
Define success criteria for the upgrade including keeping to the planned upgrade timeline |
Planning |
|
11 |
Customer IT and business leaders schedule dates for the following milestones of the upgrade:
|
12 |
Define the rollback strategy in case upgrade success criteria are not met |
13 |
Prepare Development and Test Plans including the verification of rollback strategy |
14 |
Create project specific upgrade run book based on detailed upgrade steps and output of upgrade assessment and planning steps |
Phase Prerequisite |
Test Plans, 6.2 Development Plans |
Phase Deliverable |
Application code ready for 6.2, QA/Development/Staging Upgrade Certification |
The upgrade project preparation is mostly about upgrading the Development, QA and Staging environments and executing the test plans on these instance. Please refer to the Upgrade instructions documentation for more details on how to perform upgrades.
ID |
Task Name |
Development Environment Upgrade |
|
1. |
Setup 5.6.1 environment with Production code |
2. |
Follow Upgrade Steps to upgrade the instances in the environment. |
3. |
Follow the Development Plan to make code and infrastructure 6.2 ready to the environment. This may take a few weeks to months based on the impact on the AEM implementation. |
4. |
Perform User Acceptance testing on the AEM implementation after the development phase, and file and fix any bugs encountered. |
5. |
Commit the development changes for the 6.2 environment implementation to source control. If there is active development work on the current version, use a separate source control branch as suitable. |
Milestone: 6.2 Development Complete |
|
QA Certification |
|
6. |
Clone the QA environment with the latest content from production |
7. |
Upgrade the QA Environment to the latest code on 6.2 |
8. |
Time the duration of all major upgrade steps as well as overall duration |
9. |
Go ahead with testing and the fix cycle based on the test plan, including the rollback strategy. Report any relevant issues to Adobe. |
10. |
QA Cycle - Certify Environment |
11. |
Dev/Adobe QA Support |
Milestone: Dev Environment QA Certified |
|
Stage Environment Upgrade |
|
12. |
Clone the staging environment with the latest content from production |
13. |
Upgrade Staging Environment to the latest code on 6.2 |
14. |
Time the duration of all major upgrade steps as well as overall duration |
15. |
Perform testing and start the fix cycle for integration, performance and load testing, including the rollback strategy. |
16. |
Commit fixes or changes to source control for the 6.2 environment |
17. |
Get certification from QA |
18. |
Dev/Adobe QA Support |
19. |
Define estimated upgrade duration and timeline based on QA and staging upgrades. Update run book with the timeline and lessons learned. |
Milestone: Stage Environment Certified |
|
Phase Prerequisite |
Staging Upgrade Certification with full performance and load testing |
Phase Deliverable |
Production Environment on 6.2 |
The upgrade project execution refers to the upgrade and go live of the production environment. The prerequisite to this phase is that the staging environment (which should be an exact copy of the production environment), went through the same upgrade, all the tests were performed and any bugs reported are fixed.
ID |
Task Name |
Production Environment Upgrade |
|
1. |
Production Cutover / Detailed Planning with date and time identified based on the planned upgrade duration |
2. |
Stop authoring activities and start production upgrade setup using Upgrade Procedure, summarized here:
|
3. |
Conduct smoke testing |
4 |
Certify the Production instance |
Phase Prerequisite |
A clean and successful upgrade of the production environment |
Phase Deliverable |
Performance testing and Production validation, Scheduled Maintenance tasks. |
ID |
Task Name |
Duration |
Owner: Customer | AGS | Partner | Managed Services Role: Business | Developer | Operations |
Post Production Procedure |
|||
1 |
Post-Cutover: Production Validation |
|
|
2 |
Schedule regular maintenance for Revision clean up(compaction) and Data Store garbage collection. |
|
|
3 |
Conduct performance testing again like performed on the staging environment after the upgrade and see if the indexing strategy needs to be revisited. |
|
|
4 |
Decommission activities |
|
|
Let’s look at the topology in more detail: the content from the Author instance gets copied to the Publish instance through replication.
When performing an upgrade, the following sequence should be followed on the topology:
- Stop authoring new content
- Stop replication
- Take a backup of all instance repositories, as any customization to libs or core components might be overwritten during migration
- Upgrade the Author Instance to 6.2 including Oak migration then start it
- Upgrade the Publish Instance 1 to 6.2 including Oak migration then start it
- Upgrade Publish Instance 2 to 6.2 including Oak migration then start it
- Upgrade the Dispatcher modules on the web servers if needed
- Enable replication queues.
Remarque :
* Workflow purges are highly recommended unless there are regulatory concerns.
** Enable replication agents after all author and publish instances have been upgraded.
Les publications Twitter™ et Facebook ne sont pas couvertes par les dispositions Creative Commons.