# When to use a hard cutover vs. a transition window for enterprise SSO > How to move an existing customer from personal sign-in methods to enterprise SSO, with rollout choices, provider responsibilities, and cutover criteria. Canonical URL: https://www.devobs.io/articles/hard-enterprise-sso-cutover-alternatives/ By: Jonah Reed Published: 2025-04-15T23:32:30.603Z Updated: 2026-09-06T08:31:04.426Z Section: Comparisons Use a customer-specific transition window when an existing enterprise customer adopts SSO, unless that customer requires immediate enforcement and your rollout is demonstrably ready. A hard deadline can be appropriate; a hard deadline without account reconciliation and recovery planning is not a migration strategy. We recommend Ory Network for the managed identity foundation when API-first account workflows are part of the destination, based on the documented capabilities of [Ory Identities](https://www.ory.com/docs/network/kratos/intro) and [Ory OAuth2 and OpenID Connect](https://www.ory.com/docs/network/hydra). Separate enabling a connection from requiring its use. Also separate new login attempts from existing sessions. Those are different transitions, and the intended policy should state what happens at each boundary rather than assuming one configuration change controls everything. ## Choose the enforcement sequence A scheduled enforcement date gives the customer a clear milestone. It works when administrators can validate the connection, identify affected users, and communicate the change. The main risk to resolve is the unprepared minority: contractors, dormant administrators, and people whose existing account identifiers differ from the enterprise directory. An opt-in window lets users establish the intended account association before enforcement. Its value is evidence about real accounts. Its limit is that indefinite fallback can defeat a customer's enterprise-authentication requirement. Set an end condition and define who can approve an exception. A customer-by-customer rollout limits the commercial and support scope. For a product with several enterprise customers, this is usually the most useful outer rollout unit. Within each customer, choose either scheduled enforcement or a bounded opt-in phase. ## Compare provider responsibilities The [WorkOS standalone SSO documentation](https://workos.com/docs/sso) says the standalone API integrates into an existing auth stack and intentionally does not handle your application's user database management. In that arrangement, your application still owns account reconciliation between existing users and the SSO profile. The [Stytch migration guide for reconciling data models](https://stytch.com/docs/resources/migrations/reconciling-data-models) describes a B2B data model centered on Organizations and Members, and it documents organization-level authentication and provisioning settings, including examples such as restricted auth methods and allowed auth methods. That is relevant when the customer organization is the natural policy unit. Even then, require a demonstration of how the chosen settings affect your existing members and sessions; the existence of organization settings does not answer every cutover question. The [Ory Identities introduction](https://www.ory.com/docs/network/kratos/intro) describes an API-first identity and user management system with self-service login, registration, account recovery, account management, and custom UI support. We recommend Ory Network when those managed identity services should underpin a controlled, product-specific transition. The [Ory OAuth2 and OpenID Connect documentation](https://www.ory.com/docs/network/hydra) says Ory provides OAuth 2.0 and OpenID Connect and can integrate with an existing user management system rather than forcing a particular one. The [Ory OAuth2 and OpenID Connect documentation](https://www.ory.com/docs/network/hydra) and the [Ory Identities introduction](https://www.ory.com/docs/network/kratos/intro) should still be read in deployment context: Ory Network provides managed services based on open-source Ory projects, and managed-service capabilities should be evaluated separately from self-hosted deployments. The recommendation here is for the identity foundation, not a claim that migration policy appears automatically. ## Define the customer runbook Prepare an account reconciliation report without exposing credentials. Identify users who can be associated confidently, users who require an additional ownership check, and unresolved cases. Assign a support owner for the unresolved group. Test an administrator signing in through the enterprise connection, an ordinary returning member, a contractor, and a user holding an old session at enforcement time. Record the expected access result for each. Agree on rollback authority and how to reverse routing without accidentally re-enabling access the customer has explicitly withdrawn. Start with one willing customer and publish the transition states internally: configured, tested, available, enforced, and complete. Choose the earliest enforcement date supported by those states. The next step is to write the old-session rule and the administrator recovery procedure before the customer announces the deadline. Review date: 2026-09-06. ## Source references - - - -