Notifications
Clear all
Topic starter
05/07/2026 10:44 pm
TL;DR: SSO tenant migration approaches that use DNS redirection and existing SAML or OIDC parameters can move tenants without customer-side reconfiguration, which reduces coordination overhead during provider changes, according to Descope. The operational lesson is that tenant portability is a governance problem as much as an engineering one, especially where identity workflows span multiple organisations.
NHIMG editorial — based on content published by Descope: how to migrate SSO tenants without reconfiguration
Questions worth separating out
Q: How should security teams migrate SSO tenants without customer reconfiguration?
A: Use a migration design that preserves the existing federation contract while rerouting traffic to the new service provider.
Q: Why do SSO migrations create identity governance risk?
A: Because each tenant is a discrete organisational trust relationship, not a shared template.
Q: What breaks when SCIM is not included in an SSO migration plan?
A: User provisioning can diverge from sign-in even if authentication continues to work.
Practitioner guidance
- Map every tenant-specific federation dependency Capture ACS URLs, entity IDs, IdP metadata, redirect URLs, and domain mappings for each tenant before any cutover.
- Separate sign-in continuity from provisioning continuity Plan SSO and SCIM together so user authentication and lifecycle updates move through the same migration window.
- Use routing changes as a controlled identity mechanism Treat DNS or proxy rules as part of the identity architecture and place them under the same approval, testing, and rollback discipline as federation settings.
What's in the full article
Descope's full guide covers the operational detail this post intentionally leaves for the source:
- Step-by-step Cloudflare Worker and AWS Lambda proxy configuration for live SSO traffic
- Code samples for Descope Flows, SDK-based tenant creation, and SAML settings
- SCIM proxy settings and log-only validation steps for safer cutover testing
- Rollback mechanics for cookie-based routing and staged tenant migration
👉 Read Descope's guide to migrating SSO tenants without reconfiguration →
SSO tenant migration without reconfiguration: what changes for IAM teams?
Explore further
05/07/2026 10:48 pm
SSO tenant migration is really a federation continuity problem, not a login problem. The article shows that the hard part is preserving exact tenant behaviour while moving the service provider behind the scenes. That distinction matters because authentication can appear stable even when tenant routing, metadata interpretation, or provisioning paths are misaligned. Practitioners should read this as a reminder that federation migrations fail at the boundary between protocol correctness and tenant-specific configuration.
Tenant portability will matter more as identity estates become more distributed. Teams that can move federation relationships without forcing customer reconfiguration will handle platform transitions with less disruption, but only if they preserve tenant-level trust data and lifecycle flow. The practical signal is that migration architecture now belongs in IAM design reviews, not just implementation runbooks.
A question worth separating out:
Q: Who is accountable for SSO tenant cutover success?
A: Accountability usually sits with the identity team that owns the migration design, DNS or proxy routing, and tenant configuration validation. Customer IT may still need to confirm trust settings, but the migrator is responsible for preserving service continuity, proving rollback, and ensuring the old and new paths behave identically during transition.
👉 Read our full editorial: SSO tenant migration without reconfiguration changes IAM operations
