Steps to plan and perform AEM upgrade – Part 1

In this 5-part series, we will see the steps that are required to plan and perform an AEM version upgrade.

Step 1: Establish the objectives

The first step in the migration process is to clearly layout the objectives for the migration.

There could be many reasons why you might want to upgrade your AEM instance. Some of the common reasons to upgrade are

1. An AEM version in use go out of support and you want to be safe and remain on a supported version
2. You wanted to use the new features in a later release and hence need the upgrade
3. You wanted to leverage the enhancements and performance improvements in the later releases
4. You have a bloated CMS, accumulating a lot of junk content over the period and wanted to use the upgrade to cleanup and trim down your CMS
5. You may even be wanting to rewrite your application for a newer version and want to migrate the content over to the new version
6. Or it could just simply be for the reason that you are tech savvy and you don’t want to be on a stale environment or be left behind

The reasons for upgrade could be many. But the important thing to start the upgrade is to clearly establish your reasons for upgrading and their priority. 

These reasons typically form the primary objectives for migration and would significantly influence the decisions taken in the subsequent steps

Secondary objectives

You might be upgrading for one or more primary reasons, but you would also want to leverage it to achieve few other objectives. List down all the other objectives that you want to achieve along with the upgrade. 

Some examples of such objectives are

1. Migration the infrastructure to the cloud
2. Move the datastore to S3
3. Migrate to MongoMK from the current TarMK setup or vice versa
4. And so on…

By the end of this exercise, have a listing of all objectives to be achieved with the upgrade, classifying them into primary and secondary objectives. 

This would greatly help in making the right choices in the subsequent steps of the migration

Step 2: Finalize the target version to migrate to

This might seem trivial but it’s prudent to give some consideration before finalizing the target version to migrate to. 

The default choice is to migrate to the latest available version, but consider the AEMs release timeline to decide if you can wait for some time for the next release before performing the migration. 

Or to be safe, you might not want to move to the version that just got released but instead wanted to move to the latest – 1 version so that the stability is guaranteed.

Step 3: Assess the current state

Once you have established the objectives for the upgrade, the next step is to analyze the current state and document it (or update your documentation if there is already one present). 

The current state document should include all the details relevant for migration, including

1. The topology of the deployment – including all components (Author, Publish, Dispatcher, integrations, third party systems, …) and their specifications
2. Current infrastructure details
3. Operating systems and JRE versions the current environment is on
4. The size of your current repository, and how recently / frequently the compaction and maintenance jobs are run
5. The sanity and validity of the content accumulated – How much of your current content is junk?
6. A listing of OOB components and services used by the application
7. Details of all the custom components and services deployed. How frequently do they change? Is there any development work in progress? What is the release cycle followed? When is the next release planned?
8. Document all the customizations done on the AEM directly (OSGi configurations, Workflow customizations, Overlays, User/User Groups, ACLs,…)
9. Document all the indexes used (OOB or custom indexes created). Newer versions do not come with indexes pre-defined and we will have to plan creating all missing indexes when migrating
10. Document the users and usage volume – No. of users, frequency of access and authentication, authorization mechanisms
11. Does the application generate UGC content? How much is the volume of content created each day?
12. Detail of integrating systems and integration approach followed by each. Are the regular feeds into AEM or going out of AEM?
13. Constraints and limitations in the current setup that you would like to be addressed in the target environment

With the objectives established and detailed analysis done on the current state, we can jump in to define the target state on the decided target AEM version. The next part covers this aspect

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