Guide
Ping Identity to Microsoft Entra ID Migration Guide
Ping Identity is a product family, not one system. This guide starts where a Ping migration plan has to start: establishing what you are actually running.
Ping Identity to Microsoft Entra ID · Published and last reviewed July 27, 2026 by PhaseArc.
How do you migrate from Ping Identity to Microsoft Entra ID?
Identify whether the source is PingOne, PingFederate, or both. Inventory application connections, users and groups, and attribute contracts. Design the target claims and Conditional Access to match policy intent. Rebuild provisioning. Then move connections in approved waves, validating each wave before cutover is accepted.
Step 1
Identify the architecture
| Question | Why it changes the plan |
|---|---|
| Is PingOne in use? | Configuration and inventory come from the cloud environment and its APIs. |
| Is PingFederate in use? | Configuration lives in server config, with adapters, data stores, and connections to inventory. |
| Are both in use? | Two inventories, two migration patterns, and an ordering decision between them. |
| Which other components appear? | PingAccess, PingID, or DaVinci add dependencies that need an owner and a target decision. |
| Where are the directories? | Directory sources behind Ping determine how users and groups reach Entra ID. |
Step 2
Inventory connections and access
- Service provider connections and client applications, with owners and vendor contacts.
- Endpoints, metadata, and signing certificates for each connection.
- Users, populations or groups, and how access is actually granted.
- Data stores, adapters, and token processors in the authentication path.
- Outbound provisioning connections and synchronization jobs.
- Scripts and API clients built against Ping administrative interfaces.
Step 3
Attributes and claims are design work
Every attribute contract is a promise to an application. In the target, Microsoft Entra ID has to issue the same information under a name and format the application accepts. Record the expected claim names, formats, and sources per application, and confirm them with the application owner before the wave runs.
Step 4
Flows and policies translate by intent
Authentication policies and flow logic do not convert one to one into Conditional Access. Capture what each policy is protecting and under what conditions, express that in Conditional Access and Entra authentication methods, then validate the resulting behaviour application by application.
Step 5
Legacy enforcement needs its own plan
- Header-based and agent-protected applications rely on an enforcement model Entra ID does not reproduce directly.
- Each such application needs a target architecture decision: modernize, front with a proxy pattern, or retire.
- These decisions are made early because they set the outer limit on the migration timeline.
- Applications with hard-coded issuers or embedded certificates are treated as named exceptions.
Step 6
Waves, validation, and cutover
- Group connections into waves by owner, risk, and business calendar.
- Keep the Ping environment serving anything not yet cut over.
- Validate sign-in, claims, assignments, and provisioning for each connection.
- Record an explicit accept, remediate, or fall back decision per wave.
- Plan decommission only once every dependency has a confirmed replacement.
Category by category treatment is in the migration map.
Ping migration questions
Why does the Ping starting point matter so much?
How do PingFederate connections map to Entra ID?
What happens to attribute contracts?
Can PingFederate stay in place during the move?
Establish your Ping starting point
The assessment confirms which Ping components are in play and inventories the connections and attributes behind them.