Businesses want to move whole legacy CQ application to new AEM 6.0/ AEM 6.1. There are different types of migration from legacy to new AEM version and it all depends on the version of legacy application. If it is below than CQ5.6 then there might be lot of efforts needed to make things work. Assets & static data can be moved easily but moving components & bundles might be a big hurdle.
However, we are here to talk about how do we move users to new AEM instance without any manual effort. When we proceed migrating users & their groups, first thing comes to our mind is that let’s create a package of all the users & their groups and install it in another instance. This seems pretty right approach and convincing as well. To be fair, AEM package manager module is built for such things (Importing/Exporting content & AEM stuff).
But when you try to install a package that contains users & groups info of legacy system, it throws a big exception and leaves you with no hope. Let’s see the exception first..
com.day.jcr.vault.packaging.PackageException: org.apache.jackrabbit.vault.packaging.PackageException: javax.jcr.nodetype.ConstraintViolationException: OakConstraint0025: Authorizable property rep:authorizableId may not be removed.
at java.lang.Thread.run(Unknown Source)
Caused by: org.apache.jackrabbit.vault.packaging.PackageException: javax.jcr.nodetype.ConstraintViolationException: OakConstraint0025: Authorizable property
Caused by: org.apache.jackrabbit.oak.api.CommitFailedException: OakConstraint0025: Authorizable property rep:authorizableId may not be removed.
What to do now? Create all the users & their groups in another system? Not a good idea, you can’t simply do that. What about their passwords?
Here is the solution:
Well, many of us as AEM developers agree that package manager is the right tool for moving content (even taking backup of content). Though it does not work efficiently for moving large content and assets. There are multiple open source solutions. For instance, “GRABBIT” is one of the best and fastest tool to transfer content from one system to another.
Let’s get back to our problem in hand. In this case, package manager throws big exception and does not provide a clue here.
But if you look closely, it seems, package manager is not able to override the admin accounts. Actually, CRX is not allowing admin users to be overridden. In a way, it is right in doing so. Our personal opinion is that CRX is not allowing admin users to be overridden because admin has all the privileges and AEM stores permissions information in a different way. It maintains “rep:policy” nodes to keep privileges and can’t be overridden just like that.
Package manager does help when you want to move users & groups privileges from one instance to another which is a different case.
In order to solve the above problem, we are still going to use package manager. Follow the steps below:
- Create a package and put all the users & their groups.
Exclude few users & groups :
- admin & administrative anonymous (not necessary but good to keep it excluded)
- If same user & group are found in both environments; delete from AEM 6 instance before installing 5.6 user package. You should ignore admin & anonymous here too
- Install it
- To verify your accounts, login with any of your group. Also you can verify logged-in user’s privileges.
This solution is tested and proven in one of our applications. However, if you still find any issue, leave a comment, we will try to help you.