Agen.co enables organizations to securely expose enterprise context to internal agents, copilots, and AI workflows through an identity-aware control layer that governs access, reduces risk, and centralizes oversight.
A low-code CIAM platform for managing customer identity as you scale.
Empower your workforce with secure agents
A staged CIAM migration moves customer organizations to a new identity system in controlled cohorts instead of switching every login at once. Each cohort needs a named login owner, reconciled user and tenant records, a tested sign-in path, an explicit session policy, and a rollback decision. The hard part is not simply importing users. It is keeping authentication and application access correct while the old and new systems coexist.
This guide gives a B2B SaaS team a cutover plan it can adapt to its own identity stack. It does not assume that moving a user record also moves an active session, an enterprise SSO connection, or the application’s authorization rules.
Four jobs often get bundled under “migration.” Separate them before changing production traffic, because each can succeed or fail independently:
For example, importing Customer A’s users does not mean Customer A is ready to sign in through the new provider. Its SSO connection might still point at the old one. Likewise, routing Customer A’s next login to the new provider does not invalidate sessions already issued by the old one. Write down the state of each job separately.
Frontegg’s user-migration documentation covers import paths. It should be read alongside—not substituted for—the plan for login routing and application authorization.
A B2B migration is usually easier to reason about by customer account or enterprise connection than by a random percentage of users. A customer may have multiple domains, and one person may belong to more than one customer account. A domain can help discover a sign-in route, but it is not proof of the user’s membership in a particular tenant.
Maintain a cohort register owned by the application team. For each customer, record its stable account identifier, current login owner, import/reconciliation status, SSO status, intended cutover time, approver, monitoring owner, and rollback path. An illustrative progression is:
An “imported” checkbox alone is not enough. It cannot tell support staff whether a failed login belongs to a data-mapping problem, an SSO configuration problem, a routing decision, or an application permission check.
The sign-in entry point needs to determine which identity system should handle an attempt. The application team should define what context is available before authentication, how it maps to the cohort register, and what happens when it is missing or ambiguous. Do not treat an email suffix, a client-provided tenant hint, or a remembered browser choice as an authenticated authorization fact.
Frontegg’s prehook documentation describes AUTH_INITIATED, an event at the beginning of login, before credentials are verified. The docs say the flow may continue with Frontegg or be sent to another login page. That establishes a possible routing surface; it does not establish a universal payload, a safe redirect configuration, or a ready-made migration implementation. Validate the exact behavior for your login methods and environment before deploying a route.
AUTH_INITIATED
Do not confuse this migration decision with SSO discovery within Frontegg. Its self-service SAML docs describe routing to a configured SSO connection using a claimed domain. The multi-tenant SSO guide describes additional choices when a domain is shared across multiple SSO configurations. Those settings select a Frontegg SSO path; they do not, by themselves, decide whether a cohort should still use a separate legacy identity provider.
If a person belongs to both a migrated and an unmigrated customer, test the intended sign-in path for each context. After any successful authentication, the application must still check the active tenant, the user’s membership and permissions, and the tenant that owns the requested resource. A successful login for Tenant A is not permission to read Tenant B’s data.
A rollback is more than reversing the route for new logins. It does not automatically undo imported records, revoke already-issued sessions, restore a former SSO configuration, or change which tokens an API accepts. Keep the legacy dependencies available for the agreed rollback window, and give each component an owner and an order of operations.
Test the cases most likely to be hidden by a successful happy-path login:
The Frontegg prehook docs describe configurable failure handling and logs that show a hook’s verdict and whether it succeeded. They do not replace the application’s own record of which cohort rule was applied. Log routing decisions in a privacy-reviewed way, without credentials or tokens, and correlate them with login and support outcomes where your architecture permits.
Before enabling a pilot, reconcile source and destination users and memberships, run the customer’s real SSO flow if applicable, and record the prior login-success and support pattern for that customer. During the pilot, compare successful and failed sign-ins, wrong-destination redirects, MFA and SSO failures, post-login authorization denials, and support tickets. A healthy sitewide average can hide one broken enterprise customer, so review the cohort separately.
Agree on stop conditions and a human decision owner before launch. Expand only when the pilot’s failures are understood and the rollback has been exercised. Decommission the old login path after its remaining sessions and connected systems have an explicit disposition—not simply because the latest cohort can sign in.
Teams evaluating a move to Frontegg can start with the migration use case, then use the migration docs for supported user-import procedures and the prehook docs for the current routing surface. The cutover plan remains the application’s responsibility: decide who moves, prove the right tenant and resources remain protected, and know how to stop or reverse the move.
