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.
At a glance
What this is: This is a practical guide to migrating SSO tenants without customer-side reconfiguration, using DNS redirection plus existing SAML or OIDC settings.
Why it matters: It matters because IAM teams need migration patterns that preserve authentication continuity, tenant boundaries, and operational control when identity platforms change.
👉 Read Descope's guide to migrating SSO tenants without reconfiguration
Context
SSO tenant migration is hard because the service provider, identity provider, and customer tenant are all already bound by exact configuration. In practice, even when the authentication flow is standard, a move between platforms can force each customer IT team to touch DNS, ACS URLs, metadata, and tenant settings.
The identity governance issue is not just login continuity. It is whether tenant portability can be achieved without turning every cutover into a multi-party change-control exercise across IAM, support, and customer administration teams.
Key questions
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. Keep the source IdP settings, ACS endpoints, redirect handling, and tenant mappings aligned, then validate the path with internal users first. The goal is continuity of authentication and provisioning, not a redesigned tenant experience.
Q: Why do SSO migrations create identity governance risk?
A: Because each tenant is a discrete organisational trust relationship, not a shared template. If migration requires customer-side reconfiguration, identity teams inherit coordination risk, inconsistent cutover timing, and more chances for drift between authentication, provisioning, and support processes. Governance improves when the migration path reduces dependence on external tenant owners.
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. That creates stale attributes, delayed onboarding or offboarding, and mismatched tenant state across systems. A migration is only complete when both login and lifecycle updates still reach the correct tenant through the new path.
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.
Technical breakdown
How DNS redirection preserves SAML and OIDC continuity
The migration pattern keeps the existing authentication contract intact while changing where the response lands. In SAML, the user still authenticates with the original IdP and returns to the same ACS URL, but DNS redirects that response to the new service provider so it can process the assertion. In OIDC, the same principle applies through matching parameters and response handling. The important technical point is that the tenant does not need a redesigned federation relationship, only a rerouted termination point.
Practical implication: validate that response handling, relay state, and redirect targets stay consistent before cutover.
Why tenant-level SSO settings matter in migration
Each SSO tenant represents a discrete organisational configuration, not a generic login toggle. That means migration depends on preserving tenant-specific values such as IdP metadata, entity IDs, ACS URLs, redirect URLs, and domain mappings. The guide shows that the new platform must interpret the same federation data the old platform used, otherwise authentication may still succeed at the IdP while tenant resolution fails in the destination system. This is a configuration fidelity problem, not an authentication problem.
Practical implication: inventory every tenant-specific federation field before migration and compare source and target values exactly.
How SCIM proxying fits into phased SSO cutover
When SCIM is part of the tenancy model, the migration has to cover provisioning as well as sign-in. Proxying SCIM requests alongside SSO lets the organisation keep user lifecycle updates flowing while the underlying service provider changes. The article’s DNS proxy pattern extends to SCIM by forwarding requests through the same routing layer, which avoids splitting authentication and provisioning into different migration windows. That matters because broken provisioning can create drift even if login continues to work.
Practical implication: treat provisioning continuity as part of the cutover plan, not as a post-migration cleanup task.
NHI Mgmt Group analysis
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.
DNS redirection becomes an identity control surface when it is used to preserve authentication state. The guide makes DNS part of the identity path, not just the network path. That expands the operational blast radius because a routing change can now alter which system terminates SSO traffic, which SCIM requests reach the tenant, and which environment becomes authoritative for login. The implication is that identity teams must govern routing, not only federation settings.
Tenant portability exposes the hidden cost of customer-administered reconfiguration. The post implicitly shows that traditional SSO migration assumes every customer can be mobilised to update their own configuration. In reality, that assumption creates coordination debt across support, customer IT, and identity teams. The practical conclusion is that migration design should minimise dependence on external tenant owners whenever the authentication contract can be preserved programmatically.
SCIM continuity matters as much as SSO continuity during cutover. The article treats provisioning proxying as part of the same migration story, which is the correct framing. If sign-in moves cleanly but lifecycle updates do not, identity drift begins immediately. Practitioners should evaluate migration plans on whether both authentication and provisioning remain coherent across the transition.
Runtime federation migration can reduce change-control friction without weakening control if the original trust parameters stay fixed. This is the central operational trade-off in the article. The value comes from moving traffic, not from renegotiating trust, which means the migration succeeds only if the same SAML or OIDC semantics are preserved end to end. Teams should treat this as a controlled reroute of identity traffic, not as a new trust relationship.
From our research:
- 98% of companies plan to deploy even more AI agents within the next 12 months, despite documented rogue behaviour in 80% of current deployments, according to AI Agents: The New Attack Surface report.
- Only 52% of companies can track and audit the data their AI agents access, leaving 48% with a complete blind spot for compliance and breach investigation.
- For the governance side of this problem, read the Ultimate Guide to NHIs for the control model that keeps machine identity changes from becoming operational drift.
What this signals
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.
The broader pattern is that identity teams are being asked to reduce coordination cost without weakening control. That means routing, provisioning, and federation need to be treated as one governance chain, especially when customer-managed tenants and external IdPs are involved.
The same discipline that prevents SSO cutovers from fragmenting also helps with machine identity lifecycle work, where a preserved trust contract is often more valuable than a total redesign. For that reason, migration planning should be reviewed alongside NHI lifecycle guidance and current federation standards.
For practitioners
- Map every tenant-specific federation dependency Capture ACS URLs, entity IDs, IdP metadata, redirect URLs, and domain mappings for each tenant before any cutover. Compare source and target values field by field so you can prove that the federation contract stays consistent.
- Separate sign-in continuity from provisioning continuity Plan SSO and SCIM together so user authentication and lifecycle updates move through the same migration window. If provisioning is left behind, identity drift can begin even when logins appear healthy.
- 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. Validate that traffic reaches the intended tenant before expanding scope.
- Test internal accounts before tenant expansion Run the migration first with internal users, then a small customer subset, and only then widen coverage. Confirm the expected login path, tenant association, and SCIM behaviour at each stage.
Key takeaways
- SSO tenant migration is difficult because each customer tenant has its own trust configuration, and reconfiguration at cutover creates unnecessary coordination risk.
- DNS redirection can preserve authentication continuity, but only if ACS URLs, entity IDs, redirect handling, and provisioning paths remain aligned.
- IAM teams should treat tenant portability as a governance capability, with validation, rollback, and SCIM continuity built into the migration plan.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST Zero Trust (SP 800-207), NIST CSF 2.0 and NIST SP 800-63 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST Zero Trust (SP 800-207) | The migration reroutes authenticated traffic while preserving trust boundaries. | |
| NIST CSF 2.0 | PR.AC-1 | Tenant-based access and identity routing need controlled governance. |
| NIST SP 800-63 | Federated authentication continuity depends on stable identity assertions. |
Verify that routed SSO traffic still satisfies zero-trust verification and access boundary requirements.
Key terms
- Service Provider: The system that receives and consumes the federation response after a user authenticates with an identity provider. In migration work, the service provider is often the component being replaced, so its URLs, metadata, and assertion handling must remain consistent during cutover.
- Tenant: A discrete customer configuration inside a shared identity platform. Each tenant carries its own domains, federation settings, and lifecycle relationships, which means migration work must preserve tenant-specific trust and routing rather than assuming one global configuration fits all.
- SCIM Proxying: Forwarding SCIM provisioning requests through an intermediate routing layer so user lifecycle updates continue while systems are being migrated. It is useful when sign-in can move first, but it still requires careful validation so provisioning state does not drift from authentication state.
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
Deepen your knowledge
NHI governance, agentic AI identity, and machine identity lifecycle are core topics in our NHI Foundation Level course, the industry's only accredited NHI security programme. If you are responsible for identity security strategy or NHI governance in your organisation, it is worth exploring.
Published by the NHIMG editorial team on 2026-06-18.
NHI Mgmt Group — the independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org
