AEM upgrade – the plan!

Practically speaking, the whole process of upgrade should be divided into 5 phases:

• Analysis
• Plan
• Development & Test
• Go-Live
• Post-Go-Live support & maintenance

Let’s go through each phase separately and discuss its purpose.

Analysis

The goal of this phase is to find out what is the current state of your AEM solution. Given that AEM platforms are usually long-living ones, it may appear that your knowledge needs completion.

Questions that should be helpful in this phase:

• What’s the architecture of the solution? Is AEM a part of some bigger system? (perhaps upgrading AEM is only a part of the bigger program?)
• Do I use any 3rd party solutions/frameworks/accelerators? (am I able to upgrade it on my own?)
• What are the current results of security and performance tests?
• Do I know all the features that are currently built-in the system?
• What’s the level of testing? Do I have test scenarios that cover all the features? Are tests automated?
• How many Custom Components were implemented? How complicated are these?
• Are there any Custom Workflows in the system?
• Did you make any change in the AEM Request Processing flow?
• Which OS do I use? What’s the Java version? Which dispatcher version is in use?

Finding answers to the above questions should help you to increase the level of knowledge about the system and point out missing bits (e.g., automated tests). What is more, the estimate of the project should be much more accurate when that information is taken into account.

Plan

Given that you gathered all the required details during the Analysis phase you should now be able to prepare an upgrade plan. To prepare it you must estimate certain steps of the process – make sure that you include all the subtle details like the presence of the 3rd party libraries or accelerators. To estimate the development part, practically you may need to assume some time per each component/feature. It may not be fully accurate but on the other hand, estimating such migrations is always a challenge.

What is the measure of a successful migration? That is not a simple question and most likely, the answer depends on the project, however, there is something that always describes it well – the quality. The test plan is crucial in this situation – first of all, make sure that you identified all the test cases (information gathered during the Analysis phase will be extremely helpful here – custom components, features, workflows must be identified!), do not stop on that – make sure that all the tests pass. Do not focus on functional tests only, remember about the performance (usually, it should not be worse than in the legacy platform) and security!

Make sure that you remembered about training and documentation. Authors must be able to work on the content since day one, so usually, providing them with all the required training should happen right after the development phase is done.  Think about the best form of training – consider interactive workshops combined with the docs. Additionally, make sure that your technical documentation is up-to-date and it does its job.

The platform lives, probably some campaigns or events have already been planned – think how does it influence your plan. Perhaps some features will be implemented twice (to some extent), obviously it is better to avoid such situations, however, let us be realistic – it may happen. Make sure that your developers are aware of changes being made on the legacy platform and they incorporate these changes on the upgraded codebase as well. Naturally, the alternative solution is to freeze all the features until the platform is migrated – this scenario is much cheaper, less complicated, so whenever you can follow that path – do it.

Development & Test

The majority of development activities will take place in this phase (that will be a subject of our next article).

Upgrade & Rollback procedures must be designed and (at least initially) approved in this phase. Never assume that everything will go right, having the option b) is a good habit, especially given the fact, that the upgrade is not an easy to revert the process.

If you have not done that yet, implement a decent monitoring system. Analyzing logs using ‘less’ or similar tools is so 2010… Having a good tool (or a stack) will save you hours or days going forward.

Do not forget about the documentation (technical and author) – it is the right moment to revisit its format and question its usability.

Go-Live

The Go-Live procedure must be planned & approved in the previous phase. Make sure that everyone knows what is their responsibility when they need to undertake action and what should happen if things went into a bad direction. The whole process must be transparent and understandable to all your stakeholders. That will pay off.

Post-Go-Live support & maintenance

Launching the project is not the end of the process. Post-go-live support is essential, especially right after the upgrade process, where you should monitor all the logs, CPU and Memory usage, repository size, etc. At least during the first two weeks after the upgrade the system should be monitored in carefully. Additionally, it is worth monitoring all the patches, hotfixes and services packs released by Adobe, especially when you have just upgraded to the version that was released recently.

Summary

The number of phases and steps called out in this article proves the thesis I made at the very beginning – the upgrade is not trivial and it has to be planned well. However, it is planned and done right, it will pay off, especially that you can use this time to improve the quality, documentation and even some features.

The next article will focus on the technical aspects of the upgrade.