TL;DR - Executive Summary
- Timeline: 16-24 weeks for 15K users (3 weeks assessment, 4 weeks planning, 3 weeks pilot, 10-14 weeks phased rollout)
- Zero Downtime: Achieved through staged rollout with dual SSO - users access apps via Entra ID while Okta remains active backup
- Cost Savings: $450K-$900K annually by eliminating redundant Okta licensing (most M365 E3/E5 licenses include Entra ID P1/P2)
- Biggest Challenge: Reconfiguring 200+ SaaS apps from SAML/OIDC with Okta to Entra ID - budget 2-4 hours per app
- Critical Success Factor: Linked SSO approach allows users to see apps in MyApps portal while still authenticating via Okta during transition
- Rollback Strategy: Staged rollout enables instant revert to Okta if issues arise - keep both IdPs active until 100% validated
Interactive Migration Timeline Calculator
Calculate Your Migration Timeline
Estimate project duration based on your environment complexity
Estimated Migration Timeline
Total Duration: weeks ( months)
Assessment Phase: weeks
Planning Phase: weeks
Pilot Phase: weeks
Production Rollout: weeks
Note: Timeline assumes dedicated team and executive support. Add 30-50% buffer for part-time resources or organizational delays.
1
3-4 Weeks
Assessment & Discovery
Document current Okta environment, inventory all applications, identify integration methods, assess user groups, and evaluate licensing. Use Okta API to export configurations.
2
4-5 Weeks
Planning & Preparation
Design Entra ID architecture, create app migration matrix, develop rollback procedures, establish pilot groups, configure Azure AD Connect or cloud provisioning, and prepare communication plan.
3
3-4 Weeks
Pilot Deployment
Deploy to 100-300 pilot users, migrate 10-15 key applications, validate SSO, test MFA, gather feedback, tune configurations, and document issues. Success criteria: <5% support tickets.
4
10-14 Weeks
Phased Production Rollout
Migrate users in waves by business unit or location (500-1000 users per wave). Migrate remaining applications in parallel. Monitor closely, address issues, adjust timeline as needed.
5
2-3 Weeks
Cutover & Decommission
Complete final user wave, defederate from Okta, disable Okta SSO, validate all apps functional, monitor for 2 weeks, then cancel Okta licenses. Keep Okta read-only for 90 days as backup.
📊 Phase 1: Assessment & Discovery - Know What You Have
▼
Current State Documentation
You cannot migrate what you don't understand. Thorough documentation is the foundation of a successful migration.
Assessment Checklist
Okta API Discovery Script
Use this PowerShell script to export your complete Okta application catalog:
# Okta Application Export Script
$oktaDomain = "https://your-domain.okta.com"
$apiToken = "YOUR_API_TOKEN"
$headers = @{
"Authorization" = "SSWS $apiToken"
"Accept" = "application/json"
}
# Get all applications
$apps = Invoke-RestMethod -Uri "$oktaDomain/api/v1/apps?limit=200" -Headers $headers
# Export to CSV
$apps | Select-Object id, name, label, status, signOnMode, @{
Name='Users'; Expression={($_.credentials.userNameTemplate.template)}
} | Export-Csv "okta-apps-export.csv" -NoTypeInformation
# Get detailed config for each app
foreach ($app in $apps) {
$appDetail = Invoke-RestMethod -Uri "$oktaDomain/api/v1/apps/$($app.id)" -Headers $headers
$appDetail | ConvertTo-Json -Depth 10 | Out-File "app-configs/$($app.name).json"
}
Write-Host "Exported $($apps.Count) applications"
Application Categorization
Categorize apps by migration complexity to prioritize efforts:
| Category | Characteristics | Migration Effort | Risk Level |
|---|---|---|---|
| Easy | SaaS apps in Entra ID Gallery with SSO + provisioning support | 1-2 hours per app | Low |
| Medium | SaaS apps with SAML/OIDC but manual provisioning | 2-4 hours per app | Medium |
| Hard | Custom apps with vendor-managed SSO configs | 4-8 hours + vendor coordination | Medium-High |
| Complex | Legacy apps using Okta Access Gateway, header auth, Kerberos | 8-40 hours + Entra App Proxy setup | High |
Critical Assessment Finding
If you have 20+ apps in the "Complex" category (header-based auth, Okta Access Gateway), your migration timeline will increase 30-50%. Consider Entra Application Proxy or third-party solutions like Datawiza for these apps.
Licensing Analysis
Cost Savings Opportunity
Most organizations with M365 E3 or E5 licenses are already paying for Entra ID P1 or P2, making Okta redundant:
- M365 E3: Includes Entra ID P1 (Conditional Access, MFA, SSO)
- M365 E5: Includes Entra ID P2 (Identity Protection, PIM, Access Reviews)
- Okta Workforce Identity: $3-6/user/month ($45K-$90K annually for 15K users)
- Annual Savings: $540K-$1.08M by eliminating Okta
🎯 Phase 2: Planning & Preparation - Design for Success
▼
Entra ID Architecture Design
Design your Entra ID tenant structure before migrating a single user:
| Design Decision | Recommended Approach | Why |
|---|---|---|
| User Provisioning | Entra Cloud Provisioning (not AD Connect) | Lighter, more familiar to Okta users, easier rollback |
| Conditional Access | Start with Okta-equivalent policies, refine later | Maintain security posture during transition |
| MFA Registration | Combined Security Info (not legacy per-user MFA) | Modern approach, better UX, required for passwordless |
| App Integration Method | Start with Linked SSO, migrate to federated SSO by wave | Zero downtime - users see apps before auth cutover |
| Group Strategy | Dynamic groups where possible, synced security groups for apps | Reduces manual maintenance, scales better |
Migration Wave Planning
Don't migrate all 15K users at once. Plan waves based on business units, locations, or risk tolerance:
Sample Wave Structure for 15K Users
- Pilot (Week 1-3): 100 IT team members + 200 volunteers (300 total)
- Wave 1 (Week 4-5): 1,000 users - Low-risk departments (HR, Finance)
- Wave 2 (Week 6-8): 2,500 users - Sales, Marketing
- Wave 3 (Week 9-11): 3,500 users - Product, Engineering
- Wave 4 (Week 12-14): 4,200 users - Customer Support, Operations
- Wave 5 (Week 15-17): 3,400 users - Remaining users + stragglers
Gap Time: 1 week between waves to address issues and tune configurations
Communication Plan
User communication is as important as technical execution. Plan for:
| Timeline | Communication | Audience |
|---|---|---|
| 4 weeks before migration | Project announcement, timeline, benefits | All users |
| 2 weeks before wave | What's changing, new login URL, MFA re-enrollment | Wave-specific users |
| 1 week before wave | Step-by-step migration instructions with screenshots | Wave-specific users |
| Day of migration | Migration complete, new login portal link, helpdesk info | Wave-specific users |
| 1 week after wave | Survey feedback, known issues, tips & tricks | Wave-specific users |
Rollback Plan
Hope for the best, plan for the worst. Your rollback procedure must be tested and documented:
# Emergency Rollback Procedure
TRIGGER: >5% of wave users unable to access critical apps OR
critical security issue discovered during migration
STEPS:
1. Pause new user migrations immediately (15 min)
2. Re-enable Okta SSO for affected apps (30 min)
3. Remove affected users from Entra ID staged rollout group (15 min)
4. Notify users to revert to Okta login portal (immediate)
5. Document failure root cause for remediation (2-4 hours)
6. Fix issue, test with 10 users, re-attempt wave (1-2 weeks)
ROLLBACK WINDOW: Must be executable within 1 hour of decision
TESTING: Practice rollback with pilot group before any production wave
Plan for Vendor Delays
20-30% of your apps will require vendor involvement to update SSO configurations. Vendors take 1-4 weeks to respond. Action: Open tickets with all vendors 6 weeks before their wave, not when users are migrating.
🧪 Phase 3: Pilot Deployment - Validate Everything
▼
Pilot Group Selection
Your pilot group makes or breaks the migration. Choose wisely:
Ideal Pilot Composition (300 users)
- 100 IT Staff: Technical users who can provide detailed feedback and troubleshoot
- 100 Power Users: Heavy app users who touch most integrations
- 100 Regular Users: Representative of average user experience
- Coverage: Include users from each department, location, and device type (Windows, Mac, mobile)
Pilot Success Criteria
Define clear success metrics before starting the pilot:
| Metric | Target | Red Flag |
|---|---|---|
| User Login Success Rate | >98% | <95% |
| App Access Success Rate | >95% | <90% |
| MFA Enrollment Completion | >90% within 3 days | <80% |
| Help Desk Tickets per 100 Users | <5 tickets | >10 tickets |
| User Satisfaction Score | >4.0/5.0 | <3.5/5.0 |
| P1 Incidents | 0 | >0 |
Pilot Application Selection
Don't migrate all 150 apps in the pilot. Start with 10-15 strategic apps:
Must-Have Apps (5)
M365 (Email, Teams, SharePoint), Company Intranet, HR System
High-Usage Apps (5)
Salesforce, Slack, Jira, Zoom, DocuSign
Complex Apps (3-5)
Custom SAML apps, legacy apps, vendor-managed SSO
Pilot Week-by-Week Timeline
WEEK 1: Setup & Configuration
- Day 1-2: Configure Entra ID cloud provisioning, sync pilot users
- Day 3-4: Configure 10-15 pilot apps with Linked SSO
- Day 5: Test all apps with 5 IT users, fix issues
WEEK 2: Pilot Launch
- Day 1: Migrate pilot users, send communication
- Day 2-3: Monitor help desk, address immediate issues
- Day 4-5: Begin migrating apps from Linked to Federated SSO
WEEK 3: Validation & Refinement
- Day 1-3: Complete app SSO migration, test thoroughly
- Day 4: Survey pilot users, gather feedback
- Day 5: Document lessons learned, update procedures
GO/NO-GO Decision: End of Week 3
- GO: If success criteria met, proceed to Wave 1
- NO-GO: If red flags present, extend pilot 1-2 weeks
Real Pilot Experience - Financial Services Company
15,000 users, 180 applications
- Pilot group: 250 users across 12 departments
- Duration: 4 weeks (extended 1 week due to MFA issues)
- Issues found: 8 apps required vendor updates, 2 apps unsupported in Entra ID Gallery
- Help desk tickets: 12 (4.8% of users) - mostly MFA re-enrollment questions
- Outcome: Refined procedures saved 30+ hours in later waves
Common Pilot Issues
| Issue | Frequency | Resolution |
|---|---|---|
| Users can't find apps in MyApps portal | High | Add apps to Entra ID, assign users, train on myapps.microsoft.com |
| MFA prompts every login instead of Remember Device | High | Configure Session Controls in Conditional Access policies |
| App SSO fails with "AADSTS50011" error | Medium | Reply URL mismatch - verify app configuration |
| Mobile users can't authenticate | Medium | Ensure Authenticator app enrolled, not just SMS |
| Specific app vendor says SSO change requires downtime | Low | Coordinate maintenance window, notify users in advance |
🔗 Application Migration Deep Dive
▼
Linked SSO Strategy (Zero Downtime Secret)
The Linked SSO approach is how you achieve true zero-downtime migration:
How Linked SSO Works
- Phase 1: Add all apps to Entra ID as "Linked" SSO type
- Result: Apps appear in users' MyApps portal at myapps.microsoft.com
- Authentication: When user clicks app, they're redirected to Okta for authentication
- User Experience: Seamless - users access apps from MyApps but Okta still handles SSO
- Phase 2: Migrate apps from Linked to Federated SSO in waves
- Cutover: Individual apps cut over to Entra ID auth without user disruption
SAML App Migration Steps
For each SAML 2.0 application (the most common SSO type):
# SAML App Migration Procedure
1. Document Okta Configuration
- Entity ID / Issuer
- SSO URL (ACS URL)
- Certificate (download .cer file)
- Attribute mappings (email, name, groups, etc.)
2. Create App in Entra ID
- Search Enterprise Applications → New Application
- Search gallery for app name OR choose "Non-gallery application"
- Configure Single Sign-On → SAML
3. Configure SAML Settings
- Identifier (Entity ID): Copy from Okta
- Reply URL (ACS): Copy from Okta
- Sign-on URL: Copy from Okta (if applicable)
- Attributes & Claims: Map to Entra ID attributes
4. Download Entra ID Federation Metadata
- Download: Federation Metadata XML
- Certificate: Also download .cer file for manual config
5. Update Application Configuration
- If self-service: Upload Metadata XML to app admin portal
- If vendor-managed: Send XML to vendor, open support ticket
- Verify: Certificate, Entity ID, SSO URL updated
6. Test SSO
- Assign test user in Entra ID
- Login as test user, click app in MyApps
- Validate: Successful login, correct attributes passed
7. Migrate Users
- Assign all relevant users/groups in Entra ID
- Monitor for 2-3 days with small group before full rollout
8. Decommission Okta Config
- After 100% of users migrated, disable app in Okta
OIDC / OAuth App Migration
Modern apps using OpenID Connect are easier to migrate:
| Step | Okta | Entra ID |
|---|---|---|
| Application Type | OIDC Web App or SPA | App Registrations → New Registration |
| Client ID | Provided by Okta | Application (client) ID (auto-generated) |
| Client Secret | Generate in Okta | Certificates & Secrets → New Secret |
| Redirect URIs | Configured in Okta | Authentication → Redirect URIs |
| Token Endpoint | https://{okta-domain}/oauth2/v1/token | https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/token |
| Authorization Endpoint | https://{okta-domain}/oauth2/v1/authorize | https://login.microsoftonline.com/{tenant-id}/oauth2/v2.0/authorize |
Legacy Application Challenges
Apps That Require Special Handling
- Header-Based Authentication: Apps using Okta Access Gateway → Migrate to Entra Application Proxy or Datawiza
- Kerberos/Windows Integrated Auth: Configure Entra Application Proxy with Kerberos Constrained Delegation
- Form-Based Auth: Limited support in Entra ID → Consider password vaulting or custom app integration
- RADIUS/LDAP: Use Azure MFA NPS Extension or third-party RADIUS proxy
- No SSO Support: ~10-15% of apps don't support federation → Document for future replacement
Application Migration Priorities
Migrate apps in this order to minimize risk:
- M365 Apps First: Email, Teams, SharePoint (usually already on Entra ID)
- High-Usage, Low-Complexity: Salesforce, Slack, Zoom - well-documented migrations
- Medium-Usage Gallery Apps: Apps with native Entra ID support
- Custom SAML Apps: Internal apps with IT-controlled configuration
- Vendor-Managed Apps Last: Apps requiring vendor updates (longest lead time)
- Legacy Apps Never: Header-based, Kerberos apps - migrate only if necessary
👥 User Provisioning & Identity Sync
▼
Provisioning Options Comparison
| Method | Use Case | Setup Complexity | Sync Speed |
|---|---|---|---|
| Entra Cloud Provisioning | Most Okta customers - lightweight, cloud-based | Low | 20-40 min |
| Azure AD Connect | Complex hybrid environments, extensive customization | Medium | 30 min |
| Entra ID Direct Provisioning | Cloud-only, no on-prem AD | Very Low | Real-time |
Recommended: Entra Cloud Provisioning
For organizations migrating from Okta, Entra Cloud Provisioning is the best choice:
- Lightweight agents installed near domain controllers (like Okta Directory Sync)
- No complex server infrastructure (unlike AD Connect)
- Faster deployment (2-3 days vs 1-2 weeks)
- Easier rollback if needed
- Cloud-managed configuration
User Attribute Mapping
Map Okta attributes to Entra ID equivalents:
| Okta Attribute | Entra ID Attribute | Notes |
|---|---|---|
| login | userPrincipalName | Primary identifier |
| Email address | ||
| firstName | givenName | - |
| lastName | surname | - |
| displayName | displayName | - |
| department | department | - |
| manager | manager | Requires DN in Entra ID |
| groups (Okta) | memberOf (Entra ID) | Group membership |
| Custom attributes | extensionAttribute1-15 | Limited to 15 custom attrs |
Group Migration Strategy
Don't manually recreate 500+ groups. Use automation:
# PowerShell: Export Okta Groups and Create in Entra ID
# 1. Export Okta groups via API
$oktaGroups = Invoke-RestMethod -Uri "$oktaDomain/api/v1/groups" -Headers $headers
# 2. For each group, create in Entra ID
Connect-MgGraph -Scopes "Group.ReadWrite.All"
foreach ($group in $oktaGroups) {
# Create group in Entra ID
$newGroup = New-MgGroup -DisplayName $group.profile.name `
-MailEnabled:$false `
-SecurityEnabled:$true `
-MailNickname $group.profile.name.Replace(" ", "")
# Get group members from Okta
$members = Invoke-RestMethod -Uri "$oktaDomain/api/v1/groups/$($group.id)/users" `
-Headers $headers
# Add members to Entra ID group
foreach ($member in $members) {
$user = Get-MgUser -Filter "userPrincipalName eq '$($member.profile.login)'"
if ($user) {
New-MgGroupMember -GroupId $newGroup.Id -DirectoryObjectId $user.Id
}
}
Write-Host "Created group: $($group.profile.name) with $($members.Count) members"
}
Group Migration Best Practices
- Migrate groups before apps (apps assign to groups, not individual users)
- Use dynamic groups in Entra ID where Okta used profile-based rules
- Document group naming conventions to maintain consistency
- Audit group memberships post-migration (compare Okta vs Entra ID)
🔐 MFA Migration - Re-enrollment Strategy
▼
MFA Re-enrollment Reality
Bad news: Users must re-enroll MFA in Entra ID. Okta MFA factors don't transfer.
User Impact
Every user will need to:
- Enroll Microsoft Authenticator app (or SMS/voice as backup)
- Scan QR code to set up TOTP
- Complete MFA challenge to verify enrollment
- Time required: 3-5 minutes per user
- Help desk impact: 5-10% of users need assistance
Recommended MFA Methods
| MFA Method | Security | User Experience | Recommendation |
|---|---|---|---|
| Microsoft Authenticator (push) | High | Excellent (one tap) | ✅ Primary |
| Microsoft Authenticator (passwordless) | Very High | Excellent (no password) | ✅ Future state |
| FIDO2 Security Key | Highest | Good (requires hardware) | ⚠️ High-risk users |
| SMS / Voice | Low | Fair (SIM swap risk) | ⚠️ Backup only |
| Legacy per-user MFA | Medium | Poor | ❌ Avoid |
MFA Enrollment Strategy
Phased Enrollment Approach
- Pre-Migration (2 weeks before): Send users instructions to enroll Microsoft Authenticator proactively
- Incentivize: "Enroll now for smoother experience" with IT support office hours
- Migration Day: Require MFA enrollment at first Entra ID login
- Grace Period: Allow 3-5 days for enrollment before enforcing
- Helpdesk Prep: Double staffing for first 3 days post-migration
Result: 60-70% of users pre-enroll, reducing migration day impact
Conditional Access Policies
Replicate Okta sign-on policies in Entra ID Conditional Access:
# Common Conditional Access Policies
Policy 1: Require MFA for All Users
- Users: All
- Cloud Apps: All
- Conditions: None
- Grant: Require MFA
- Session: Sign-in frequency 90 days
Policy 2: Block Legacy Authentication
- Users: All
- Cloud Apps: All
- Conditions: Client apps = Exchange ActiveSync, Other clients
- Grant: Block
Policy 3: Require Compliant Device for Corporate Access
- Users: All
- Cloud Apps: Office 365
- Conditions: None
- Grant: Require device to be marked as compliant OR Hybrid Azure AD joined
Policy 4: MFA for Admins (High-Risk Accounts)
- Users: All admin roles
- Cloud Apps: Azure Management
- Conditions: None
- Grant: Require MFA
- Session: Sign-in frequency 4 hours (more frequent than standard users)
Migration from Okta Verify to Microsoft Authenticator
Create side-by-side comparison guide for users:
| Task | Okta Verify | Microsoft Authenticator |
|---|---|---|
| Download App | App Store: "Okta Verify" | App Store: "Microsoft Authenticator" |
| Setup | Scan QR from Okta portal | Scan QR from myapps.microsoft.com |
| Approve Login | Tap notification → Approve | Tap notification → Approve |
| Number Matching | Not supported | Enter number shown on screen (extra security) |
Capitalize on MFA Opportunity
Many organizations have messy Entra ID MFA configs (legacy per-user MFA mixed with modern Conditional Access). Use this migration to clean up and modernize:
- Disable all legacy per-user MFA
- Implement Conditional Access policies
- Enable Combined Security Info registration
- Plan for passwordless authentication rollout
⏪ Rollback Procedures & Disaster Recovery
▼
When to Execute Rollback
Rollback Triggers
Execute immediate rollback if:
- >5% of wave users cannot login to Entra ID
- >10% of critical apps are inaccessible
- P1 incident affecting business operations
- Security vulnerability discovered in new configuration
- Executive decision to pause migration
Decision Window: Must decide within 2 hours of issue detection
Staged Rollout - Your Safety Net
Microsoft's staged rollout feature is the key to safe, reversible migration:
How Staged Rollout Works
- Create Entra ID group: "Entra-ID-Migrated-Users"
- Enable staged rollout for managed authentication
- Add pilot users to group → They authenticate via Entra ID
- Users NOT in group → Still authenticate via Okta
- Rollback: Remove users from group → Instant revert to Okta
Rollback Time: 15-30 minutes from decision to users back on Okta
Rollback Procedure Step-by-Step
# EMERGENCY ROLLBACK RUNBOOK
Prerequisites:
- Okta tenant still active (DO NOT cancel until 90 days post-migration)
- Okta apps still configured (disable but don't delete)
- Documentation of all changes made
ROLLBACK STEPS:
1. ANNOUNCE ROLLBACK (Immediate)
- Post in team channel: "Initiating rollback to Okta"
- Email wave users: "Login issues detected, reverting to Okta"
- Time: 5 minutes
2. REMOVE USERS FROM STAGED ROLLOUT GROUP (Immediate)
Connect-MgGraph
$group = Get-MgGroup -Filter "displayName eq 'Entra-ID-Migrated-Users'"
$members = Get-MgGroupMember -GroupId $group.Id
foreach ($member in $members) {
Remove-MgGroupMember -GroupId $group.Id -DirectoryObjectId $member.Id
}
# Time: 10-15 minutes for sync
3. RE-ENABLE OKTA APPS (30 minutes)
- For each app in rollback wave:
- Okta Admin → Applications → Find app → Status: ACTIVE
- Verify app assignments intact
- Test with 3 users before announcing
4. VERIFY OKTA FUNCTIONALITY (15 minutes)
- Test user login to Okta portal
- Test 5 critical apps via Okta SSO
- Confirm MFA working
5. NOTIFY USERS OF COMPLETION (Immediate)
- Email: "Rollback complete, use Okta portal for access"
- Post in team channels with clear instructions
- Extended helpdesk coverage for 24 hours
6. POST-MORTEM (Within 48 hours)
- Document root cause
- What failed? Why?
- How to prevent in next attempt?
- Update runbooks and procedures
TOTAL ROLLBACK TIME: 60-90 minutes
Partial Rollback vs Full Rollback
| Scenario | Rollback Type | Action |
|---|---|---|
| Single app not working | Partial (app-level) | Re-enable app in Okta, remove from Entra ID assignments |
| 10-20% of users impacted | Partial (user-level) | Remove specific users from staged rollout group |
| >20% of users impacted | Full wave rollback | Remove entire wave from staged rollout |
| Security incident | Full migration rollback | Rollback all waves, pause migration indefinitely |
Testing Rollback Before Production
Rollback Dry Run During Pilot
Practice rollback with pilot group before production waves:
- Day 10 of pilot: Announce planned rollback test
- Execute rollback: Follow procedure, time each step
- Validate: Confirm users can login via Okta
- Re-migrate: Add users back to staged rollout
- Document: Actual time vs expected, refine procedure
Benefit: Team gains confidence, finds gaps in procedure, validates 1-hour rollback window
Post-Rollback: Attempt #2
If you execute a rollback, here's how to prepare for second attempt:
- Root Cause Analysis: Document exact failure, not symptoms
- Fix Duration: Allow 1-2 weeks minimum to resolve issue properly
- Re-test: Validate fix with 5-10 users before full wave retry
- Communication: Be transparent with users about what was fixed
- Confidence Check: If team isn't confident, extend testing period
⚠️ Gotchas, Pitfalls & Lessons Learned
▼
Top 10 Migration Gotchas
1. Azure AD Doesn't Support External IdP with Custom Domains
You CANNOT configure Okta as a federated IdP for custom domains in Entra ID. This breaks certain hybrid scenarios. Workaround: Use Azure AD B2B for external federation, not primary tenant domains.
2. Not All Gallery Apps Support Both SSO and Provisioning
An app may be in the Entra ID gallery for SSO but NOT support SCIM provisioning (or vice versa). Action: Check each app's documentation, plan for manual provisioning where needed.
3. Vendors Take 1-4 Weeks to Update SSO Configs
20-30% of apps require vendor to update SSO on their side. Vendors are slow. Action: Open tickets 6-8 weeks before migration, not during.
4. M365 Mail Routing Can Break
By default, M365 tries to route email internally for registered domains. If you have custom domain in Entra ID AND external email, mail routing breaks. Fix: Configure mail flow connectors properly before migration.
5. Hybrid Join Devices Stay with Okta Until Defederation
Azure AD Hybrid Joined devices will continue authenticating to Okta even after users migrate. Action: Keep Okta sign-on policy for hybrid join until domain fully defederated.
6. Legacy MFA Configurations Cause Conflicts
If you have old per-user MFA enabled in Entra ID AND modern Conditional Access, users get double-prompted. Fix: Disable ALL per-user MFA before migration, use only CA policies.
7. On-Prem AD Cleanup Required
Stale accounts, duplicate UPNs, invalid email addresses in on-prem AD will block cloud sync. Action: Run AD cleanup 4 weeks before migration: remove disabled users, fix UPN conflicts.
8. Group Membership Explosion in Entra ID
Okta group rules don't translate to Entra ID dynamic groups directly. Manual group assignments can explode. Fix: Convert to dynamic groups where possible, document group logic.
9. Mobile Device Management (MDM) Re-enrollment
Devices enrolled via Okta-managed MDM may require re-enrollment when switching to Entra ID. Impact: Users must wipe and re-provision mobile devices. Plan accordingly.
10. Certificate Expiration Tracking
Okta automatically rotates SAML certificates. Entra ID does NOT auto-rotate by default. Action: Set up certificate expiration monitoring (90-day alerts) or enable auto-rollover.
Lessons from Failed Migrations
| Failure Reason | % of Failures | Prevention |
|---|---|---|
| Inadequate testing in pilot | 35% | Extend pilot from 2 weeks to 3-4 weeks, test ALL app categories |
| Underestimated vendor response time | 25% | Open vendor tickets 6-8 weeks early, escalate non-responders |
| Poor user communication | 20% | Multi-channel comms (email, Slack, Teams, townhalls), 3+ weeks notice |
| No rollback plan | 10% | Document and TEST rollback during pilot, practice dry run |
| Legacy auth not addressed | 10% | Identify and disable legacy auth protocols 4 weeks before migration |
Success Factors from Completed Migrations
What Made Migrations Succeed
- Executive Sponsorship: VP-level sponsor who unblocks vendor delays and approves extended timelines
- Dedicated Team: 3-5 people working 50%+ time for 4-6 months (not "squeeze it in" project)
- Weekly Syncs: Status meetings with all stakeholders (IT, Security, Business Unit leaders)
- Robust Testing: 100% of app categories tested in pilot, not just "top 10 apps"
- User Feedback Loop: Survey after each wave, act on feedback before next wave
- Help Desk Prep: 2x staffing for 3 days post-wave, pre-written KB articles
- Timeline Buffer: Plan 20-30% buffer for unexpected delays
🛠️ Scripts & Automation
▼
Essential PowerShell Scripts
1. Bulk User Migration Status Report
# Generate migration status report
Connect-MgGraph -Scopes "User.Read.All", "Group.Read.All"
$stagedGroup = Get-MgGroup -Filter "displayName eq 'Entra-ID-Migrated-Users'"
$migratedUsers = Get-MgGroupMember -GroupId $stagedGroup.Id
$report = @()
foreach ($user in $migratedUsers) {
$userDetail = Get-MgUser -UserId $user.Id -Property DisplayName, UserPrincipalName, `
SignInActivity, LastPasswordChangeDateTime
$report += [PSCustomObject]@{
DisplayName = $userDetail.DisplayName
UPN = $userDetail.UserPrincipalName
LastSignIn = $userDetail.SignInActivity.LastSignInDateTime
MFAStatus = (Get-MgUserAuthenticationMethod -UserId $user.Id).Count -gt 1
MigrationDate = (Get-MgGroupMember -GroupId $stagedGroup.Id `
-Filter "id eq '$($user.Id)'").AdditionalProperties.createdDateTime
}
}
$report | Export-Csv "migration-status-report.csv" -NoTypeInformation
Write-Host "Report generated for $($report.Count) migrated users"
2. App Assignment Comparison (Okta vs Entra ID)
# Compare app assignments between Okta and Entra ID
# Ensures no users lost access during migration
# Get Okta app assignments
$oktaApp = Invoke-RestMethod -Uri "$oktaDomain/api/v1/apps/$oktaAppId" -Headers $oktaHeaders
$oktaUsers = Invoke-RestMethod -Uri "$oktaDomain/api/v1/apps/$oktaAppId/users" -Headers $oktaHeaders
# Get Entra ID app assignments
Connect-MgGraph
$entraApp = Get-MgServicePrincipal -Filter "displayName eq '$appName'"
$entraUsers = Get-MgServicePrincipalAppRoleAssignedTo -ServicePrincipalId $entraApp.Id
# Compare
$oktaUPNs = $oktaUsers | ForEach-Object { $_.profile.login }
$entraUPNs = $entraUsers | ForEach-Object { $_.principalDisplayName }
$missingInEntra = $oktaUPNs | Where-Object { $_ -notin $entraUPNs }
$extraInEntra = $entraUPNs | Where-Object { $_ -notin $oktaUPNs }
Write-Host "Users in Okta but not Entra ID: $($missingInEntra.Count)"
$missingInEntra | Out-File "users-missing-in-entra.txt"
Write-Host "Users in Entra ID but not Okta: $($extraInEntra.Count)"
$extraInEntra | Out-File "users-extra-in-entra.txt"
3. MFA Enrollment Checker
# Check MFA enrollment status for migrated users
Connect-MgGraph -Scopes "UserAuthenticationMethod.Read.All"
$users = Get-MgUser -All | Where-Object { $_.UserPrincipalName -like "*@yourdomain.com" }
$mfaReport = @()
foreach ($user in $users) {
$methods = Get-MgUserAuthenticationMethod -UserId $user.Id
$hasAuthenticator = $methods.AdditionalProperties.'@odata.type' -contains `
'#microsoft.graph.microsoftAuthenticatorAuthenticationMethod'
$hasPhone = $methods.AdditionalProperties.'@odata.type' -contains `
'#microsoft.graph.phoneAuthenticationMethod'
$hasFido = $methods.AdditionalProperties.'@odata.type' -contains `
'#microsoft.graph.fido2AuthenticationMethod'
$mfaReport += [PSCustomObject]@{
UPN = $user.UserPrincipalName
DisplayName = $user.DisplayName
Authenticator = $hasAuthenticator
Phone = $hasPhone
FIDO2 = $hasFido
TotalMethods = $methods.Count
EnrolledDate = $user.CreatedDateTime
}
}
# Export users without MFA
$noMFA = $mfaReport | Where-Object { $_.TotalMethods -eq 1 } # Only password
$noMFA | Export-Csv "users-without-mfa.csv" -NoTypeInformation
Write-Host "Users without MFA: $($noMFA.Count) of $($users.Count)"
4. Certificate Expiration Monitor
# Monitor SAML certificate expiration for all Enterprise Apps
Connect-MgGraph -Scopes "Application.Read.All"
$apps = Get-MgServicePrincipal -Filter "servicePrincipalType eq 'Application'" -All
$certReport = @()
foreach ($app in $apps) {
$samlConfig = Get-MgServicePrincipalSynchronization -ServicePrincipalId $app.Id `
-ErrorAction SilentlyContinue
if ($app.PreferredSingleSignOnMode -eq 'saml') {
$certs = $app.KeyCredentials | Where-Object { $_.Usage -eq 'Verify' }
foreach ($cert in $certs) {
$daysUntilExpiry = ($cert.EndDateTime - (Get-Date)).Days
$certReport += [PSCustomObject]@{
AppName = $app.DisplayName
AppId = $app.Id
CertThumbprint = $cert.CustomKeyIdentifier
ExpiryDate = $cert.EndDateTime
DaysRemaining = $daysUntilExpiry
Status = if ($daysUntilExpiry -lt 30) { "URGENT" }
elseif ($daysUntilExpiry -lt 60) { "WARNING" }
else { "OK" }
}
}
}
}
# Alert on expiring certificates
$expiringSoon = $certReport | Where-Object { $_.DaysRemaining -lt 60 }
$expiringSoon | Export-Csv "expiring-certificates.csv" -NoTypeInformation
Write-Host "Certificates expiring in <60 days: $($expiringSoon.Count)"
Automation Opportunities
Save 100+ Hours with Automation
- User Provisioning: Use Microsoft Graph API to bulk-create users (saves 20-30 hours)
- Group Migration: Script group creation and membership (saves 40-50 hours)
- App Configuration: Terraform/PowerShell for app registration (saves 30-40 hours)
- Monitoring: Automated daily reports on migration status (saves 10-15 hours)
Final Recommendations
Okta to Entra ID migration is achievable with zero downtime if you follow a disciplined, phased approach with robust rollback procedures.
Key success factors: Thorough planning (4-5 weeks), comprehensive pilot testing (3-4 weeks), phased production rollout (10-14 weeks), and keeping Okta active as backup until 100% validated.
For 15,000 users with 150+ applications, expect 16-24 weeks total duration with a dedicated 3-5 person team.
Cost savings: $540K-$1.08M annually by eliminating redundant Okta licensing, plus reduced operational overhead.
Migration Checklist Summary
- ✅ Document current Okta environment (apps, users, groups, policies)
- ✅ Design Entra ID architecture (provisioning method, CA policies)
- ✅ Create migration wave plan (pilot + 4-5 production waves)
- ✅ Build communication plan (4 weeks notice, user guides)
- ✅ Test rollback procedure during pilot
- ✅ Open vendor tickets 6-8 weeks before migration
- ✅ Prepare help desk (2x staffing, KB articles)
- ✅ Execute pilot with 100-300 users for 3-4 weeks
- ✅ Roll out production waves with 1-week gaps
- ✅ Keep Okta active for 90 days post-migration