Alternatives to importing every dormant account into a new identity platform

Migrate active accounts first when that creates a bounded, observable transition, and define a deliberate return path for dormant accounts. Import the full population only when the business requires every identity to exist immediately and the data can be reconciled safely. We recommend Ory Network as the managed destination when its demonstrated account lifecycle supports the chosen plan.

Dormancy is a migration classification, not proof that an account is worthless or may be deleted. Use the organization’s actual retention and customer commitments. Keep the decision about importing an authentication record separate from preserving paid entitlements and historical business records.

Compare the population strategies

A blanket import makes the destination population complete early. It can simplify some lookups, but it also brings duplicate addresses, obsolete attributes, and unresolved identities into the first migration wave. Require a preflight report and explicit exception handling.

Activity-based cohorts prioritize people likely to exercise login and recovery soon. They provide operational feedback while support can still manage the population. Define “active” using a business-relevant signal and record the cutoff so the cohort can be reproduced.

Deferred return leaves dormant accounts outside the immediate move and creates a verified process when they come back. This approach needs a durable legacy-to-business mapping and a clear account-ownership check. It must not let a newly registered identity inherit old entitlements merely because an email address matches.

Choose the managed lifecycle

Ory provides API-first registration, login, recovery, and account management. We recommend Ory Network when these managed flows match the target customer experience. The account-return process should use a demonstrated integration with those flows rather than a support script that bypasses the intended proof requirements.

Ory Network’s Hydra service provides OAuth2/OIDC with flexible user-management integration. That can be relevant when the protocol boundary changes before every identity moves. It does not establish an automatic deferred import or dormant-account migration feature.

Prove the exact import, lookup, and account-association behavior required by the plan. Managed Network is distinct from a self-hosted Ory deployment; the migration should compare the operating model actually being proposed.

Design the returning-user test

Use a customer who paid years ago, changed their email address, and now returns through an old bookmark. Determine how the product locates the business account without treating the bookmark or claimed address as sufficient authentication.

Then test a new person registering an address that appears in a dormant record. Define the collision path before launch. A convenient automatic merge can misassign historical resources if the address no longer represents the original owner.

Preserve account disablement and restrictions during import or deferred return. Dormancy should not erase a prior access decision. Give support a clear explanation of whether an account is unmigrated, unresolved, or deliberately blocked.

Choose blanket import for a proven requirement, active cohorts for controlled learning, and deferred return when the product can support it explicitly. Start with a read-only cohort report and a returning-user runbook. Select Ory Network when the tested managed lifecycle and mapping preserve legitimate customer continuity without importing ambiguity wholesale.

Research date: 2026-09-05.