A plain account of how compiled MIM rules extension code becomes SailPoint IdentityIQ BeanShell, where automatic generation stops, and what a migration team should ask before trusting any generated rule.
Can a BeanShell rule be generated automatically from a MIM rules extension? It is one of the first questions asked by teams planning a move from Microsoft Identity Manager to SailPoint IdentityIQ. Azure IAM, an independent identity consulting firm, says the answer is yes when the logic stays inside what a parser can translate faithfully, and no when the code does something a translator would have to guess at. The important part is that a sound migration tells the two apart in writing, case by case, before anything is imported.
Start with what a rules extension is. It is C sharp or Visual Basic code compiled into a dot NET assembly. The MIM synchronization service calls it for work that declarative sync rules cannot express, such as advanced attribute flows, join resolution, deprovisioning, and provisioning. In many environments this is where the real business logic lives. It decides how a username is built, which organizational unit an account lands in, and when an account is disabled.
The difficulty is visibility. The MIM Configuration Documenter report shows that a flow uses a rules extension, but it does not show what the code does. Azure IAM calls this normally the hardest part of a MIM migration, and the reason most projects end up rewriting the logic from scratch.
Automatic generation works by matching each piece of code to the flow that calls it. The documenter report records each flow's mapping type as the rules extension script context. That context is the same string MIM passes as the flow rule name when it calls the extension. The match is exact. When the source code is supplied, the two halves fit together, and the result is a finished IdentityIQ rule instead of an empty stub.
The conversion is done by parsers. It is not pattern matching and it is not a language model, so the same input always produces the same output. The C sharp is parsed with a real grammar, and the reason is specific. The translator has to reliably detect the constructs it cannot honor and decline them. A subtly wrong attribute rule produces a wrong username or a wrong distinguished name that looks correct and surfaces weeks later in production.
So what gets declined? Four things. Code that loops over a multivalued attribute. Code that catches exceptions. Code that uses LINQ. And code that calls an external service. Those cases keep a clearly marked scaffold, and a caveats file states which construct stopped the translation. Refusal is per case, so one untranslatable flow never discards the others in the same file.
A common worry is missing source code. Azure IAM reports that most MIM estates it sees no longer have the source for their rules extensions. The developers left and the project files went with them. That does not force a manual rewrite. The firm decompiles the organization's own assemblies, at the organization's direction, recovers the logic, and translates it like any other input.
Provisioning code is handled differently, because it is not an attribute flow. Each connected system becomes a provisioning plan rule called from the lifecycle workflow. The request shape is generated, and the distinguished name logic is carried as comments holding the original code, so a person finishes it with the original in front of them.
There is a public sample that anyone can check. Microsoft publishes a sample MIM configuration called the Contoso Pilot estate. Running its two documenter reports through the transformation produces 18 BeanShell rules. Six are finished and 12 are marked scaffolds. Those 12 are scaffolds because the compiled assemblies are not part of the published sample, so there is nothing for the translator to read. Azure IAM states that with the source, or with the assemblies to decompile, those 12 become finished rules as well.
Generated rules still have to be proven. Every translated rule carries the original MIM logic as a comment above the BeanShell it became. Generated BeanShell is executed through IdentityIQ's own interpreter during development. Then MIM and IdentityIQ run in parallel and are compared, with MIM remaining the only system that provisions until the comparison holds.
On timing, Microsoft's extended support for MIM 2016 Service Pack 2 runs through January 10, 2029. That is enough time to migrate without rushing, though discovery of compiled logic is the step that should not wait.
Organizations still running MIM can book a scoping call with Azure IAM to learn which rules extensions will convert to BeanShell automatically and which will need a human decision. The contact page is at azureiam.com slash contact. Azure IAM, LLC City: Las Cruces Address: 2521 North Main Website: https://azureiam.com