Showing posts with label Upgrade to AEM 6.2. Show all posts
Showing posts with label Upgrade to AEM 6.2. Show all posts

Sunday 5 July 2020

Path changes while upgrading from AEM 6.3 to AEM 6.5

Before we start any AEM upgrades we should ensure that a detailed study is done on the release notes.
If the upgrades are planned to the next direct version (Say AEM 6.4 to AEM 6.5), We can just read the release notes of AEM 6.5 and proceed for the upgrade. But if the case is different (AEM 6.3 to AEM 6.5) ensure we are comparing the release notes for each versions.

For eg: Say we are upgrading from AEM 6.3 to AEM 6.5. We know there was an AEM 6.4 available. So while upgrade, first understand the release notes of AEM 6.4 and observe the changes between AEM 6.3 to AEM 6.4 and do the same comparison from AEM 6.4 to AEM 6.5. This process ensure that we are identifying every changes and accommodating all changes by taking precaution not to break anything during upgrades.

Approach
AEM 6.3 -> AEM 6.4(Release Notes) -> AEM 6.5 (Release Notes)

AEM 6.3 to AEM 6.5 Path Changes

Notes:  AEM content is being restructured out of /etc to other folders in the repository, along with guidelines on what content goes where, adhering to the following high-level rules:
•    AEM product code will always be placed in /libs, which must not be overwritten by custom code
•    Custom code should be placed in /apps, /content, and /conf


Old Path

New Path

/etc/workflow/models

/libs/settings/workflow/models

 

/conf/global/settings/workflow/models

 

/var/workflow/models

/etc/workflow/instances

/var/workflow/instances

/etc/workflow/launcher/config

/libs/settings/workflow/launcher/config

 

/conf/global/settings/workflow/launcher/config

/etc/workflow/scripts

/libs/workflow/scripts

 

/apps/workflow/scripts

/etc/designs/default

/libs/settings/wcm/designs/default

 

/apps/settings/wcm/designs/default

/etc/taskmanagement

/var/taskmanagement

/etc/tags

/content/cq:tags

/etc/notification/email/default/com.day.cq.replication

/libs/settings/notification-templates/com.day.cq.replication

 

/apps/settings/notification-templates/com.day.cq.replication

/etc/workflow/notification

/libs/settings/workflow/notification

 

/conf/global/settings/workflow/notification

/etc/workflow/packages

/var/workflow/packages

Monday 27 March 2017

Upgrading Previous versions of CQ/AEM to AEM 6.2

Notes on Upgrading to AEM 6.2

We worry a lot when we get a request from client to Upgrade AEM from older version to AEM 6.2. Let us see some important things to be taken care while doing this activity.
Basically we go with product upgrades for two reason. Firstly the support for old versions gets expired. secondly, there are lots of new features and security upgrades in newer versions. AEM upgrade activities should include implementation, regression, full testing, downtime, go-live and production operations etc.

Adobe recommends In place upgrade method for upgrading to AEM Latest versions. This is one of the most tested method whith in Adobe. There are many individual tasks that are performed during an in-place upgrade. Also AEM 6.2  requires JRE 1.7.x (64bit) or later.

Upgrade Steps in High Level

  • Analysis
  • Planning
  • Preparation
  • Execution
  • Post Upgrade Activities

AEM upgrade has two steps basically.
1)Upgrading the repository. (Using crx2oak tool)
2)Upgrading AEM to 6.2.
Note: For AEM 6.1 to 6.2 upgrade, we don't have to do step (1) since we already have OAK(CRX3).

Version dependencies:
AEM versions 5.4 to AEM 6.1 can be directly upgraded to 6.2.
AEM 5.3 and below versions needs to upgrade first to version 5.4 or above, then to AEM 6.2.
AEM 6.1 to 6.2 upgrade can be carried out by just upgrading AEM(Not repository), In all other versions we need to upgrade the repository.

Some precautions. 

If your code is well maintained, and components are granular, you are safe. Ensure the infrastructure team is fully understood the architectural changes. Another success factor is you testing the upgrade activities minimum 3 times in development machines, to ensure all integration, third party APIS work perfectly.




Upgrade Steps:

Preparing the source instance: Here we are ensuring our environment is ready for upgrade.

  •     Create a full backup - Take a backup of content and any custom codes
  •     Cleanup any content -  remove unwanted content, packages, workflows
  •     Consistency and Traversal Checks - Validate system checks using Adobe tools
  •     Run a test suite - Ensure you have a test suite with all  functionality checking
  •     Disable custom authentication mechanisms - Disable any hooks related to authentications.
  •     upgrade customization - Upgrade your customs codes to reflect new APIs, removing deprecated ones.
  •     Stop the instance 
  •     Archive then delete the log files - Delete all old log files.

 
Content Repository Migration : Migrate the repository to Apache Oak Using crx2oak tool.

AEM Upgrade: Start the AEM 6.2 quickstart jar with the appropriate run modes (author, publish)

Post Upgrade : 

  • Verify the upgrade.log and error.log for any issues.
  • Ensure the home page is loading fine.
  • Run the same test suite which you ran before upgrade and ensure things are normal.
Related Posts:


Current scenarios: At present teams are upgrading various cq/aem versions as below.
CQ 5.3 to AEM 6.2
CQ 5.4 to AEM 6.2
CQ 5.5 to AEM 6.2
CQ 5.6 to AEM 6.2
CQ 5.6.1 to AEM 6.2
AEM 6.0 to AEM 6.2
AEM 61. to AEM 6.2