What's New in AEM 6.3: Upgrades
Anyone who has been in the business of content management knows the words “upgrade” and “migration” carry a heavy weight and are often cumbersome, painful, and expensive. Many of the issues are rooted in the fact that every project or implementation is different; but there are common pain points that can be streamlined, if you know what to look for. With Adobe’s latest release of Adobe Experience Manager (AEM 6.3), they have taken the opportunity to improve the upgrade process from previous versions of their product. In this post, we’ll talk about a few of these changes, and how they will help save you some time when you upgrade to 6.3.
And if you missed our previous post on AEM 6.3 Sites, you can find that here.
Pre-Upgrade Maintenance Tasks
One of the cool things about AEM 6.3 is the additional support Adobe has provided for upgrading to this version. Adobe has provided a more streamlined approach than in the past for most of the pre-upgrade maintenance tasks.
They have added content packages that can be downloaded from the package share: PRE-UPGRADE-TASKS-CONTENT-${currentAEMVersion}, where ${currentAEMVersion} is ‘CQ62’ for 6.2. This package comes with an OSGi component that can be configured to run all the necessary pre-upgrade maintenance tasks together at one time. Example tasks include: revision clean up, workflow instance purging, audit log maintenance, etc. These are all bundled together conveniently and can even be viewed from the health check dashboard.
These tasks give you the flexibility to run a single task, all tasks, check when the last time tasks were run, etc. Another useful thing about optimizing all these maintenance tasks is they are centralized and easy to read, for example, the “runAllPreUpgradeHealthChecks()” task reports out to a single file that gets dropped in the crx-quickstart folder: “preUpgradeHCStatus.properties” (example contents of that file are shown below). This gives you a single source for information on which tasks succeeded and which failed, along with any errors they produced.
Pre-Upgrade Compatibility Checks
Additionally, there is a new task that checks the version compatibility of all the bundles currently installed on your environment. It will report out any APIs that are currently being used that will not be compatible with the target upgraded version. This is especially helpful because it is a proactive approach to determining what changes developers will need to make to support the new version. It expedites the process of testing for what doesn’t work in the new version, fixing it, then it testing again. To run this task, you only need to be on the PreUpgradeTasks JMX page and run the detectUsageOfUnavailableAPI() task.
Content Repository Upgrade
AEM 6.3 introduces a new version of the Oak Segment Tar. This new storage format provides performance improvements along with better support for Online Revision Cleanup. What this means though, is any content from a previous version of AEM will need to be upgraded in order to exist on the new data store.
Luckily, Adobe provides a tool to do just that, as part of the regular AEM 6.3 quickstart jar. The actual migration to the new datastore is performed by using the new “-x crx2oak” option when running the 6.3 quickstart jar. You should note that the full command for running the quickstart jar will vary depending on the version of AEM you are upgrading from, as well as the source and target datastores. Please reference Adobe’s documentation before performing the actual data store migration.
Post Upgrade Check Automation
Previously, checking if your upgrade was a success or not required meticulous parsing of several different log files, parts of the content repository, and the launchpad. With 6.3, there have been strides to consolidate this information to a single source that is written to a log file named “upgrade.log”. This log file will indicate any issues that may have risen from the upgrade, along with indicators if any manual steps need to be taken.
A few of the possible issues you might see at this point would be things like bundles not installing or switching to the active state. If you do see this happening it is most likely being caused by unresolved dependencies in that bundle. Check again the list of unavailable APIs from the detectUsageOfUnavailableAPIs JMX task, and make sure none of the bundle’s dependencies are listed.
Your AEM 6.3 Upgrade
Hopefully with these improvements and automation provided, your understanding of AEM 6.3 has improved and when you move to upgrade, you will already know some tips to make the transition easier. Check back next week as we do a deeper dive into Adobe’s new “Core Components” and what your development team needs to know about them. And, if you missed our post on the benefits of AEM 6.3 Sites, you can read it here.
Need help implementing or optimizing your AEM solution? Reach out to us today.
Subscribe to Our Newsletter
Get the latest insights from Blue Acorn iCi