Steps to plan and perform AEM upgrade – Part 2

Go to: Part 1 | Part 3 | Part 4 | Part 5

Step 4: Define the target topology

Based on the objectives for the upgrade and the current state assessment, define the target topology to migrate to the target version. 

This topology defines the deployment architecture of the target environment with all components included (author, publisher, dispatcher, integration systems and third party systems). 

Validate the infrastructure, OS and JRE requirements for the target version to migrate to and arrive at the hardware, OS and software update requirements for the target environment

Step 5: Agree on the migration and cutover downtime

It is extremely critical to agree with all stakeholders on the downtime that the upgrade would need. The approach taken for migration would be influenced by the downtime that can be taken up. 

Also check if authoring freeze can be brought in during the migration window so that new content is not getting created when migration is happening. 

Applications handling UGC content brings in additional complexity, which has to be factored in for migration

Step 6: Finalize the approach for upgrade

Based on the objectives, current state assessment and the target topology, finalize the approach for upgrade. 

Basically there are two approaches to choose from for migration

1. Direct instance upgrade or In-place upgrade where the current instance with all the contents in it is migrated to the target version
2. New installation in which a fresh install of the target version is done with content extracted from the current instance and migrated over to the target instance

Choose which approach to adopt for your upgrade. 

If the upgrade involves cleaning up of significant part of the content or change in deployment architecture (like moving from TarMK to MongoMK or vice versa), the new installation approach would be appropriate. 

On the other hand, if you need to retain all revision history, audit logs and when cleanup is required, direct instance upgrade would be appropriate.

Step 7: Prepare for the migration

With the approach for migration decided, now it’s time to build the pieces that are needed to do the migration. This would involve

1. Getting the infrastructure for the target state ready, with OS and JRE matching the requirements for the target state. Some spare capacity is required to setup the environments for testing the migration
2. Updating if required and making sure the application code builds and deploys to the new environment and preferably does not use any deprecated APIs
3. Keeping ready all the maintenance processes (cleanups, compaction…) and backup scripts, to be used before the migration
4. In case where content cleanup is required, device an approach to identify active content and eliminate stale content
5. Creating scripts and commands to extract and sync content to target environment
6. Make ready the scripts for creating the replication agents and dispatcher flush agents for the target environment
7. Validate the authentication configuration and authorization mechanism in the new version
8. Create the test plans to validate the migration. Test plan to cover all the functional and non-functional aspects of the application
9. Following points apply specifically for the fresh install
10. Check the customizations done directly on the AEM and move those to code and scripts where possible. Create document & checklists for performing custom configuration in the target environment for items that cannot be moved to code / scripts
11. Check the indexes in use in the current application and have the configuration ready to create them in the target environment
12. In case where users need to be migrated, create sync scripts to migrate users and their ACLs
13. Work out the details for performing the migration on different components (Author, publish and dispatcher)

By the end of this exercise, create a process document and checklists for executing the migration. 

Make it comprehensive and cover all aspects of migration including the pre-migration steps (running the maintenance procedures, taking backups), migration activities (executing the actual migration), post migration activities (validation, cut over steps, and covering changes in ops and dev ops processes post migration) and fall back procedures (rollback option).

This aids the execution process greatly and ensures none of the steps gets missed out. Also these documents help bring clarity to all stakeholders during execution.

With the preparation compete, we can jump in to do a test migration on a lower environment as detailed in the next part. 

Go to: Part 1 | Part 3 | Part 4 | Part 5