Migrate from Novell IDM to Microsoft Identity Manager (MIM): The expert prep guide

The need to migrate from Novell IDM to Microsoft Identity Manager is a common issue. Customers are keen to move away from a legacy environment that is difficult to support. Takeovers by Attachmate (who rebranded the platform NetIQ) and more recently MicroFocus have done little to dispel those concerns. This guide will let you know what you need to consider as part of any migration.

Abstract IT data image to represent complexity of Novell IDM to MIM migration.

Preparing to migrate from Novell Identity Manager to MIM

In general terms, the overall architecture of Novell’s IDM and Microsoft’s MIM are very similar – both have a hub-and-spoke approach to moving data around. Data flows out from systems like HR into the ID Vault, and from there it is processed and distributed to other connected systems.

With MIM, the systems are linked in the same way. However, there are some terminology differences. These can be confusing, but the names can be interchangeable.

The following table shows the differences at a high level:

 Novell IDM MIM
 Driver Management Agent or Connector
 Loopback Reflector
 ID Vault MetaVerse
 User App Portal

The Novell system uses terminology to describe the directionality of the driver. The publisher channel goes from the system into the Identity Vault, while the subscriber channel transmits information from the Identity Vault to the target system. Each driver has both of these components.

Understand the key difference between each system

The biggest difference between these systems is the basis on which changes are made. In the main, Novell IDM is event-based. This means it waits for a change to be made in a connected system and this initiates a synchronisation of the change from the source to the Identity Vault. MIM is more state-based, this means that it regularly polls the connected systems looking for changes. These are then processed in batches. MIM does have the capability to handle changes immediately (on an event basis) where that is appropriate. As an example, workflows, which are much more immediate in nature, can initiate changes in connected systems immediately.

This change in the nature of the systems does mean that a better understanding of the timings between the systems is required. To give a better example, changes in HR systems tend to be future dated (for example, Bill is changing department next Monday), so there is no need for this to be event driven. As long as the change is seen and acted upon, it will still take place. This event basis allows MIM to directly search against HR on a regular basis – this could be hourly, daily, or anything in-between. Other changes (for example, Bill has requested access to a file share through a group membership) are much more immediate. When handled through workflow, they should be processed directly.

Questions to ask before migrating

With the main architecture understood, the migration can start to move ahead and a better understanding of the environment will be required. For this, the following questions need to be answered:

  • Is the system doing what it should be doing?
  • Are there any enhancements that relate to the current solution and are causing issues?
  • Is a full set of documentation available?
  • Is a “Designer” dump of the complete environment available?

Of these, the enhancements are the most troublesome. As a rule, the migration should deliver a like-for-like replacement. Adding in complexity makes the testing much more difficult and will increase the effort required to implement the new solution.

“Designer” provides the migration with a stable basis. The ability to investigate the actual complexity held within the identity management system, and to be able to refer to exactly the criteria that the current system is using to define its logic, is essential.

Once the “Designer” files have been analysed then a new MIM design can be proposed and accepted along with detailed designs for each of the connectors. These will then be used to initiate the build and development required for the system.

Ready to migrate

The migration should then take place – but not as a big bang. This should be a staged migration, with systems being moved from Novell across to MIM individually.

The migration from Novell IDM to MIM is complex and should not be underestimated, but it does deliver a supportable environment with a good roadmap moving forwards. A good understanding of the current environment, with the ability to discern the components in place and how they interact, is key. If these are in place, or can be obtained, then the project can start.

This article was written in collaboration with Jason Banks.

If you need help migrating from Novell IDM to Microsoft Identity Manager, please contact usAlternatively, watch our Privileged Access Management webinar and discover more about MIM’s new security feature.