The older your current version of AEM is the more complicated and longer the process of the upgrade will become, and unfortunately, there are no exceptions to this rule
Is it worth upgrading to 6.5?
Shortly speaking: yes. 6.5 is an evolved version of 6.4 that brings many improvements and bug fixes, including:
● Headless CMS,
● SPA improvements,
● Core Components upgrade,
● Remote DAM & Sites Authoring sync,
● Adobe Asset link Extension with AEM Assets,
● Adobe Stock integration,
● AEM Desktop App 2.0.
You can find a complete list here.
These changes are important, that’s for sure, but are they worth investing time and money to upgrade? That’s an open question.
What is, however, unquestionable is the fact that AEM is going to the Cloud. For some customers, it may be a very attractive and beneficial move. The one that will not be possible without updating to 6.5.
Last but not least, Adobe has just released AEM Service Pack 6 (!), so we are now on 6.5.6. Given that 6.5.0 was released in April 2019, it is a very mature and stable version of the product.
What is your current version of AEM?
That is a crucial question. Depending on the answer, you may get a gut feeling of how complicated the upgrade process will be.
Adobe has recently made a lot of significant changes in AEM:
● 5.6 -> 6.0 was a revolutionary step (CRX was replaced by Jackrabbit Oak, therefore, you have to migrate CRX2 repositories using the crx2oak tool)
● 6.3 introduced a new format for SegmentNodeStore which also requires a repository migration (including downtime)
Each of these significant changes introduces another level of complexity to the upgrade process. To cut a long story short:
● 6.4 -> 6.5 will not be a problem, in-place is possible
● 6.3 -> 6.5 should be fine, in-place is possible
● <6.3 -> 6.5 (especially 5.x -> 6.5) will be a challenge, in-place may not be possible
AEM upgrade is not a task, it is a project
As you probably remember from my previous article, the AEM upgrade is not a simple task and has to be carefully planned. What I did not mention last time is that even if you plan the process well, it will still take a significant amount of time to execute it. Adobe confirms that in the upgrade documentation: Upgrading AEM is a multi-step, sometimes multi-month process.
The older your current version of AEM is the more complicated and longer the process of the upgrade will become, and unfortunately, there are no exceptions to this rule.
Upgrade options
In order not to overcomplicate this chapter – there are two options of migration: in-place upgrade and the so-called clean installation. Both have pros and cons and match different business/technical scenarios.
In-place upgrade
An in-place upgrade is a way recommended by Adobe and that itself is a major advantage. In a nutshell, the process requires a few manual steps (jar upgrade, unpack, Content Repository migration, upgraded code deployment) performed on the existing instance that will upgrade it to the newest version.
Obviously, nothing will happen magically, you still have to adjust your code to be compatible with the version you are upgrading to, but… you will not forget about: migration of the users, unobvious content (e.g. tags), ACLs or you will not lose historical entries.
What’s the price you have to pay then? There are not that many disadvantages of such an approach. In my opinion, if you include a step to clean up your content, that is the right option to choose.
Clean installation
This approach is completely different from the previous one. It assumes that you will not use any automated tool from Adobe to automate your upgrade process. Instead, you will spin up a completely new, “fresh” instance that you will use as a foundation for the next steps, that include content (incl. DMA), configuration (OSGi configs), users, tags, etc. As a matter of fact, it is quite likely that you will not remember everything and some pieces will be missing on the target instance. Half of the trouble if you notice that, a much worse scenario if you do not and the instance will start behaving in an unpredictable way.
So… are there only downsides of such an approach? Of course not, in some scenarios (especially if you are upgrading from 6.1 or 6.2) that may be the only way. Also, a clean installation forces you to (finally?) clean up your instance from the unwanted content, configuration, etc.
Pattern Detector
Adobe introduced quite a useful tool called Pattern Detector, it helps to tell approximately how complicated the upgrade process will be. As stated in the documentation:
This feature allows you to check existing AEM instances for their upgradability by detecting patterns in use that:
- Violate certain rules and are done in areas that will be affected or overwritten by the upgrade
- Use an AEM 6.x feature or an API that is not backwards compatible on AEM 6.5 and can potentially break after upgrade.
After running this tool, you will be able to check:
● OSGi bundles exports and imports mismatch
● Sling resource types and supertypes (with search-path content overlays) over usages
● definitions of Oak indexes (compatibility)
● VLT packages (overuse)
● rep:User nodes compatibility (in context of OAuth configuration)
Summary
The upgrade is a process that is much closer to a project rather than to a task. But when it is planned well and you choose the right approach, there is quite a good chance that you will succeed. Anyhow, the upgrade will pay off, eventually.
