Process Breakdown (AEM 6.5 Upgrade)
Tags: aem, adobe, upgrade
Published: 2020-08-26 22:25:11

A good process is a key part of the upgrade, being able to create a very good breakdown of general activities, being able to identify inner activities helped me build and determine the different steps that I needed to follow for each instance, for each environment.

This process is always a living document, my recommendation would be to draft an initial breakdown and keep removing/adding details as you move forward with the upgrade.

The general steps that I came up with are:

* Upgrade Planning
* Development & QA
* Pre-upgrade Maintenance
* Upgrade Procedure
* Post Upgrade Checks

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/5zr0ywturnjf7qbtjxwy.png)

## Upgrade Planning ##

For me, this section covers tasks that will allow me to understand the development effort for the upgrade.
I have listed within it current versions of everything. This allowed me to identify if versions of different platforms will work with 6.5 or if they also need to be updated.

* Run pattern detector.
* Create a test plan.
* Components inventory.
* Platforms version inventory.

### Run pattern detector ###

Download and install package pd-all-aem65-1.0.zip this package. After install go to `/system/console/status-pattern-detector` and analyze the results. This will allow you to assess the level of complexity of your upgrade.

You will get a list of components that might be violating certain rules, features that are not compatible with 6.5. For more information on this go [here] (https://docs.adobe.com/content/help/en/experience-manager-65/deploying/upgrading/pattern-detector.html).

### Create a test plan ###

This test plan will allow you to test core AEM functionalities after each environment upgrade and also will allow you to test site components that are critical or could be prone to fail after the upgrade.

For us, it was very useful to build three sets of test plans

1. Core AEM functionality tests (i.e. blueprints, rolloutconfigs, i18n, tags, contexthub, etc)
2. Test cases from a site visitor perspective.
3. Test cases from an authoring perspective.

### Components inventory ###

We generated a dictionary of components and the number of instances within the site. This helped me understand which are key components that we need to test carefully while doing the upgrade, mainly if any of those components are using third party integrations.

### Platforms version inventory ###

This is an important step within the **upgrade planning**. This allowed me to identify if there was any inconsistency between environments, and it helped me identify and assess if apache and dispatcher needed an upgrade or not.

The platforms/tools that I listed in the inventory are:

* Java
* AEM
* Dispatcher
* Apache

The above was listed for every environment, in my case Local, Dev, QA, UAT, Prod.

This step allowed me to identify that I needed to include a dispatcher upgrade in my process.

![Alt Text](https://dev-to-uploads.s3.amazonaws.com/i/b0h4lcezz9wvhvou7z10.png)

_[Next Post] (https://dev.to/caraujo/dev-qa-aem-6-5-upgrade-5d7n)_

_[Parent Post] (https://dev.to/caraujo/upgrading-aem-to-6-5-2i58)_