...

Unpool Organizational Identities

Platforms brought up on Registry v3.0.0 or earlier had the option to enable Organizational Identity Pooling. This setting is no longer supported. Org Identities must be unpooled prior to Transmogrification.

Instantiate Extended Types

COs that were created using Registry v0.9.1 or earlier may be relying on default attribute types. For any such CO, click "Add/Restore Default Types" (via Configuration > Extended Types) for each available attribute.

From v0.9.2, Extended Types were enabled by default.

Migrate Login Identifiers

Login Identifiers are now attached to the Person, not the Organizational Identity. Transmogrification can be passed flags to migrate login Identifiers. Multiple flags can be provided. If no flags are provided Transmogrification will not perform any actions, except that login flags will be removed from Identifiers not associated with a Person.

• --login-identifier-copy: For any Identifier associated with an Org Identity that is flagged for login, a copy will be made attached to the associated Person record.
• --login-identifier-type: For any Identifier associated with an Org Identity that is of the specified type, a copy will be made attached to the associated Person record. The specified type should be the legacy v4 type string (eg: eppn) and not the transmogrified foreign key.

Check Group Names

Group name restrictions are more strictly enforced, and non-conformant names will cause the Group to not Transmogrify correctly. Check for any problematic names and fix them prior to running Transmogrification. Specifically:

1. Standard Groups may not be named starting with the string "CO:". This prefix is reserved for System Groups created by Registry, and existing System Groups (such as Administrator Groups) should not be renamed. (AR-Group-9)
2. Two Groups within the same CO may not have the same name. (AR-Group-1)

Consider Archival Requirements

As part of Transmogrification, certain database tables that are no longer required will not be migrated to the new database. This includes

• cm_co_org_identity_links: With the elimination of pooled Organizational Identities, OrgIdentities are linked directly to a CoPerson, and this intermediate table is no longer required.
• cm_org_identities: Org Identities that are not linked to a CO Person will not be migrated to the new database, nor will their associated data (such as cm_names). This includes Org Identities that were created from an Org Identity Source, but not linked (typically via a Pipeline) to a CO Person. Additionally, Org Identities that do have null (or empty) affiliations will not be migrated.

Some tables are also changed in a significant enough way that it is not possible to migrate all old records. This includes

• cm_co_group_members: This table is split into two (group_members and group_owners), and handling of non-manual memberships (eg: from group_nestings) is changing. Certain rows, including empty rows and changelog archives, are not migrated as there is not a consistent way to migrate these records.
• cm_co_jobs: Legacy job types (those prior to v4.0.0) cannot be migrated as they are no longer supported. Additionally, queued or in progress jobs are not migrated to avoid potential upgrade conflicts.

Additionally, deprecated or obsolete columns that were left in place to facilitate upgrading older versions will not be migrated to the new database.

It may be desirable to create a read-only archive of the old database for future auditing or historical needs.

Setting Up Databases

...