SSO and identity provider migration, answered.

Connect the Okta org as the source and the Entra ID tenant as the destination. The Okta connection only needs okta.apps.read; the Entra connection needs Application.ReadWrite.All and Policy.ReadWrite.ApplicationConfiguration so it can create applications and attach their claim policies.

Run discovery on the Okta org to list every SAML application with its sign-on configuration, attribute statements and assignments, and to band each one as straightforward, needs review or manual work. Pre-approve the applications in scope, create a migration job with a naming template, and run it. TenantFlex creates each application in Entra ID as an enterprise application with SAML single sign-on configured from the Okta settings (identifier, reply URL and NameID) and a claims policy built from the Okta attribute statements. Every stage is written to an execution log, including any setting Entra ID refuses, such as an identifier on a domain the tenant has not verified.

The application owner then points the service provider at the Entra ID federation metadata (login URL, identifier and signing certificate) at a time that suits them.

The same workflow in the other direction. The Entra ID connection needs Application.Read.All, plus Policy.Read.All so SAML claims are read rather than reported as unknown. The Okta connection needs okta.apps.manage to create applications.

Discovery reads each enterprise application's SAML configuration and claims. The migration job creates a SAML 2.0 application in Okta with the same audience and assertion consumer service URL and attribute statements translated from the Entra ID claims. The application owner switches the service provider to the Okta metadata at cutover.

Connect the PingOne environment with a worker application that holds the Configuration Read Only role. Discovery lists its applications and reads their attribute mappings, which are PingOne's claim configuration. Choose Entra ID or Okta as the destination and run the same pre-approve and migrate steps as for any other pair of providers.

Discovery reads each OIDC application's redirect URIs, grant types, claims and credentials. The migration job recreates the application in the destination with the same redirect URIs and claims. Client secrets cannot be read from any identity provider, so a new client secret is created in the destination, and the application owner updates the client ID, client secret and issuer URL in the application at cutover.

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.

Each provider's claims are translated to one shared vocabulary, based on Okta's base user profile, 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.

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.

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.

Every SAML and OIDC application and service principal, with its sign-on configuration, claims, assignments, certificates and secret expiry. With the optional permissions it also reads SCIM provisioning status, the conditional access or sign-on policy that applies to the application, and when the application was last signed in to. Each application gets a band, straightforward, needs review or manual work, and the overall report sizes the whole migration before it starts.

One read permission to start: Application.Read.All on Entra ID, okta.apps.read on Okta, or the Configuration Read Only role on PingOne. Everything else is optional and added only for the feature that needs it. Write permissions are needed only on a tenant you migrate into. The full list is in the Access section.

Yes. The Credentials page lists every signing certificate and client secret with an end date, across source tenants and migrated applications, soonest first. A nightly scan keeps it current, and a scan can be run on demand.

Yes. A backup captures every SSO application a connection can see, on demand or on a schedule. A capture can be compared with the tenant as it is now, and the fields that changed can be restored. The same inventory lets you stage applications in a standby tenant at a second provider for disaster recovery.

Yes. TenantFlex is available as SaaS and as an on-premises deployment of the same release, for organisations with data residency or regulatory requirements. On-premises, application metadata, credentials and migration logs stay inside your network.

The TenantFlex SaaS runs on servers in Finland, so tenant data processed by the hosted service stays in the EU. The TenantFlex team is based in the EU. Organisations that need the data inside their own environment can use the on-premises deployment.

Microsoft Entra ID, Okta and PingOne. Additional identity providers are added on request.

Discovery already shows which applications provision users through SCIM and how. Migrating the provisioning configuration with the application is the next item on the roadmap.

By the applications in scope, not by user count or tenant size. Discovery tells you that number before you commit. Alternatively, the white-glove option includes our practitioners, who run discovery, the claim and policy decisions, cutover planning and the hand-off to application owners with you.