Hi @hardikbamaniya There is no migration, it is more like a re-implementation. There is no one-to-one equivalent between OIM and ISC objects and configurations. What I would do is to build a new design document, based on actual project implementation and everything you can take from your OIM environment. Note that there are significative differences, like OIM being an on-premise tool and ISC a SaaS tool. This, with the fact that OIM supports java adapters, can make tome things not implementable on ISC.
However, you can make some mappings that helps to build this new ISC design document based on OIM environment:
OIM Users: look for authoritative connectors that create the OIM users, these will be traduced into ISC authoritative resources + identity profiles → identities.
Resource objects (non authoritative) / application instances: these will be your sources in ISC.
Roles + Access policies: you can use them to configure your ISC roles.
Lookups: there is no place in ISC to hold mapping values (code/decode). You will have to manage it for each source.
Adapters / event handlers / plugins: this is the hard logic in OIM, you can implement logic in ISC with transforms and rules (perhaps this is the point when you find something that is not implementable on ISC).
SOA Approval workflows: if they are simple you cane use the ootb approval configuration. If more complex is needed, you can rely on ISC forms and workflows.
Provisioning / Reconciliation tasks: if you have some custom logic made with event handlers, you may traduce them to transforms or rules. In ISC it depends on the connector type.
Notification templates: ISC has a lot of built in email templates, and if you need to email some event, you may configure it via workflows.
Resuming, based on your OIM environment, try to describe:
- Identify authoritative sources.
- Identity login/email generation algorithms.
- Identify all envolved connected systems and its provisioning/reconciliation logic.
- Identify birthright roles.
- Identify JML events.