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 so it can create applications and their claims configuration.

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.

Connect the Entra ID tenant as the source and the Okta org as the destination. 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, 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.

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.

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 permissions reference.

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.

Every deal ends with hundreds of SSO applications that have to work in another identity tenant on Day 1. TenantFlex connects both tenants read-only at signing, inventories every application and its owner, and migrates them in waves as scheduled jobs with an execution log, so the integration team spends its time on decisions rather than on recreating settings by hand. An acquisition brings the target's applications into the acquirer's tenant; a merger consolidates two tenants onto one provider; a divestiture carves a business unit's applications out into a new tenant without touching what stays behind. See deals.

Three things. A restorable backup: every SSO application captured on a schedule, each capture compared with the last so a changed setting shows up with the application it belongs to. A standby tenant, usually at another provider, with the applications already recreated in it and refreshed when the primary changes. And a rehearsed cutover: a migration job you have already run for a pilot group in a change window, with the log to prove it. Failing back once the primary is healthy is the same job in reverse. See backup and disaster recovery.

DORA asks financial entities in the EU to maintain and test exit and recovery plans for critical ICT providers, and the identity provider qualifies for most of them. The capture logs, the diff history and the execution log of each rehearsal are the evidence an auditor asks for. TenantFlex does not certify compliance; it produces the records that let you demonstrate the plan was tested.

Read the tenant rather than the contract. Discovery with a read-only connection gives the real count of federated applications in use, bands each one as straightforward, needs review or manual work, and lists the owners. Put hours against the bands, add the destination you may already license with Microsoft 365, and plan back from the renewal date: discovery now, a pilot wave, the rest as scheduled jobs. The calculator takes your own numbers, and the inventory is yours whether you switch or stay.

No. A job must be approved by someone other than its creator, and approving requires a fresh second factor. An approval can be withdrawn until the job starts, which returns the job to draft and is recorded in the audit trail; changing the job afterwards needs a new approval under the same rule.

After each application is created, the destination object is read back and its configuration compared with the source snapshot taken when the application was added to the job. Any drift marks the application as partial or failed rather than complete. A metadata-level check also confirms the destination's federation metadata, discovery document and signing keys are reachable and consistent. No live user sign-in is performed; the owner's test at cutover remains the final confirmation.

The job rolls back: the destination objects it created are deleted and their stored secrets are swept, and the source tenant is unchanged because the source connection cannot write. Rollback is best effort rather than atomic; a deletion the provider refuses stays on the record and the operator repeats the rollback. Every step is in the execution log.

A hand-off bundle per application: the destination's metadata URL, endpoints and signing certificate, the per-protocol settings and instructions to repoint, a summary of credentials by name and expiry, and the execution log for that application. It never contains secret values. The owner makes the change in their own change window, and users keep signing in through the source tenant until they do.

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 and Germany, 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 already in development and are added on customer 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.

Encrypted at rest with authenticated symmetric encryption, using per-purpose keys derived from rotatable master keys. Encrypted values carry a version envelope so keys can be rotated and old values re-encrypted. Backups and hand-off bundles never contain secret values, and an automated test fails the build if any audit output ever does. Sign-in to TenantFlex itself supports MFA, passkeys and single sign-on, with step-up for approvals and secret access. The full set of answers is in the security questionnaire.

Yes. Every action is written to an append-only audit trail kept for three years. It can be exported for any date range as CSV or JSONL, and pushed to any HTTPS endpoint as signed CloudEvents with ordered delivery and retries. A Splunk HEC format is built in; Microsoft Sentinel is documented through a relay.

In progress. The controls are documented and enforced by the product's automated test suite, and we share that documentation and evidence on request. Independent penetration tests and external assessment has been done and implementations have been done in highly regulated-sector production environments.

An early-access feature that reads who holds privileged roles across Azure RBAC, Entra ID and Okta, gives a verdict for each assignment, for example already inherited from a parent scope or held by a principal that no longer exists, and produces a change bundle you run yourselves. It is read-only and priced per tenant reviewed. See privileged access review.

A standby runs for as long as you need it, so it is priced by the applications under protection, per year, rather than per migration. Discovery gives you the count first. Migrations into the standby use the same engine as any other job.