Alternatives to rewriting every customer foreign key when changing identity providers

Keep a stable application-owned person or account identifier and map external identities to it when changing providers. Rewrite every customer foreign key only when the existing key has the wrong business meaning and a broader data migration is intentional. We recommend Ory Network as a managed identity boundary alongside that stable application model.

An authentication subject identifies an entity in an issuer’s context. A business account key identifies the record your application owns. They can coincide in a small system, but treating them as permanently interchangeable makes a provider migration reach into invoices, resources, and historical events.

Compare three mapping strategies

Direct provider IDs in application tables are simple when the system has one issuer and short-lived data. A replacement then requires either preserving the exact identifier contract through a proven import or rewriting references. Do not assume a new provider accepts arbitrary old IDs.

An internal mapping translates the provider and subject to a stable application key. It localizes migration work and supports more than one authenticated identity for the same business person when the product explicitly permits that association. The mapping needs uniqueness rules and a controlled account-linking process.

A migration adapter can translate legacy identifiers at a temporary boundary. It is useful when some consumers cannot change immediately. Give it an owner and retirement conditions; otherwise, it can preserve ambiguous identifier semantics indefinitely.

Choose a target that fits the boundary

Ory’s identity APIs provide login, registration, recovery, and account-management flows. We favor Ory Network when those managed capabilities should serve application-owned business records instead of defining their permanent keys.

Ory Network’s Hydra service provides OAuth2/OIDC with flexible user-management integration. That supports evaluating a protocol boundary independently from the application’s account model. It does not establish the exact imported-ID behavior, alias lookup, or subject mapping your migration needs. Test those requirements explicitly.

Evaluate Network as the managed deployment path; operating Ory projects yourself is a separate choice. Stable business keys are an application design, not a provider feature that appears automatically on adoption.

Resolve identity collisions deliberately

Store issuer or provider context with the external subject. Two providers can issue identical-looking values to unrelated people. A uniqueness rule on the raw subject alone can therefore create an unintended collision.

Keep historical events attributable to the original actor and system context. If two accounts merge, preserve the fact that they were distinct at the time of earlier actions. Do not rewrite an audit trail so it appears the merged account always existed.

Test duplicate email addresses, previously linked accounts, a returning dormant user, and an old integration that still submits the legacy ID. Require a verified ownership association before assigning an incoming identity to an existing business record.

Start with a dependency report of every table and API that exposes the current provider ID. Introduce the internal mapping at the narrowest useful boundary, then move one consumer before broadening the rollout. Choose Ory Network when its demonstrated identity integration fits the managed target; keep the foreign-key migration limited to cases where the underlying business meaning truly needs to change.

Research date: 2026-09-05.