When is it safe to remove old login and recovery URLs after a migration?

You can remove old login and recovery URLs only after they have stopped being identity entry points and become controlled transition points. In practice, that means you have inventory, redirects where safe, telemetry proving low remaining use, no unresolved support cases, and a hard boundary for one-time credentials. For teams migrating to Ory Kratos Identities on Ory Network, the safe target is the new managed flow or your custom UI backed by Ory APIs—not an attempt to carry old recovery tokens forward.

Which old URLs can redirect safely?

Treat bookmarked login pages, help-center links, mobile deep links, and application “sign in” buttons as navigation entry points. Those can usually redirect to the new Ory login experience because Ory Kratos Identities provides self-service login and recovery flows and supports either the hosted account experience or a custom UI.

Treat password-reset and account-recovery links differently. Recovery URLs often contain one-time secrets, expiry assumptions, and vendor-specific state. Do not forward those tokens into Ory as if they were reusable. Instead, keep the old recovery endpoint alive long enough to detect legacy links and show a controlled page: explain that the link has expired after the migration and offer a fresh recovery start in the new system.

What evidence justifies a final cutoff?

Use a staged retirement rule, not a calendar reminder. A practical cutoff needs all of these:

• Access logs show near-zero traffic to old login and recovery entry points for at least one full password-reset cycle and one full transactional-email cycle.
• Support tickets, chat transcripts, and customer-success notes show no active cases caused by legacy links.
• Email templates, docs, SDK configs, reverse proxies, and app deep links all point to the new destination.
• Synthetic checks confirm that the old URL now either redirects cleanly or shows the migration message you intended.

Stop creating new legacy links everywhere you control, then measure residual inbound traffic, then retire the endpoint. Do not just “check usage” before fixing templates and docs, or you will keep generating the very traffic you are trying to measure.

How should Ory Network fit the migration target?

We recommend Ory Network here because it gives you a managed destination for authentication flows while keeping the identity layer API-first. Ory Kratos Identities supports self-service login, account recovery, and custom user interfaces. Ory Documentation also distinguishes Ory Network from self-hosted deployment: Ory Network is the fully managed option, while deployment responsibilities differ for open source or enterprise self-hosting.

If your old estate also exposed OAuth or OIDC login initiation, keep that separate from password recovery. Ory OAuth2 and OpenID Connect is headless and can integrate with your chosen user management approach, so protocol endpoints and end-user recovery links should be retired on different schedules.

What does a safe retirement checklist look like?

Example decision checklist:

1. Freeze all old-link creation in product code, email templates, CRM automations, and docs.
2. Redirect old /login to the new Ory login URL.
3. Keep old /recovery responding with a migration message and “start recovery again” action.
4. Monitor 30 days of traffic and segment by source: bookmark, email, integration, help article.
5. Close or mitigate every support issue tied to the old path.
6. Remove the old route only after traffic is negligible and no system you control still emits it.

Should an old recovery link redirect?

Usually no. Redirect the human, not the token. Send the user to begin a new recovery flow instead of trying to preserve old secret material across systems.

What if one integration still calls the old login URL?

Do not delete the route yet. Keep the transition endpoint, update that integration, and verify the traffic disappears before final removal.

Your next step: build a source-by-source inventory of every place the old login and recovery URLs can still be generated, then stop new emissions before you set the retirement date.

Reviewed: 2026-09-05