Гледате помощното съдържание за версия:

AEM Project Overview

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 6.1 to 6.3, 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.3. Customers running 5.3 and below need to upgrade first to version 5.4 or above (6.2 recommended).

Please note that new oak segment tar format is used now for the segment node store, a repository migration to this new format is mandatory even for 6.0, 6.1 and 6.2.

This guide assumes the following source and target topologies:


What has changed since 6.1 ?

This is the list of key changes in AEM between 6.1 to 6.3 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.
  • The crx2oak tool has been updated to handle the new oak segment tar format for the segment node store.
  • The crx2oak tool command line usage options have been changed to be automation friendly and support more upgrade paths.
  • The pre-upgrade maintenance tasks have been optimized to support automation.
  • The new oak segment tar format is used now for the segment node store, a repository migration is mandatory.
  • The post-upgrade checks have also been made automation friendly.


For more details about what changed in 6.3, see the complete release notes here.

Upgrade Scope and Requirements

Below you will find a list of areas that are impacted in a typical AEM Upgrade project:

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.3 requires JRE 1.7.x (64bit) or later.

Content Repository (CRX or Oak)

High Impact

Starting from version 6.1, AEM does not support CRX2, so a migration to Oak (CRX3) is required if upgrading from an older version. 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.


The upgrade will require downtime for the Author tier and Publish tier as most AEM upgrades are performed as in place upgrades.

Upgrade Best Practices

  • If you are using version 5.4 or newer, you can upgrade to AEM 6.3 directly. If you are using version 5.3 or earlier you need to upgrade to AEM 6.x first(6.2 recommended), and then to 6.3
  • 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.

AEM 6.3 Technical Requirements

For more information, see the AEM 6.3 Technical Requirements page.

AEM 6.3 Testing Requirements

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.

AEM Upgrade Project Phases

An AEM Upgrade project can be divided into several major phases:

Phase Key Activities

Assessment and Planning

  • Identify the scope of the project required
  • Identify the customizations and impact
  • Prepare upgrade plan with the schedule and dates
  • Prepare the test plan for testing the AEM implementation, integrations with other Marketing Cloud solutions, third party systems and performance.

Upgrade Preparation

  •  Perform test upgrades on non production environments
  • Execute the upgrade test plan, including performance testing. Test custom applications and integrations.  

Upgrade Execution

  • Actual upgrade steps performed on AEM production instances and go live event

Post Upgrade Activities

  • Post upgrade smoke tests, monitoring and maintenance tasks.

Assesment and Planning

Phase Prerequisite

Review Upgrade Scope and Requirements

Phase Deliverable

Impact Assessment Report, Upgrade Schedule, Upgrade Test Plans, AEM 6.3 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.

Assesment and Planning Checklist


Task Description



Review the business and technical requirements associated with the AEM upgrade


Review roadmap for projects planned to be on-boarded onto the AEM platform


Review of current and go-forward architecture, hardware, infrastructure and server environment


Assess downtime tolerance to select appropriate upgrade options


Review of standards for taxonomy, tagging, templates, components, pages and content


Analyze the current AEM workflow models and custom processes


Assess the impact of upgrade on the content structure


Validate forward compatibility of templates, components, services and add-ons with new AEM version


Perform repository clone analysis to see what parts of repository can be migrated smoothly with the migration tool


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


Present recommendations on upgrade strategy, execution plan, potential areas of risk and gaps and mitigation plan to close those gaps.


  • Review the features released in 6.3
  • Determine communication and training requirements. Perform follow-up and update documentation based on review


Define success criteria for the upgrade including keeping to the planned upgrade timeline



Customer IT and business leaders schedule dates for the following milestones of the upgrade:
  • Readiness of the development and test plans
  • Upgrade of the Development Environment
  • Completion of the AEM 6.3 code changes
  • QA test and fix cycle
  • QA certification
  • Upgrade of the staging environment
  • Integration, Performance and Load Testing
  • Staging environment certification


Define the rollback strategy in case upgrade success criteria are not met


Prepare Development and Test Plans including the verification of rollback strategy


Create project specific upgrade run book based on detailed upgrade steps and output of upgrade assessment and planning steps

Upgrade Project Preparation

Phase Prerequisite

Test Plans, 6.3 Development Plans

Phase Deliverable

Application code ready for 6.3, 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.


Task Name

Development Environment Upgrade


Setup 6.1 environment with Production code


Follow Upgrade Steps to upgrade the instances in the environment.


Follow the Development Plan to make code and infrastructure 6.3 ready to the environment. This may take a few weeks to months based on the impact on the AEM implementation.


Perform User Acceptance testing on the AEM implementation after the development phase, and file and fix any bugs encountered.


Commit the development changes for the 6.3 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.3 Development Complete

QA Certification


Clone the QA environment with the latest content from production


Upgrade the QA Environment to the latest code on 6.3


Time the duration of all major upgrade steps as well as overall duration


Go ahead with testing and the fix cycle based on the test plan, including the rollback strategy. Report any relevant issues to Adobe.


QA Cycle - Certify Environment


Dev/Adobe QA Support

Milestone: Dev Environment QA Certified

Stage Environment Upgrade


Clone the staging environment with the latest content from production


Upgrade Staging Environment to the latest code on 6.3


Time the duration of all major upgrade steps as well as overall duration


Perform testing and start the fix cycle for integration, performance and load testing, including the rollback strategy.


Commit fixes or changes to source control for the 6.3 environment


Get certification from QA


Dev/Adobe QA Support


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

Upgrade Project Execution

Phase Prerequisite

Staging Upgrade Certification with full performance and load testing

Phase Deliverable

Production Environment on 6.3

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.


Task Name

Production Environment Upgrade


Production Cutover / Detailed Planning with date and time identified based on the planned upgrade duration


Stop authoring activities and start production upgrade setup using Upgrade Procedure, summarized here:
  • Clone or create images of the running instance (author or publish). These can be used later for backups.
  • Disable replication queues and Custom Login Modules
  • Run maintenance tasks
  • Run automated migration of the content on the target author and publish instances
  • Run the actual upgrade steps including re-enabling the replication queues, Custom Login Modules and installation of the recommended hotfixes


Conduct smoke testing


Certify the Production instance

Post Upgrade Activities

Phase Prerequisite

A clean and successful upgrade of the production environment

Phase Deliverable

Performance testing and Production validation, Scheduled Maintenance tasks.


Task Name


Owner: Customer | AGS | Partner | Managed Services

Role: Business | Developer | Operations

Post Production Procedure


Post-Cutover: Production Validation




Schedule regular maintenance for Revision clean up(compaction) and Data Store garbage collection.




Conduct performance testing again like performed on the staging environment after the upgrade and see if the indexing strategy needs to be revisited.




Decommission activities



Upgrade Procedure

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:

  1. Stop authoring new content
  2. Stop replication
  3. Take a backup of all instance repositories, as any customization to libs or core components might be overwritten during migration
  4. Upgrade the Author Instance to 6.3 including Oak migration then start it
  5. Upgrade the Publish Instance 1 to 6.3 including Oak migration then start it
  6. Upgrade Publish Instance 2 to 6.3 including Oak migration then start it
  7. Upgrade the Dispatcher modules on the web servers if needed
  8. Enable replication queues.

Upgrade Procedure Summary

The upgrade procedure can be summarized as follows:



* Workflow purges are highly recommended unless there are regulatory concerns.

** Enable replication agents after all author and publish instances have been upgraded.