Skip to main content

Source to target

Map what moves, changes, and must 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.

PhaseArc workspace / Migration map

Northstar Identity Consolidation

Okta Workforce + PingFederate to Microsoft Entra ID (northstar.onmicrosoft.com)

Wave 3 of 6Connections healthy

Access

  • SourceSalesforce SAML application and claims contractTranslation decisionTransformMicrosoft Entra IDEnterprise application with mapped claims
  • SourceGroup assignment paths for finance applicationsTranslation decisionDirectMicrosoft Entra IDSecurity group assignment on enterprise apps

Provisioning

  • SourceWorkday outbound SCIM connectionTranslation decisionRebuildMicrosoft Entra IDEntra ID application provisioning

Policies

  • SourceOkta sign-on policy for privileged accessTranslation decisionRebuildMicrosoft Entra IDConditional Access policy set
The PhaseArc Migration Map connects source objects on the left, the recorded translation decision in the middle, and the Microsoft Entra ID target on the right. This view shows a working subset of mappings. The tables below carry the source to target detail in full.

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

Identity object treatment. Typical planning guidance, confirmed during assessment.
Source objectMicrosoft Entra ID destinationTreatment
UsersEntra ID user objectsMoved or matched to existing objects
User attributes and profilesDirectory attributes and extension attributesMapped
GroupsSecurity groups and Microsoft 365 groupsMoved or mapped
Rule-based or dynamic groupsDynamic membership rulesTranslated, rule syntax differs
Nested group structuresGroup nesting in Entra IDMapped, behaviour differs per application
Directory sourcesEntra ID with Entra Connect or cloud syncRedesigned in target

Category 02

Applications and protocols

Application treatment by protocol.
Source objectMicrosoft Entra ID destinationTreatment
SAML applicationsEnterprise applications with SAML SSOMapped, then validated per application
OIDC and OAuth clientsApp registrations and enterprise applicationsRe-registered with new identifiers
Gallery or catalog applicationsEntra ID application gallery entriesConfigured again in the target
Custom claims and attribute contractsClaims mapping on the target applicationTarget design required
Signing certificates and metadataEntra ID issued certificates and metadataReplaced, vendor coordination needed
Bookmark or password-based appsEntra ID equivalents where applicableReviewed case by case

Category 03

Access and policy

Access and policy treatment. Policies are translated by intent, not copied.
Source objectMicrosoft Entra ID destinationTreatment
Application assignmentsUser and group assignment on enterprise appsMapped
Sign-on or authentication policiesConditional Access policiesTranslated by intent, no one to one
MFA and authentication methodsEntra ID authentication methods policyRedesigned in target
Network or location rulesNamed locations in Conditional AccessTranslated
Session and device rulesConditional Access session controlsTranslated where an equivalent exists
Administrative rolesEntra ID roles and role assignmentsRedesigned in target

Category 04

Provisioning and lifecycle

Provisioning treatment. Connections are replaced rather than moved.
Source objectMicrosoft Entra ID destinationTreatment
SCIM provisioning connectionsEntra ID application provisioningRebuilt in the target
Directory synchronizationEntra Connect or Entra Cloud SyncRedesigned in target
Joiner, mover, leaver automationEntra ID lifecycle capabilities and workflowsRedesigned in target
Provisioning attribute mappingsEntra ID provisioning attribute mappingsTranslated and re-tested
Deprovisioning behaviourEntra ID provisioning deprovisioning settingsTarget 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.

Custom and legacy treatment.
Source objectMicrosoft Entra ID destinationTreatment
Custom sign-in and hosted pagesEntra ID company brandingRebuilt within target capability
Custom flows, hooks, or DaVinci logicExternal logic or target-native equivalentsRebuilt, environment dependent
Agent or header-based enforcementApplication-specific target architectureEnvironment dependent
Legacy protocol applicationsApplication proxy or modernizationCase by case decision
Scripts and API integrationsMicrosoft Graph based integrationsRebuilt or retired
Reporting and log pipelinesEntra ID logs and diagnostic settingsRedesigned 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.

Turn this map into your plan

An assessment applies each treatment to your real inventory, names the exceptions, and sequences the waves.