How it works

Discover, review, migrate. Then verify.

Connect to a tenant in read-only and let TenantFlex inventory what is really integrated. Approve what migrates. Each application is recreated in the target, read back, compared with the source and handed to its owner.

Request a demo

Microsoft Entra IDOktaPingOneadditional IdPs on request

Source tenant → TenantFlex → destination tenant

The workflow

The same three steps for every pair of providers.

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 one fails, the job rolls back what it created.

Verified, then handed offEvery setting is read back from the destination and compared with the source. A claim without a clean match is mapped and flagged, then each owner receives a hand-off bundle. The source tenant is read-only throughout.

Discovery, read-onlyThe first step reads the tenant and bands every application. The counters are the point: how many were found, how many need a human, and that nothing was changed.

One bundle per ownerWhen an application is verified, its settings, execution log, certificate and notes are packed into a hand-off bundle for the owner, so repointing needs no call with the migration team.

Claims

Claims mapped through one vocabulary.

Each provider writes the same claim in its own form: ${user.email} in Okta, user.mail in Entra ID, email in an OIDC token.

TenantFlex maps every source claim to one canonical name, based on a central user profile, and writes it in the destination provider's own form.

Claims without a clean match are given a suggested transform, with a confidence score and a check on sample users, and marked for review.

The console

One console for every tenant, every provider, every migration job.

Connect your source and target tenants, explore what is actually integrated, and run migrations with a full execution log.

TenantFlex create migration job screen with job configuration and application selection — **Migration jobs**Pick a source tenant and any connected destination, even the same provider, set the naming template and credential handling, then stage the selected applications for approval.

TenantFlex application review screen listing applications with their discovery assessment and migration status — **Application review**Browse every application and service principal in a connected tenant, see which carry standard or complex claims, and mark what is in scope before anything moves.

TenantFlex credential expiry screen listing signing certificates and client secrets with their end dates and status — **Credential expiry**Every signing certificate and client secret with an end date, across source tenants and migrated applications, soonest first. Rescanned nightly.

By provider pair

Every direction between the three providers.

The same workflow, with the permissions, claims forms and cutover notes for the pair you are moving between.

Entra ID → Oktamigrate Entra ID → PingOnemigrate Okta → Entra IDmigrate Okta → PingOnemigrate PingOne → Entra IDmigrate PingOne → Oktamigrate

What we ask to read

Read-only to start. Nothing more until you need it.

Microsoft Entra ID

Step 1 · read applications Application.Read.All

Lists applications and service principals with their sign-on configuration, redirect URIs, assignments, certificates and secret expiry. The inventory, discovery reports and credential expiry run on this alone.

Only for the features you use optional

Claims on SAML enterprise applicationsPolicy.Read.All
Without it, a SAML application's claims are reported as unknown rather than as standard.
Conditional access that applies to an applicationPolicy.Read.ConditionalAccess
SCIM provisioning statusSynchronization.Read.All
When an application was last signed in toReports.Read.All
Privileged access reviewRoleManagement.Read.DirectoryRoleAssignmentSchedule.Read.Directory
Reads directory role holders, active and PIM-eligible. Azure RBAC is read through a separate read-only role at the root management group.
Migrating into this tenantApplication.ReadWrite.All
Destination only: create the applications and their claims configuration. A source tenant never needs it.

Okta

Step 1 · read applications okta.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.

Only for the features you use optional

The sign-on policy governing an applicationokta.policies.read
API scopes granted to OAuth applicationsokta.appGrants.read
Without it, an OAuth application's API permissions are reported as unknown.
When an application was last authenticated tookta.logs.read
Also needs an administrator role that can read the System Log.
Admin role reviewokta.roles.readokta.users.readokta.groups.read
Reads who holds admin roles, directly or through a group. The API client also needs an administrator role that can read role assignments.
Migrating into this orgokta.apps.manage
Destination only. A source org never needs it.

PingOne

Step 1 · read applications Configuration Read Only

PingOne gives a worker application a role rather than scopes. This role lists applications and reads their attribute mappings, which are PingOne's claim configuration, and cannot change anything.

Only for the features you use optional

Migrating into this environment, or restoring a backupClient Application Developer
Creates applications and writes their configuration back. A source environment never needs it.

Roadmap

Where the platform goes next.

Today we migrate SSO. Each step widens what a tenant move can carry with it, in the order customers have asked for it.

In production

SSO migration

Pre-discovery and migration of SAML and OAuth/OIDC applications between Entra ID, Okta and PingOne, running in customer environments today.

Close the gap

SCIM discovery is in production: pre-discovery shows which applications provision users and how. SCIM migration is next, so provisioning moves with the app, not after it.

In progress

Security lifecycle

Certificate and secret expiry tracking across tenants is in production. Rotation follows, so a credential is renewed before it expires.

Planned

Governance

App consent and OAuth grant governance, so what was approved in the source is understood in the target.

The order changes with what customers ask for.

Ask about the roadmap

Get started

See it on your own tenants.

Tell us the source and target identity providers and we will walk you through a live migration, read-only until you say otherwise.

[email protected] · www.tenantflex.com