Migrate from Ping Identity to ZITADEL

Claims enrichment adds roles, entitlements, tenant identifiers or account tiers to the tokens that applications receive. In Ping deployments this logic often sits in attribute contracts, OAuth access token mappings or custom code attached to an adapter. ZITADEL structures access around projects, roles and grants inside organizations, so some claims may be expressed through those built-in features before any custom action is written.

• Inventory each added claim: List every attribute an application reads, its source (directory, profile field or calculated value) and the application that consumes it.
• Prefer native roles and grants where they fit: Role-based claims tied to projects and organizations may need no custom code. Confirm the exact claim names ZITADEL emits against what each application parses.
• Rebuild calculated claims: Logic that derives values from several sources must be re-expressed in the action runtime and tested with fixed inputs. Line-by-line translation of the Ping logic is rarely reliable.
• Agree the claim contract first: Renaming or retyping a claim breaks every relying party, so settle names, types and multi-valued formats with application owners before cutover.

Compare token contents for each application in a staging instance against captured production tokens, including the tenant claims for users who belong to more than one organization.

Registration and progressive profiling steps collect consent, company details or extra attributes after a user signs up. These flows often hold business rules such as domain checks, duplicate detection and mandatory terms acceptance. In ZITADEL the first question is which organization a new user joins and who approves that join, because organizations hold users and projects.

• Map each step to a lifecycle event: Decide which steps belong at sign-up, at first login or later in the profile, and confirm which trigger points ZITADEL actions support in your version.
• Make self-registration a business decision: Choose whether anyone can create an account, whether domain-based joins are allowed and who may invite users into an organization.
• Rebuild validation logic and test it: Field checks and lookups need fresh tests with invalid inputs, since error messages and step ordering will differ from the Ping journey.
• Keep consent records under your control: Store consent timestamps and document versions in a system you operate, and confirm how ZITADEL exposes or lets you export them.
• Drop steps that duplicate hosted screens: If the ZITADEL login pages already collect an attribute, remove the second copy of that step so users are not asked twice.

Test the full registration path for each organization type, covering invitation, validation failure and abandoned sign-up, and confirm that each path ends in the expected organization with the expected roles.

Step-up and policy checks decide when to request stronger authentication or block a sign-in based on risk, device, location or account state. Ping deployments may implement these through policy branches or adapter logic. ZITADEL supports passkeys based on FIDO2 and WebAuthn with fallback to password login, which shapes how step-up should be designed. The security decision belongs to the policy owner, so write the policy before rewriting any code.

• Write each condition as a rule: Turn every trigger, such as a risk signal, sensitive action, role or device trust state, into a documented rule with a named owner.
• Confirm the available context: Verify which login context ZITADEL passes to an action and which risk data must come from an external service you call.
• Set passkey and fallback rules: Decide when passkeys are required, when password fallback is acceptable and how recovery works for users who have no passkey enrolled.
• Get risk tolerance signed off: Lockout thresholds, step-up scope and handling of unfamiliar locations need approval from security and customer-facing teams.
• Test each branch against original behavior: Do not assume a Ping policy step maps one-to-one to a ZITADEL construct. Verify each branch against its recorded result in the current system.

Run a test matrix covering normal sign-in, step-up trigger, denial and fallback paths, and record the expected outcome for each case before go-live.

Custom journeys often call CRM, fraud, KYC, consent or entitlement services over HTTP during sign-in. Each call adds latency, a failure mode and a credential that moves into a new runtime. ZITADEL provides APIs and supports SCIM v2 for provisioning, but any call from a login flow to your own services needs timeouts, retries and secret handling designed for the new platform, not carried over unchanged.

• Classify each call: Separate read-only lookups from writes. Writes made during sign-in need idempotency and clear rules for partial failure.
• Define failure behavior per dependency: Decide whether a timeout blocks sign-in, allows it with logging or falls back to a cached value. These are business decisions for each service.
• Move credentials into a managed secret store: Keys for external services should sit in a secret store you operate, with a documented rotation process.
• Reduce synchronous calls where possible: Sync reference data through SCIM v2 or the APIs introduction so logins do not depend on every external service being available.
• Monitor login time and call errors: Set alerts on sign-in latency and external call failures so a degraded dependency is visible to operations staff.

Confirm the availability target and the owner for each external dependency in writing before cutover, and rehearse a dependency outage in a non-production environment.

A small deployment usually has a handful of applications, one user population and a single administrative team. The move is mostly about getting a clean inventory, standing up one ZITADEL instance and re-registering each application as an OIDC or SAML client. Because ZITADEL's instance is the isolation boundary, a single organization inside one instance is often enough, and the projects inside it group applications, roles and grants.

• Inventory first: list every client, redirect URI, scope and signing certificate, and mark the ones nobody has used in months.
• Pilot choice: move one low-risk internal application first, ideally one that already uses standard OIDC.
• Cutover pattern: switch applications in small batches during a planned window, keeping the Ping connection available until each app has logged in successfully.
• User import: confirm with Ping how passwords are stored, since hashes may not be exportable and users may need a reset path.
• Operations: a single PostgreSQL database and one set of backups keeps day-two work light.

Confirm with your team whether any application depends on a Ping-specific adapter or attribute contract before you commit to a date.

A business customer platform serves many organizations, and each one may bring its own identity provider, user list and login policy. Here the design work centers on ZITADEL's model of instances, organizations and projects, so that each customer's users, roles and federated providers stay isolated. Migration becomes a per-tenant exercise rather than one big switch, and the order in which tenants move matters as much as the technical steps.

• Tenant mapping: decide which Ping environments, realms or connections map to an organization, and which need separate instances for full data isolation.
• Pilot choice: pick a friendly customer whose identity provider is already OIDC or SAML, and whose admins will give quick feedback.
• Federation: ZITADEL lets each organization use a different identity provider, so customers can keep their own Entra ID or Okta connection during the move.
• Cutover pattern: move tenants in waves, using just-in-time migration or a managed import where the source supports it, and keep old and new logins running side by side.
• Actions: rebuild custom journeys as ZITADEL actions only after the basic login path works for each wave.

Ask your team which tenants depend on custom Ping journeys, because those drive most of the rework.

In a regulated environment, the move must leave behind an evidence trail that shows who changed what, when, and how access was tested. The technical steps stay similar, but scope grows to include change records, access reviews, key handling and test results. DeployOpen prepares systems, controls and evidence for compliance assessments, while independent auditors decide whether those controls meet a given standard.

• Evidence plan: agree with your assessor which records (configuration exports, change tickets, test logs, access approvals) will be kept for each wave.
• Pilot choice: choose a low-impact application whose login results can be tested against documented criteria.
• Parallel running: keep Ping active for the regulated applications until controls are verified, and document the decision to retire each one.
• Key and certificate handling: plan how signing keys and certificates are moved or reissued, since the Ping configuration archive contains private keys that need protected handling.
• Licensing: check ZITADEL's AGPL-3.0 terms and whether your organization needs the Enterprise plan or any support contract, and confirm these with your legal and procurement teams.

Confirm with your auditor which evidence format they accept before the first wave begins.