Best Practices: Okta to Entra ID Migration¶

Status: Authored 2026-04-30 Audience: Identity Architects, Project Managers, IT Directors Purpose: Proven practices for successful Okta-to-Entra ID migration based on enterprise and federal implementations

Overview¶

This document captures best practices for planning and executing an Okta-to-Entra ID migration. These practices are drawn from Microsoft's published migration guidance, enterprise migration patterns, and federal identity consolidation projects. Following these practices reduces risk, minimizes user disruption, and accelerates time to value.

1. Migration planning best practices¶

Align with Okta contract timeline¶

• Start planning 12-18 months before Okta contract renewal. This provides adequate time for discovery, migration execution, and validation before the renewal decision date.
• Issue non-renewal notice early. Most Okta contracts include 30-90 day non-renewal notice requirements. Missing the notice window triggers auto-renewal (typically 1-3 years).
• Negotiate short-term extensions if needed. If migration will extend past the renewal date, negotiate a 6-month or month-to-month extension rather than a multi-year renewal.
• Budget for overlap. Plan for 3-6 months of dual-IdP operation (paying for both Okta and using Entra ID) during the transition period.

Build the migration team¶

Create a migration playbook¶

Before executing, document:

• Complete Okta application inventory with protocol, provisioning, and user count
• Per-application migration plan (wave assignment, owner, testing criteria)
• MFA enrollment strategy and timeline
• Conditional Access policy mapping (Okta sign-on policy -> Entra CA policy)
• Federation cutover plan with rollback procedures
• User communication templates (email, intranet, FAQs)
• Help desk escalation procedures
• Success criteria and go/no-go decision matrix

2. Application migration order¶

Recommended wave sequence¶

The order of application migration matters. Migrate in this sequence to minimize risk and build confidence:

Migration anti-patterns¶

• DO NOT migrate all applications at once ("big bang"). This maximizes risk and makes troubleshooting impossible.
• DO NOT migrate provisioning before SSO. SSO must be stable before provisioning connectors are switched.
• DO NOT migrate MFA before applications. Users need applications working before MFA is enforced.
• DO NOT cut federation before all applications are migrated. Federation cutover is the final step.

3. MFA re-enrollment communication¶

Communication timeline¶

Key messages for users¶

1. Why: "We are consolidating to one sign-in system to improve security and simplify your experience."
2. What changes: "You will use Microsoft Authenticator instead of Okta Verify for sign-in verification."
3. When: "Complete enrollment by [date]. After this date, Okta Verify will no longer work."
4. How: "Install Microsoft Authenticator, then visit https://aka.ms/mysecurityinfo to set up."
5. Help: "Contact IT help desk at [number/email] for assistance."

MFA enrollment success targets¶

4. Rollback planning¶

Rollback requirements¶

Every migration phase should have a documented rollback procedure. For the Okta-to-Entra ID migration, the critical rollback scenarios are:

Rollback prerequisites (maintain throughout migration)¶

• Okta tenant remains active until 90 days post-federation cutover
• Okta signing certificate is not expired
• Okta application configurations are not deleted (deactivated only)
• Federation configuration backup saved (okta-federation-backup.json)
• Rollback runbook reviewed and tested in non-production environment
• Rollback team contacts documented and available 24/7 during cutover

5. CSA-in-a-Box RBAC integration¶

Design Entra groups for CSA-in-a-Box platform access¶

When migrating from Okta groups to Entra groups, design the group structure to align with CSA-in-a-Box platform roles:

CSA-in-a-Box RBAC Group Structure:

    csa-platform-admins          -> Platform administrators (Fabric, ADF, Purview)
    csa-data-engineers           -> Data engineers (Fabric, Databricks, ADF)
    csa-data-analysts            -> Data analysts (Fabric, Power BI, SQL)
    csa-data-scientists          -> Data scientists (Databricks, Azure AI, Fabric)
    csa-governance-admins        -> Governance administrators (Purview, compliance)
    csa-security-admins          -> Security administrators (Sentinel, Defender)

    Per-workspace groups:
    csa-ws-{domain}-contributors -> Workspace contributors for specific domains
    csa-ws-{domain}-viewers      -> Workspace viewers for specific domains

    Per-environment groups:
    csa-env-dev                  -> Development environment access
    csa-env-staging              -> Staging environment access
    csa-env-production           -> Production environment access

# Create CSA-in-a-Box platform groups
$csaGroups = @(
    @{ Name = "csa-platform-admins"; Desc = "CSA-in-a-Box platform administrators" },
    @{ Name = "csa-data-engineers"; Desc = "CSA-in-a-Box data engineers" },
    @{ Name = "csa-data-analysts"; Desc = "CSA-in-a-Box data analysts" },
    @{ Name = "csa-data-scientists"; Desc = "CSA-in-a-Box data scientists" },
    @{ Name = "csa-governance-admins"; Desc = "CSA-in-a-Box governance administrators" },
    @{ Name = "csa-security-admins"; Desc = "CSA-in-a-Box security administrators" }
)

foreach ($group in $csaGroups) {
    New-MgGroup -DisplayName $group.Name `
                -Description $group.Desc `
                -MailEnabled:$false `
                -MailNickname ($group.Name -replace "-", "") `
                -SecurityEnabled:$true
    Write-Host "Created: $($group.Name)"
}

Map Okta groups to CSA-in-a-Box Entra groups¶

6. Identity governance consolidation¶

Deploy Entra ID Governance alongside migration¶

The migration is an opportunity to deploy identity governance capabilities that may not have been available in your Okta deployment:

Access reviews¶

# Create recurring access review for CSA-in-a-Box platform groups
$accessReview = @{
    displayName = "CSA-in-a-Box Platform Access Review"
    descriptionForAdmins = "Quarterly review of CSA-in-a-Box platform group memberships"
    scope = @{
        query = "/groups?$filter=startswith(displayName, 'csa-')"
        queryType = "MicrosoftGraph"
    }
    reviewers = @(
        @{
            query = "./manager"
            queryType = "MicrosoftGraph"
        }
    )
    settings = @{
        mailNotificationsEnabled = $true
        reminderNotificationsEnabled = $true
        justificationRequiredOnApproval = $true
        defaultDecisionEnabled = $true
        defaultDecision = "Deny"
        instanceDurationInDays = 14
        autoApplyDecisionsEnabled = $true
        recommendationsEnabled = $true
        recurrence = @{
            pattern = @{ type = "absoluteMonthly"; interval = 3 }
            range = @{ type = "noEnd"; startDate = "2026-07-01" }
        }
    }
}

Privileged Identity Management (PIM)¶

# Configure PIM for CSA-in-a-Box admin roles
# Enable just-in-time activation for platform admin group
# This replaces any Okta Privileged Access configurations

Write-Host "Configure PIM via Entra admin center:"
Write-Host "  1. Navigate to Identity Governance > Privileged Identity Management"
Write-Host "  2. Select 'Groups' under 'Manage'"
Write-Host "  3. Add 'csa-platform-admins' group"
Write-Host "  4. Configure activation settings:"
Write-Host "     - Maximum activation duration: 8 hours"
Write-Host "     - Require justification: Yes"
Write-Host "     - Require approval: Yes (for production)"
Write-Host "     - Require MFA: Yes (phishing-resistant)"

7. Testing and validation¶

Pre-migration testing checklist¶

• SSO tested for each application with at least 3 users
• MFA tested for each authentication method (Authenticator push, FIDO2, passwordless)
• Conditional Access policies validated in report-only mode for 14+ days
• Provisioning tested for each SCIM connector (create, update, deactivate)
• Self-service password reset tested
• Emergency access (break-glass) accounts validated
• Rollback procedures tested in non-production environment

Post-migration monitoring (first 30 days)¶

# Daily monitoring script (run first 30 days post-migration)
$yesterday = (Get-Date).AddDays(-1).ToString("yyyy-MM-ddT00:00:00Z")

# Authentication failures
$failures = Get-MgAuditLogSignIn -Filter "createdDateTime ge $yesterday and status/errorCode ne 0" -All
$total = (Get-MgAuditLogSignIn -Filter "createdDateTime ge $yesterday" -All).Count
$failureRate = [math]::Round($failures.Count / $total * 100, 2)

Write-Host "=== Daily Migration Health Report ==="
Write-Host "Date: $(Get-Date -Format 'yyyy-MM-dd')"
Write-Host "Total sign-ins: $total"
Write-Host "Failures: $($failures.Count) ($failureRate%)"

if ($failureRate -gt 1) {
    Write-Host "WARNING: Failure rate exceeds 1% threshold" -ForegroundColor Red

    # Top failure reasons
    $failures | Group-Object { $_.Status.ErrorCode } | Sort-Object Count -Descending | Select-Object -First 5 | ForEach-Object {
        $errorCode = $_.Name
        $count = $_.Count
        $reason = ($_.Group | Select-Object -First 1).Status.FailureReason
        Write-Host "  Error $errorCode ($count occurrences): $reason"
    }
}

# MFA registration status
$unregistered = Get-MgReportAuthenticationMethodUserRegistrationDetail -Filter "isMfaRegistered eq false" -All
Write-Host "Users without MFA: $($unregistered.Count)"

# Provisioning health
$provisioningIssues = Get-MgAuditLogProvisioning -Filter "createdDateTime ge $yesterday and provisioningStatusInfo/status ne 'success'" -Top 100
Write-Host "Provisioning issues: $($provisioningIssues.Count)"

8. Post-migration optimization¶

After migration is stable (30-90 days post-cutover):

1. Enable Security Copilot integration -- Leverage AI-assisted identity investigation and policy recommendations
2. Deploy authentication context -- Add step-up MFA for sensitive actions within CSA-in-a-Box applications
3. Enable Continuous Access Evaluation (CAE) -- Near-real-time policy enforcement for supported applications
4. Implement token protection -- Prevent token theft and replay attacks
5. Review Secure Score -- Address identity security recommendations
6. Archive Okta audit logs -- Export Okta System Log for compliance retention requirements before decommissioning tenant
7. Decommission Okta tenant -- After 90-day validation period, cancel Okta subscription

9. Lessons learned (common pitfalls)¶

Key Microsoft Learn references¶

• Migrate applications from Okta to Entra ID
• Conditional Access best practices
• Entra ID deployment checklist
• Access reviews
• Privileged Identity Management
• Microsoft FastTrack

Maintainers: csa-inabox core team Last updated: 2026-04-30