Migrating from Stytch Consumer to B2B

At some point, you may find that Stytch's user-first Consumer data model no longer works for your use case, and you need to migrate to the organization-first B2B data model.

Migrating across Stytch data models requires some legwork, so please be sure to first consider your desired end state and login flows you'd like to maintain or add support for, based on your application and userbase.

For more information, please check out this guide on the differences between the two models.

• You are moving from a single-tenant to a multi-tenant model, and thus need Organizations to represent tenants and isolate data within each tenant.
• You require native SSO support and Trusted Auth Tokens do not fit your use case, and/or require JIT provisioning support.
• You require SCIM to enable end users to be managed by their workforce IdP.

In B2B authentication, the equivalent to a User is a Member.

Users must have an email and/or a phone number associated with them. On the other hand, Members must have an email address. Email addresses must be unique within an Organization, but can be shared for Members across multiple Organizations.

When updating your authentication flows, keep in mind that there are two different paths in B2B, in contrast with Consumer authentication: Discovery flows generally return an Intermediate Session Token and a list of discovered Organizations, and Organization-specific authentication endpoints require a specific organization_id to be passed in. For more information, please see this guide.

If you also support Passwords as an authentication method, please be sure to read through this guide to determine whether you want to use Cross-Organization or Org-Scoped Passwords, as you cannot change this setting once you have active Passwords.

Please note that most of these steps can be managed via Programmatic Workspace Actions or the API, either by using your existing infrastructure as code, or by getting the corresponding object and re-creating it with the B2B-specific API endpoint.

1. Create a new Project and select B2B SaaS Application. Add test environment(s) and Secrets, and update your credential store with the new Project IDs and secrets.
2. Configure Redirect URLs, Custom Domains, Custom Claims, Country Code Allowlists, RBAC policies, and any other Project-level settings that existed for your Consumer Project.
3. Create Connected App clients and M2M clients, and configure them with the corresponding Authorization URL and Scopes. Be sure to update your credential store with the new client IDs and secrets.
4. Configure authorized domains, enabled methods, authentication products, and session-related options in Frontend SDKs to match your Consumer Project.
5. Set up Email templates. Custom sender domains are shared across Projects within your Stytch Workspace and do not need to be reconfigured.
6. Configure DFP rules that existed for your Consumer Project. DFP is Project-agnostic and supports both Consumer and B2B, but DFP rules and overrides are specific to each Project.
7. Create Organizations, then migrate your Users by creating them as Members under their corresponding Organization(s). You can reference the steps in this guide to ensure best practices.
8. Lastly, switch out the Consumer endpoints (if you interact with the API) or methods (if you use the SDKs) for the B2B equivalents, and modify your application logic to account for this new tenancy model. You can feature flag these changes in conjunction with the previous step in a gradual roll out to minimze impact on your end users.

• Export Users from your Consumer Project with this export utility script