Eric, these migrations have been completed. Will try to answer/address some of your topics.
In short, is not a trivial endeavor nor easy to deal with topic.
- Can you provide us the impact and best practices
A - "Best practices" will differ from client to client & are generally proprietary to each..
Probably one of the most important items to bear in mind when migrating between directories (these two included) is whether or not passwords should be preserved. ome organizations will want to preserve existing ones (i.e. especially for external users) or reset passwords at migration to standard value, and force password change after first login (i.e. mostly internal users migrations).
-Do I need to recreate the new directory.XML and new IME (Identity Manager Environment)
A: Yes, ,more than likely. The two schemas will differ, in terms of attributes, schema extensions, etc.
-Is there a way I can preserve the existing IME pointing to the new Identity directory (different type)
A: You could, although that old IME and new one will be completely separated, In principle, unless strictly required by some business reason (i.e. back-out of the migration comes to mind), user data migration from one directory to another & cutover is one way. It avoids issues.
-If I need to create new IME, do I need manually create all the provisioning and identity policies?
A: In principle no. The IMEs get created the usual way - create Corp Dir, then create PROV Dir. Build base IME, then export Roles and tasks from old IME and import into new one. It is assumed that migrations happen in DEV, then UAT, QA, etc.
Thus you work out all the migration's quirks and address potential attribute and data mapping issues, for the R&T XML export - which include provisioning and ID policies.
-If I need to create new IME, do I need to re-register (re hook) all the endpoints?
A: Yes, in principle, if you change the Provisioning Manager infrastructure. At a minimum, the new IME will need to have the E/P reconfigured, then a E/C is most likely needed, to sync accounts.
-If I need to create new IME, do I need to (re hook) with siteminder?
A: More than likely, unless IME URLs remains the same (not likely, but possible). IME's are protected by SM. If only the CORP Dir changes, you could potentially update CA SSO (fka SM)objects. Although this is technically possible, keep in mind that the supported way is to let IM automatically build SSO object after SSO/IM integration. Avoids issues with CA SSO objects and XPS.
-Is there a quick way to migrate Identity data from SUN to CA Identity directories. Would there be conflict if the endpoints sync back the data
A: Not really. A lot of planning effort and data analysis should go into this.
-Are there best practice guidelines to do such migration?
A: Guideline would be to determine what is attribute mandatory to stay unaffected after migration. i.e. user passwords come to mind as one of the most important attributes to consider for migration. It changes the paradigm for the migration requirements if passwords must remain unchanged. Attributes normalization (i.e. if SunONE LDAP does not have all the required attributes for the users, when migrated to CA Directory, data needs to be reconciled and populated.
In essence, most effort will have to be put into the data set migration, normalizing said data set (ensure proper attributes exist and are preserved, populate the mandatory ones that may not exist in SunONE, but are required in CA Directory, etc.), automating the LDAP data migration and apply proper error handling (especially if hundreds of thousands of users are involved, run & ensure timing for migration execution scripts is known (important for dry-runs and go-live cutover windows. etc.).