Repeated Migration or Deletion of an Old Migration
It is possible to execute migrations multiple times. All of the migration results of the previous migrations are completely deleted for all users from the user group that is to be migrated again. If a subgroup of the previously migrated users is part of the new group to be migrated, a warning is given that you can ignore if you wish.
It is recommended that you first delete completely or that you do not migrate subgroups of already migrated users to avoid any inconsistencies or incomplete authorizations that might occur.
You migrated as explained in the previous example. Now you want to migrate only user USER1 and authorization object BO1 in a second step. Because only user 1 is authorized for this authorization object, this user group is recognized as being complete.
You now have to delete before migration. All authorizations for user USER1 are deleted, including BO2. The system then determines that USER2 is also authorized for this object, so it gives a warning that user USER2 is missing. You can ignore this warning. In this case, the new authorizations were also deleted for user USER2. The warning is noted in the log.
You can also choose Recall Old Migration as the migration option. You use this to undo the migration for complete user groups. The same conditions apply as for repeated migration.
- The migration help is designed for only a few migrations during the upgrade. It is not intended for regularly migrating newly created authorizations or those generated using the old concept. Nor can the complete functionality of a migrated authorization concept be guaranteed without manual reworking.
- Complex authorization concepts may demonstrate different behavior after migration in the details. This is especially true for concepts that are based on the compatibility modes for referencing characteristics with hierarchy and referencing navigation attributes. These have to be checked in detail and adapted manually as required.
- It is not possible to migrate variables of type customer exit for characteristic 0TCTAUTHH because they have no equivalent in the new concept. The associated hierarchy nodes have to be inserted manually or read using node variables of type customer exit for query runtime.