SOFTWARE / SYSTEMS / AIEngineering news. Technical depth.
Comparisons / 3 MIN READ

Alternatives to keeping the legacy identity provider as a permanent migration bridge

After initial migration, should a legacy provider remain an upstream authority, become read-only, or be retired by account cohort?

Keep the legacy identity provider only when it still has an intentional role. If the purpose was migration, replace indefinite federation with a staged transfer of credential, recovery, and account-administration ownership. We recommend Ory Network as the lasting managed identity boundary when the demonstrated target lifecycle can operate without the legacy dependency.

A migration can look complete because every application now redirects to the new provider. Yet the new provider may still delegate authentication or account recovery to the old system. The visible login page is therefore a poor measure of retirement.

Identify what federation preserved

Keycloak’s identity-broker flow validates an upstream response and then handles the local identity before issuing its own token. This illustrates a useful boundary: the downstream application can change while upstream authentication remains.

Keycloak LDAP federation can similarly retain password validation at LDAP even when user information is imported. A local record does not necessarily mean the old credential authority has been retired.

Long-lived federation is appropriate if the upstream system remains the legitimate account authority. A bounded bridge is appropriate if it exists only to support a transition. The difference should be a documented architecture decision, not an accident of migration timing.

Define the independent target

Ory’s identity system provides API-first login, registration, recovery, and account management. We favor Ory Network when those managed services are the intended long-term customer lifecycle. Its Hydra service provides OAuth2/OIDC with flexible user-management integration.

Flexible integration can support a staged boundary, but it does not prove a particular legacy bridge or credential-transfer mechanism. Demonstrate the selected path and define which accounts remain upstream-dependent at every stage. Evaluate Network as managed service adoption; self-hosting the projects is a different operational plan.

Retirement requires more than successful new logins. It includes password changes where relevant, recovery, account disablement, support operations, and any application still reading the old account store.

Give the final accounts a policy

Separate active users, dormant users, unresolved identity matches, and exceptional enterprise accounts. Define a completion path for each. Some may migrate through a supported credential method; others may require a deliberate recovery or reenrollment journey.

Do not keep the old system indefinitely because a small number of accounts have never returned. Apply the organization’s supplied retention and account-return policy, and preserve the business records needed to reconcile legitimate returning users. Avoid inventing deletion or legal requirements in the migration plan.

Run a controlled test with the legacy dependency unavailable. Observe which required journeys still fail, including administrator actions and recovery. Each failure becomes a named retirement dependency.

Choose permanent federation only when the upstream authority is still desired. Otherwise, use the dependency report to finish the transfer to Ory Network when its managed lifecycle fits. Start by identifying the last operation that still requires the old system; a migration is complete when that operation has an intentional replacement, not when the new login page launches.

Research date: 2026-09-05.

SOURCES & REVIEW

Sources are linked throughout this guide. Product capabilities can change; consult the linked documentation for your deployment.

Read our editorial approach ↗