We are going to meet a prospect that's using Sun IdM.
After showed our CA Identity Suite I would like to present a Migration Path from SUN to CA solution (analysis, activities, timeline, etc)
Anybody has already done it and want to share ?
I doubt that anyone can just share something. Migrations are entirely dependent on the circumstances and the environment. Mainly they depend on the data you have and your requirements.
You shall basically check out IDM's bookshelf guides , specifically look into the upgrade guide.
However, if you refer to your directory's data and how to migrate that into a new corp user store for IDM then most likely you shall do that by exporting current data into LDIF files , then uploading it to IDM's directory before even installing IDM.
I hope this helps somewhat.
We are completing a migration of Sun IM to CA IM. There are a couple of things to keep in mind, and one recommendation that I will make.
First, it is important to keep in mind - and emphasize to management - that Sun IM and CA IM have completely different models of how identity management is done.
Sun IM uses a lightweight model, both in infrastructure and in the amount of data overhead. Sun IM can be completely implemented using one database and a single application server. It does not keep track of the existing state of endpoints, accounts, or user identities, which means it is extremely agile and resilient. This is ideal in environments where changes are potentially being made by multiple groups or systems, because Sun IM will "explore" the accounts first and then make changes as needed based on what they actually are, versus what they are "supposed" to be. This model makes compliance auditing more difficult and cumbersome, and moves RBAC management to an external, possibly even manual, process that is only loosely implemented within the system.
CA IM uses a heavier model, implementing multiple systems to track the current state of each endpoint, identity, and account, as well as establishing the templates, roles, and policies necessary to move from point A to point B. This is ideal in environments where management wishes to establish RBAC and/or perform compliance auditing by comparing the actual state to the ideal model. If management is willing to restrict changes to only those using the CA IM system, everything will work very smoothly, but if changes are being made by other systems or groups, things get ugly in short order.
My recommendation then, is based on the above. An organization that is used to the fast-and-loose Sun IM model may have difficulty changing their thinking to the much more formal CA IM model. If they attempt to take their existing processes and force them into CA IM, they might get it to work, but they are more likely to get frustrated by how CA IM "doesn't work well" or is "slow." Encourage them to go through a requirements process to really re-think their identity management processes so you can design a flow that makes sense for the CA IM data-heavy model. Otherwise, the road will be a rocky one. You might be able to encourage this by explaining that there is no real "migration" for this, it is actually a conversion. Each part of their Sun IM system will have to be evaluated, redesigned, and ported to CA IM anyway, so they really should take the time to back up and look at the whole picture first so they convert things in the right order.