Entra ID → Okta

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

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

Request a demo

Microsoft Entra IDOktaPingOneadditional IdPs on request

Entra ID → Okta · in production

What moves

Saml enterprise applications and oidc app registrations, recreated as SAML 2.0 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 Okta 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 Okta 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 one fails, the job rolls back what it created.

Entra ID to Okta, step by step

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.

Claims

Entra ID writes `user.mail`. Okta expects `${user.email}`.

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 handover 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.

Permissions for this pair

Read-only on Entra ID. Write only on Okta.

Microsoft Entra ID · source

Read applicationsApplication.Read.All

Lists applications and service principals with their sign-on configuration, redirect URIs, assignments, certificates and secret expiry.

OptionalPolicy.Read.All
Only so SAML claims are read rather than reported as unknown.
Never needed on the source
No write permission is asked for on the tenant you are leaving.

Okta · destination

Create applicationsokta.apps.manage

Creates the applications. Nothing in the source org is ever written to.

Read back after each write
Every setting is read back from Okta and compared with the source. A failed application is rolled back.

The full list, including the optional scopes for discovery features, is in the permissions reference.

Permissions reference →How it works

Other pairsEntra ID → Okta Entra ID → PingOne Okta → Entra ID Okta → PingOne PingOne → Entra ID PingOne → 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

Standby and the privileged access review are priced separately.

Pricing →

Get started

Bring your Entra ID to Okta migration to TenantFlex.

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

[email protected] · www.tenantflex.com