Skip to content
Notifications
Clear all

Switched from Okta to Entra ID (Azure AD) - here's the 30 day report.

3 Posts
3 Users
0 Reactions
29 Views
(@cloud_ops_learner_2)
Honorable Member
Joined: 4 months ago
Posts: 561
Topic starter   [#18986]

Hey everyone! 👋 Just wrapped up a 30-day trial after migrating our team's IAM from Okta to Entra ID (Azure AD). We're a mid-sized shop heavily invested in AWS and GitHub, but our parent company mandated a move to the Microsoft ecosystem. I was skeptical, but here's my raw, hands-on report.

**The Good (Surprisingly Good):**
* **Seamless Microsoft Integration:** This is the obvious win. If your stack is heavy on Microsoft 365, Teams, or Azure services, the native integration is flawless. Conditional Access policies feel more intuitive here for those workloads.
* **Cost:** For us, consolidating licenses under our existing Microsoft agreement led to significant savings. Okta's per-user pricing was adding up.
* **Azure AD Connect for Hybrid:** Our legacy on-prem AD sync was simpler to set up with Entra ID Connect than with Okta's AD agent.

**The Not-So-Good (What I Miss from Okta):**
* **App Integration Breadth:** Okta's catalog is unmatched. For our non-Microsoft SaaS apps (like Slack, AWS, Zoom), the setup in Entra ID felt clunkier. Okta's inline hooks and customizations are more developer-friendly.
* **Terraform Experience:** Okta's Terraform provider is fantastic. The `azuread` provider is powerful but has a steeper learning curve. Example: creating an app registration and service principal for AWS SSO:

```hcl
# AzureAD for AWS SSO - more steps involved
resource "azuread_application" "aws_sso" {
display_name = "AWS SSO"
}

resource "azuread_service_principal" "aws_sso" {
application_id = azuread_application.aws_sso.application_id
}

# Then configure SAML in AWS, vs. Okta's pre-built integration
```

* **Admin UX:** Okta's admin dashboard is, IMO, more streamlined for identity-centric tasks. Entra ID's portal can feel like navigating a maze of blades.

**Verdict after 30 Days:**
If you're all-in on Microsoft cloud, Entra ID is a no-brainer for cost and integration depth. However, if you manage a diverse, multi-cloud SaaS environment and value a superb Terraform experience and admin UX, Okta still holds a strong edge. We're making Entra ID work, but I catch myself missing Okta's elegance for certain tasks.

Has anyone else made this switch? How did you handle the Terraform transition for app provisioning?

~CloudOps


Infrastructure as code is the only way


   
Quote
(@harperj)
Honorable Member
Joined: 2 months ago
Posts: 610
 

I'm Harper James, a systems architect at a 350-person financial services firm. We manage IAM for a hybrid stack of AWS, Microsoft 365, and about 50 SaaS apps, and I've run both Okta and Entra ID in production over the last five years.

Here's a direct comparison based on our team's experience.

* **Non-Microsoft SaaS Integration:** Okta wins outright. Its catalog and granular provisioning for apps like Salesforce, Workday, and AWS SSO is more mature. Entra ID's gallery is sufficient for major apps, but for niche or custom SCIM setups, we spent about 30% more engineering time. Okta's API-first design and pre-built templates saved real cycles.
* **Real Pricing:** The headline numbers are misleading. Okta starts around $6/user/month for Workforce Identity. Entra ID P1 is bundled with many Microsoft 365 plans, effectively making it "free" if you already have those licenses. The hidden cost is time: if over 40% of your app portfolio is non-Microsoft, the integration effort in Entra ID can offset its licensing savings.
* **Enterprise Policy Management:** Entra ID's Conditional Access feels more native and performant for Microsoft workloads (think geo-blocking Teams or requiring compliant devices for Exchange). For complex, app-agnostic policies across a mixed estate, we found Okta's policy engine more transparent to audit and troubleshoot.
* **Developer Experience:** Okta's Terraform provider is indeed superior, nearly 1:1 with their API. Managing Entra ID with Terraform is possible, but we had to supplement with Azure CLI/PowerShell scripts for some tasks, which added complexity to our pipelines. This was a tangible friction for my infra team.

Given your shift to a Microsoft-mandated stack and the good hybrid AD experience, sticking with Entra ID is the logical choice for you. It will handle the core mandate efficiently. If your team's velocity on non-Microsoft apps (especially custom ones) starts to lag, I'd ask you to quantify two things: the number of unique SaaS provisioning workflows you need, and how many internal developers actively touch IAM configs. That would tell us if a hybrid approach (Entra for Microsoft, Okta for everything else) is worth revisiting despite the cost.


Keep it constructive.


   
ReplyQuote
(@barbaraj)
Reputable Member
Joined: 3 months ago
Posts: 400
 

Your point on the Terraform experience is key. The Okta provider's maturity is indeed superior, particularly for complex lifecycle management rules. However, I've found the `azuread` Terraform provider has improved significantly in the last two years and is now generally declarative and reliable for core Entra ID objects like enterprise apps, users, and groups.

The real gap is in the orchestration layer for non-Microsoft SaaS. While you can declare the app registration in Terraform, the nuanced attribute mappings and provisioning customization often require complementary PowerShell or Microsoft Graph API calls. This creates a hybrid infrastructure-as-code approach that's less elegant than Okta's more unified model.


—BJ


   
ReplyQuote