Source to target
What moves, what is translated, and what has to be rebuilt
The fastest way to lose a migration plan is to assume every object has a destination. This map sets out the typical treatment for each category so the exceptions are visible before a wave is planned.
How do Okta and Ping objects map to Entra ID?
Users, groups, and standards-based applications have direct destinations in Microsoft Entra ID. Claims, sign-on policies, and provisioning are translated by intent rather than copied. Custom flows, agent-based enforcement, and header-based applications have no direct equivalent and are redesigned or rebuilt. Treatment for your estate is confirmed during the migration assessment.
Category 01
Identity data
| Source object | Microsoft Entra ID destination | Treatment |
|---|---|---|
| Users | Entra ID user objects | Moved or matched to existing objects |
| User attributes and profiles | Directory attributes and extension attributes | Mapped |
| Groups | Security groups and Microsoft 365 groups | Moved or mapped |
| Rule-based or dynamic groups | Dynamic membership rules | Translated, rule syntax differs |
| Nested group structures | Group nesting in Entra ID | Mapped, behaviour differs per application |
| Directory sources | Entra ID with Entra Connect or cloud sync | Redesigned in target |
Category 02
Applications and protocols
| Source object | Microsoft Entra ID destination | Treatment |
|---|---|---|
| SAML applications | Enterprise applications with SAML SSO | Mapped, then validated per application |
| OIDC and OAuth clients | App registrations and enterprise applications | Re-registered with new identifiers |
| Gallery or catalog applications | Entra ID application gallery entries | Configured again in the target |
| Custom claims and attribute contracts | Claims mapping on the target application | Target design required |
| Signing certificates and metadata | Entra ID issued certificates and metadata | Replaced, vendor coordination needed |
| Bookmark or password-based apps | Entra ID equivalents where applicable | Reviewed case by case |
Category 03
Access and policy
| Source object | Microsoft Entra ID destination | Treatment |
|---|---|---|
| Application assignments | User and group assignment on enterprise apps | Mapped |
| Sign-on or authentication policies | Conditional Access policies | Translated by intent, no one to one |
| MFA and authentication methods | Entra ID authentication methods policy | Redesigned in target |
| Network or location rules | Named locations in Conditional Access | Translated |
| Session and device rules | Conditional Access session controls | Translated where an equivalent exists |
| Administrative roles | Entra ID roles and role assignments | Redesigned in target |
Category 04
Provisioning and lifecycle
| Source object | Microsoft Entra ID destination | Treatment |
|---|---|---|
| SCIM provisioning connections | Entra ID application provisioning | Rebuilt in the target |
| Directory synchronization | Entra Connect or Entra Cloud Sync | Redesigned in target |
| Joiner, mover, leaver automation | Entra ID lifecycle capabilities and workflows | Redesigned in target |
| Provisioning attribute mappings | Entra ID provisioning attribute mappings | Translated and re-tested |
| Deprovisioning behaviour | Entra ID provisioning deprovisioning settings | Target design required |
Category 05
Custom and legacy
These are the items that decide the length of a migration, so they are named early rather than discovered late.
| Source object | Microsoft Entra ID destination | Treatment |
|---|---|---|
| Custom sign-in and hosted pages | Entra ID company branding | Rebuilt within target capability |
| Custom flows, hooks, or DaVinci logic | External logic or target-native equivalents | Rebuilt, environment dependent |
| Agent or header-based enforcement | Application-specific target architecture | Environment dependent |
| Legacy protocol applications | Application proxy or modernization | Case by case decision |
| Scripts and API integrations | Microsoft Graph based integrations | Rebuilt or retired |
| Reporting and log pipelines | Entra ID logs and diagnostic settings | Redesigned in target |
Path-specific detail is on the Okta page and the Ping Identity page.
Migration map questions
Does everything in Okta or Ping have an equivalent in Microsoft Entra ID?
No. Users, groups, and standards-based applications have clear destinations. Policies, custom flows, and legacy access enforcement do not map one to one and need target design instead of translation.
What does treatment mean on this page?
Treatment is what happens to an object category during migration: moved, mapped, re-registered, redesigned in the target, or rebuilt. Treatment for your estate is confirmed during the assessment.
Is this a supported product matrix?
No. This is typical treatment for planning purposes. Actual support and scope depend on your source architecture, protocols, and permissions, and are confirmed during the migration assessment.
Official sources
- Microsoft Learn: Migrate applications from Okta to Microsoft Entra ID
- Microsoft Learn: Migrate Okta sign-on policies to Microsoft Entra Conditional Access
- Microsoft Learn: Migrate Okta sync provisioning to Microsoft Entra Connect
- Microsoft Learn: Migrate application authentication, phases and planning overview
- Ping Identity docs: Introduction to PingFederate
Turn this map into your plan
An assessment applies each treatment to your real inventory, names the exceptions, and sequences the waves.