A new AEM upgrade has been released, so what now? You might think that changing a version of your content management system is pretty easy. Heck, WordPress allows you to do it with the click of a button and you’re up in no time (in the ideal world). But with AEM there’s much more to think about. For example, there are some major architectural changes with the latest version, to view more information about them click here.
With so many changes to the latest version, it’s almost hard to believe how an upgrade could go smoothly. After completing upgrades for our clients, we’ve learned a few things about what makes one successful, as well as potential challenges you may face.
Why Bother with an Upgrade?
The current site is working, why would we need to upgrade? Adobe plans to end standard support of AEM 5.6 (the latest version before 6.0) by early next year. The last thing you want is for something to happen to your site and not have Adobe’s support because you’re using an old version. That alone should be a reason to upgrade, but you may also be interested in some of the new features that AEM 6.1 offers, such as sling’s health checks tools, improved language support, and the integration of phonegap.
Why Was it Successful?
How can you tell if the upgrade was successful? The one word that comes to mind is “time”. Too often people rush into upgrades without taking the proper time to fully test their site. A major factor in the success of these upgrades was allowing developers, as well as the UAT team, ample time to test the site. They allowed the development team to test components and performance well before the UAT team got to even look at the site on 6.1. When it came time for UAT testing, there were only a few bugs that the development team hadn’t already found and were in the process of fixing. Here’s a list of a few other reasons why the upgrade was successful:
- When building components and pieces of the site on version 5.6, we always kept the theme of “build it to be re-used.” Many components we build are small, granular components that could be used across many areas of the site, making testing a lot more manageable.
- Devops and development worked closely together to determine the necessary infrastructure and architecture changes.
- Ensure you thoroughly test with the latest versions of third-party libraries and API’s.
- Made use of the open source tool, Grabbit, for easily migrating content.
It took many hours and late nights to complete a successful upgrade to AEM 6.1. In the hopes of saving other people time and money, below is a list of AEM 6.1 specific issues, as well as AEM 6.1 non-specific issues to keep in mind.
Specific Issues of AEM 6.1
- Upgrade to jQuery 1.11 (6.1 default). There weren’t obvious issues around .prop and empty json string.
- Stricter syntax on JCR Queries.
- Account for changes in data indexing in the new Jackrabbit Oak JCR implementation in AEM 6.x.
- Used TarMK instead of MongoDB, TarMK grows faster on 6.1 compared to 5.6. Offline compaction is much more important, went from 20gb to 100gb, in a week or so.
- Used a non-clustered author since TarMK was chosen. MongoDB was a larger change and licensed separately, so we tabled it for now.
- ResourceResolver updates, need to use Admin session (not recommended by Adobe) or appropriate new “Servlet user” session. For the upgrade we changed all of our anonymous resource resolvers to use the admin session with the expectation to cleanup later.
- More restrictive permissions, /etc in JCR is now blocked by default. Had to re-add permissions and update our package filters to prevent permissions from being overwritten.
- Adobe no longer provides proprietary jars. You must either export the jars yourself from your AEM instance or use Adobe’s obfuscated Uber jar for building AEM dependencies.
- Optimize queries by reducing multiple criteria. There are often performance issues with larger numbers of paths or criteria. Enable path restriction flag so criteria queries are limited to paths you specify.
- Oak doesn’t index content by default. We’ve had to create indexes manually and used ACS Commons.
- Jetty servlet container instead of CQSE. New dependency and API.
- Dependency and instance clustering changes.
Non Specific Issues of AEM 6.1
- Reverse replication issues that were also present in 5.6 but became more pronounced as you add more production nodes.
- Development and author confusion on how things used to work and what configs we had to match to previous instances to get things to work.
- Ensure you’ve properly migrated your previous users and ACLs.
- Ensure you’ve migrated any custom workflows as well as launchers.
- Custom apache rules that weren’t migrated to 6.1 (disallowing POST requests, certain rewrite rules weren’t in place).
Upgrading to the latest version of AEM is certainly a challenge, but hopefully some of the lessons we’ve learned along the way will help you in your AEM upgrade endeavor.