Okta → PingOne

Migrate SSO applications from Okta to PingOne in hours, not months.

TenantFlex reads every SAML and OIDC application in your Okta org, maps its claims to PingOne's own form, and recreates it in the PingOne environment with an execution log and a hand-off bundle for each owner. The Okta side is read-only throughout.

Request a demo Migration checklist
Microsoft Entra IDOktaPingOneadditional IdPs on request
Okta → PingOne · in production
What moves

SAML 2.0 and OIDC applications, recreated as SAML and OIDC applications.

SAML

Entity ID, reply and sign-on URLs, NameID format and the attribute statements. A new signing certificate is generated on the PingOne side; the application owner installs it at cutover.

OIDC and OAuth

Redirect URIs, grant types, scopes and API permissions. Client secrets are generated on the PingOne side and handed to the owner once, never copied.

Reported, not moved

User and group assignments, conditional access or sign-on policies, and SCIM provisioning are read and shown in discovery so the owner can recreate them deliberately. SCIM migration is on the roadmap.

How it works

Discover, review, migrate.

Discover

Connect an identity provider tenant in read-only. TenantFlex inventories its SAML and OAuth/OIDC applications, service principals, credentials and their expiry. You see what is really there, not what the CMDB says.

Review

Approve what is in scope, set naming and credential handling, and get suggestions for complex claims transformations. Nothing migrates until it is approved.

Migrate and hand off

Each application is recreated in the target tenant, read back and compared with the source, then handed to its owner for cutover. If an application fails, the job deletes what it created in the destination and leaves the source unchanged.

Okta to PingOne, step by step

Connect the Okta org as the source and the PingOne environment as the destination. The Okta connection only needs okta.apps.read. The PingOne worker application needs the Configuration Read Only role, plus the Client Application Developer role to create applications.

Discovery reads each SAML application's sign-on configuration and attribute statements. The migration job creates a SAML application in PingOne with the same audience and assertion consumer service URL, and attribute mappings translated from the Okta attribute statements. The application owner switches the service provider to the PingOne metadata at cutover.

Claims

Okta writes ${user.email}. PingOne expects email (attribute mapping).

Each provider's claims are translated to one shared vocabulary, the central TenantFlex profile vocabulary, and written back in the destination's own format. Claims that map to a standard user attribute migrate automatically. Claims that use transformations, expressions or attributes the destination does not have are reported as complex in discovery, so they are reviewed before anything moves. Custom claims can be mapped to destination claims for a whole job or for a single application.

At cutover

TenantFlex provides a hand-off bundle per migrated application. For a SAML application: the identity provider login URL, the identity provider identifier and the signing certificate, all of which are in the destination's federation metadata. For an OIDC application: the client ID, the client secret and the issuer URL. Until the owner makes the change, users keep signing in through the source tenant, so each application can be cut over on its own schedule, aligned with your change management processes and maintenance windows.

How long it takes

Recreating an application in the destination takes minutes. Most of the elapsed time in a tenant migration is cutover coordination with application owners, so a plan is usually built back from a date: discovery about three months ahead, a pilot wave, then the remaining waves as scheduled jobs.

Same provider on both sides?

Yes. The destination can be any connected tenant, including one at the same provider: Entra ID to Entra ID after an acquisition, or Okta org to Okta org when two business units consolidate. The naming template keeps the migrated applications distinguishable from the originals.

Checklist

Okta to PingOne migration checklist

Nine steps, in order, for moving SSO applications from an Okta org to a PingOne environment. The first three need only a read permission on Okta.

Before you start

  1. Get the read permission on Okta. okta.apps.read on the org you are leaving, with an administrator role that can read applications; okta.appGrants.read adds an OAuth app's API permissions. Nothing is written there, now or later.
  2. Run discovery and fix the count. Every SAML 2.0 and OIDC application with its claims, owners and credential expiry, and when it was last used if the sign-in permission was granted. Retire what nobody signs in to.
  3. Sort the bands into waves. Straightforward apps go first. For the ones marked needs review, compare their attribute statements and expressions with PingOne attribute mappings before anything moves.

During the run

  1. Create the write connection on PingOne. The client application developer role on the destination environment. Every setting is read back after it is written and compared with the source.
  2. Pilot one wave. A handful of apps with willing owners, created under a naming template so the originals stay distinguishable. Roll back any that fail; the source is untouched either way.
  3. Check the mapped attributes. Claims arrive as PingOne attribute mappings; the ones discovery banded as needs review are worth a look before the wave runs.

At cutover

  1. Repoint each SAML app. The owner installs the PingOne login URL, identifier and signing certificate from the hand-off bundle. Users keep signing in through Okta until that moment, so each app moves on its own date.
  2. Repoint each OIDC app. New client ID, a client secret handed over once, and the PingOne issuer URL. PingOne issues the new secret; nothing secret is copied from the source.
  3. Recreate what is reported, not moved. User and group assignments, sign-on policies and SCIM provisioning are in the discovery report for the owner to set up on PingOne. Then retire the Okta app once its sign-ins have moved.

The same list applies to a pilot of five applications and to a tenant of five hundred; only the number of waves changes. Discovery sizes it before you commit to anything: see what a discovery report contains and the permissions reference.

Permissions for this pair

Read-only on Okta. Write only on PingOne.

Okta · source

Read applicationsokta.apps.read

Lists applications with their sign-on mode, SAML and OIDC configuration, assignments and signing certificates. The API client also needs an administrator role that can read applications.

  • Optionalokta.appGrants.read

    Only so an OAuth application's API permissions are read rather than reported as unknown.

  • Never needed on the source

    No write permission is asked for on the org you are leaving.

PingOne · destination

Create applicationsClient Application Developer

Creates applications and writes their configuration.

  • Read back after each write

    Every setting is read back from PingOne and compared with the source. A failed application is rolled back.

Other pairsEntra ID → OktaEntra ID → PingOneOkta → Entra IDOkta → PingOnePingOne → Entra IDPingOne → Okta
Pricing

Pay for the applications you move, or hand the whole thing to us.

Licensed per application in scope. Discovery tells you the number before you commit.

Two ways to engage.Take the platform, or take the platform and the people.

Licensed per application

You license the platform by the applications in scope, not by user count or tenant size. Discovery tells you that number before you commit. SaaS or deployed in your own environment, the same release either way.

Self-service

White-glove migration

We run it with you: scoping, the claim and policy decisions that need a human, a cutover plan per application, and the hand-off to each application owner. You get the platform and the practitioners who have done these migrations by hand.

With consultancy
TenantFlex Get started

Bring your Okta to PingOne migration to TenantFlex.

Tell us roughly how many applications are in the org and what is driving the move. We will walk you through a live migration, read-only on Okta throughout.

team@tenantflex.com · www.tenantflex.com
Tell us about your migrationWe reply within one business day.

Goes straight to team@tenantflex.com. If the form can't reach us, it opens your email app with the request prefilled instead.

Click image to zoom · ← → to browse · Esc to close