Okay, I'm probably going to get some heat for this, but here goes. We just finished a full migration from Okta to Entra ID (formerly Azure AD). Our environment is about as "Microsoft shop" as it gets: 365, Intune, the whole suite. After six months on it, my take is that it's... fine? It gets the job done. But "exceptional" or "best-in-class"? Not from where I'm sitting.
The integration is obviously seamless. One less bill, one less dashboard, and the conditional access policies are powerful once you wrestle them into shape. For simply managing user identities and access to Microsoft apps, it's perfectly adequate. But the moment you need to do anything slightly more nuanced, like automating group management from our HR system or building custom reports that aren't out-of-the-box, you feel the friction. The admin experience feels clunky compared to some competitors. It works, but it's not a joy to use.
I'm curious if others in a similar boat have found this. Are we just not leveraging it correctly? For those who migrated from a dedicated IDP like Okta or Ping, do you regret it? Or was the trade-off of "good enough" for tighter integration and cost savings actually worth it? I'm specifically interested in the migration war stories around custom app provisioning and support ticket fallout. Did your help desk get flooded?
The grass is greener? We'll see.
Your point about feeling friction for anything beyond basic management is spot on. That clunkiness isn't a configuration problem - it's a design philosophy. Microsoft builds for the 80% use case, where "good enough" integration beats best-in-class user experience. The cost isn't just in the licensing you save; it's in the internal developer hours you'll spend writing Graph API scripts to automate what Okta did with a few clicks.
For a pure Microsoft stack, that trade-off is often mathematically correct. But it does mean accepting that your IAM will be a utility, not a strategic asset. Did your team factor in those ongoing "friction" labor costs when calculating the ROI of the migration away from Okta?
James K.
Your experience mirrors what I've seen in three separate migrations I've advised on. The friction you're describing becomes a tangible cost.
The "one less dashboard" benefit is real, but you're right that it often just moves the complexity. I've spent more hours than I care to admit writing and maintaining PowerShell scripts that interact with the Graph API for things like dynamic group memberships based on custom attributes. In Okta, that's a UI-driven policy. The trade-off calculation often ignores the ongoing platform engineering effort required to make Entra ID operate at the level a dedicated IDP provides out-of-the-box.
For a pure Microsoft shop, the math can still work, but only if you honestly quantify that labor. Most organizations don't. They see the license savings and stop there. Did your team establish a baseline for "admin hours per 100 users" on Okta versus what you're now forecasting on Entra ID? That's where the real answer lies.
Totally agree on the "moves the complexity" point. We quantified admin hours, but only after the migration. The forecast was a joke because we underestimated how often a "simple" Graph API script needs updating when Microsoft changes an endpoint or adds a new field.
The real hidden cost? It's not just engineer hours, it's the *risk* of those scripts breaking. A UI policy in Okta might get a deprecation notice. Our custom PowerShell script for syncing department data just failed silently for a week once. That's when "good enough" becomes a liability.
It's not marketing, it's logic.