Every Microsoft Identity Manager (MIM) retirement plan reaches the same slide: the joiner, mover, and leaver workflows move to Entra ID Governance lifecycle workflows. For a lot of estates that slide is right. For others it hides the hardest part of the project. Azure IAM, LLC, an independent identity consulting firm that migrates MIM estates, keeps a running list of where the two products diverge, drawn from Microsoft’s own documentation and from assessments at clients like Contoso. The firm’s migration method is documented at https://azureiam.com/mim-to-sailpoint
What a lifecycle workflow is
A lifecycle workflow is a job in Entra ID Governance that runs a sequence of built-in tasks against users who meet an execution condition. The condition is a trigger plus a scope. Triggers are time based (a number of days before or after employeeHireDate, employeeLeaveDateTime, or createdDateTime), attribute change based, group membership based, or on demand. Scope is a rule over user attributes, such as department equals Finance.
The task list is Microsoft’s catalog: welcome and reminder emails, Temporary Access Pass generation, add or remove from groups and Teams, assign or remove licenses, request or remove access packages, update attributes, enable, disable, and delete the account, and a custom task extension that calls an Azure Logic App. Microsoft’s FAQ is explicit that new task types cannot be created; anything outside the catalog goes through a Logic App.
The numbers Microsoft publishes
The Entra ID Governance service limits page sets the ceilings. Azure IAM reads them against a typical MIM estate.
100 workflows per tenant. A MIM shop with one workflow per department per lifecycle event hits this quickly. Workflows have to be designed around scope rules, not copied one to one.
25 tasks per workflow. Long MIM action workflows with dozens of sequential activities are split or collapsed into Logic Apps.
100 custom task extensions per tenant. Every piece of logic that does not match a built-in task consumes one.
Five administrative scopes per workflow, and ten users per on-demand run. Bulk remediation of a thousand accounts is not an on-demand feature.
A trigger offset of 180 days either side of the date attribute. Workflows that need to fire a year before a contract expiry use a different trigger.
A schedule of every one to 24 hours, three by default. MIM run profiles can fire every few minutes; lifecycle workflows cannot.
Four gaps a MIM shop notices first
Users only. Lifecycle workflows operate on user objects in Entra ID. MIM’s synchronization engine and request pipeline operate on any object type in the metaverse: groups, contacts, computers, and custom resource types such as locations, applications, or cost centers. Estates that use MIM to create, expire, and clean up groups, or that govern a custom object class, find no equivalent task.
Cloud groups only. The add and remove group tasks support Microsoft 365 groups and cloud-only security groups. Microsoft lists the exclusions: mail-enabled, distribution, dynamic, and role-assignable groups, and any group synchronized from Active Directory. Controlling access to an on-premises application that reads an Active Directory group means creating the group in the cloud and writing it back with Cloud Sync group writeback. That changes the group model itself, which is a design decision, not a task setting.
Hybrid users carry conditions. For users synchronized from Active Directory, the enable, disable, and delete tasks require the Microsoft Entra provisioning agent at a minimum version, a group managed service account with rights over the user objects, and the Active Directory recycle bin for deletions. The disable task does not run against users holding an Entra role or sitting in a role-assignable group. The update attributes task handles only directory extension attributes for synchronized users, up to ten per task. The time-based triggers depend on employeeHireDate and employeeLeaveDateTime being synchronized from the HR source. And every trigger waits for Connect Sync or Cloud Sync to carry the change up before the workflow engine can see it, so a termination entered on premises passes through a sync cycle and then a workflow cycle before the account is disabled.
Custom logic moves out of the engine. MIM workflows are Windows Workflow Foundation activities that can run any .NET code, and rules extensions execute inside the sync engine against every connected system. In Entra ID Governance that logic becomes consumption Logic Apps, invoked by a custom task extension in launch-and-continue or launch-and-wait mode with a bounded timeout. The Logic Apps need their own identities, network paths, error handling, and monitoring. A Contoso-sized estate with forty rules extensions and a dozen custom activities arrives at a Logic Apps portfolio rather than a single sync server.
What lifecycle workflows do better
Azure IAM is equally direct about the strengths. For cloud-first users, lifecycle workflows are easier to author than MIM workflows, visible in the admin center with per-run history and audit, and now protected by tenant-wide and per-workflow execution limits that quarantine a run exceeding a user count or percentage until an administrator approves it. MIM has never had a guardrail like that. Temporary Access Pass onboarding, license removal, access package assignment, and timed deletion after termination are cleaner in Entra than the MIM equivalents.
The sorting exercise
The firm’s assessment for a MIM exit inventories every workflow, management agent, and rules extension and places each in one of three buckets.
Bucket one moves to a lifecycle workflow as is: user-scoped tasks on cloud or synchronized users that match the built-in catalog.
Bucket two moves with a Logic App: user-scoped tasks that need custom logic, within the 100-extension cap.
Bucket three does not fit the model: group lifecycle, custom object types, provisioning to systems that Entra’s connectors do not reach, and heavy code that would turn into an unmanageable Logic Apps estate.
When bucket three is empty or small, Entra ID Governance is the right destination and Azure IAM says so. When bucket three holds the work the business actually depends on, the firm moves the estate to SailPoint IdentityIQ, where workflows, BeanShell rules, and connectors operate on any object type and any target system, and uses Entra ID Governance alongside it for the cloud-native pieces.
The timing is a choice, not an emergency. Microsoft supports MIM 2016 SP2 until January 10, 2029, and MIM 2016 SP3 is available for estates that need to stay current while the assessment runs. Azure IAM scopes the assessment and the migration on a fixed fee. A consultation request at https://azureiam.com/contact is the first step.
Azure IAM, LLC
2521 North Main
Unit 1-276
Las Cruces
New Mexico
88001
United States
