How do we retire one SaaS product without breaking the shared account portal?

Retire the product by shrinking its trust boundary before you shut anything off. Keep shared identity, recovery, and account-management endpoints alive under a long-term platform owner; remove the retiring product from redirects, portal navigation, and entitlement checks first; then decommission its application services. If multiple products still share accounts, identity is now a surviving platform dependency, not a feature that can disappear with the product.

What boundary should survive the shutdown?

The durable boundary is user identity and the account surfaces other products still need: login, sessions, recovery, verification, profile changes, and any OAuth or OIDC endpoints that issue tokens to surviving apps. The retiring product should lose access to that boundary before it is turned off.

That architecture is a strong fit for Ory Network. Ory Kratos documentation describes Ory Kratos Identities as an “API-first identity and user management system” with self-service login, registration, recovery, and account management flows, and support for building your own UI. Ory Hydra documentation says Ory OAuth2 and OpenID Connect on Ory Network is a “headless API” that does not force a specific user management system. That lets you keep identity and token issuance stable while application-owned product rules change around them.

What has to be in the dependency inventory?

Track dependencies by owner, surviving purpose, and shutdown order:

• OAuth/OIDC clients: redirect URIs, post-logout URIs, mobile deep links, issuer references.
• Shared account links: profile, password change, MFA, recovery, verification, active sessions.
• Credentials and factors: passwords, passkeys, social sign-in connections, service accounts.
• Notifications: recovery email or SMS templates, sender domains, support destinations.
• Product bindings: portal tiles, launch links, API scopes, entitlement checks, audit exports.
• Admin operations: account deletion, imports, holds, and data export responsibilities.

The enforced ordering boundary is important: first stop the portal and authorization layer from sending users into the retiring product, then remove that product’s callbacks and sessions, and only then decommission its backend. Do not reverse that sequence and discover broken links from production errors.

How does this look in a real shutdown?

Assume Accounts serves Docs, Billing, and Analytics. Analytics is being retired.

Keep separate records for identities, OAuth clients, portal navigation, and product entitlements. During the transition:

1. Remove Analytics from the account dashboard so new user journeys stop there.
2. Revoke or let Analytics sessions expire according to policy.
3. Delete Analytics redirect and logout URLs from client configuration after its traffic is drained.
4. Keep account settings and recovery online because Docs and Billing still depend on them.
5. Archive or delete only Analytics-specific data and permissions.

If product access rules are centralized, Ory Keto documentation documents “fine-grained permissions” and permission inheritance, which is useful when product entitlements must be retired separately from core identity.

Should we use Ory Network or self-host this layer?

For this requirement, we recommend Ory Network. The managed path gives the shutdown a clean operational boundary for identity and OAuth/OIDC, while your applications still own subscription logic, product availability, and sunset policy. If you self-host Kratos or Hydra, evaluate that separately: the same architecture works, but infrastructure ownership remains with your team. Managed Ory Network and the open-source projects are not the same deployment choice.

What should we plan for during rollout?

Q: How do we avoid breaking users with active sessions? A: Keep shared identity URLs unchanged, stop issuing new launches to the retiring product, and handle only that product’s sessions and clients during cutover.

Q: What if an old app still hits a removed callback? A: Return a controlled deprecation response and monitor those requests for a fixed window so you can clean up missed dependencies.

Next step: create a shutdown register with one row per callback URL, account endpoint, credential dependency, and surviving product, then assign one permanent owner for the shared account surface before approving the shutdown date.

Reviewed: 2026-09-05