> ## Documentation Index
> Fetch the complete documentation index at: https://stytch.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Migration overview

> Migrate your app's existing authentication system over to Stytch.

export const sso = "Authentication process allowing users to access multiple applications with one set of credentials.";

export const organization = "Represents an instance or tenant in your application, typically mapping to each of your top-level customers.";

export const member = "Represents an individual end user's account within a given Organization, uniquely identified within that Organization by their email address.";

export const userTip = "Represents an end user's account in your application.";

Migrating your authentication setup can seem daunting, but this guide will walk you through everything you need in order to run a smooth, zero-downtime migration to Stytch from any authentication setup, whether it's an in-house build or from a legacy provider like Auth0 or Cognito.

<Tabs>
  <Tab title="Consumer auth">
    This migration guide covers the process of migrating your app's existing authentication system over to Stytch. Here we provide generalized guidance which applies to any authentication setup, including authentication built in-house as well as Auth0, AWS Cognito, and Google Firebase.

    <img src="https://mintcdn.com/stytch-34ca0595/jCmOQoXV28mXNOhP/images/consumer/from-old-docs/migrate-to-stytch.svg?fit=max&auto=format&n=jCmOQoXV28mXNOhP&q=85&s=d4d927e7b4b510ef3ed58364d19cac08" alt="migration image" width="1537" height="631" data-path="images/consumer/from-old-docs/migrate-to-stytch.svg" />

    ## Before you start

    This set of migration guides assumes you are using Stytch's Consumer APIs and SDKs. If you are using our B2B APIs, please see the [B2B migration guide](#b2b-auth).

    In order to complete any of the migration guides, you'll need the following:

    * A [Stytch](https://stytch.com/start-now) account if you don't have one already.
    * A Stytch Consumer Auth project. If you don't have one already, in the [Dashboard](https://stytch.com/dashboard), click on your projects in the top nav, click **Create Project**, and then select **Consumer Authentication**.
    * The `project_id` and secret for the **Test environment** you would like to use. These values can be accessed from the [Project ID & API keys](https://stytch.com/dashboard) section of the Project Overview. You'll need to pass these values into the Authorization request header for most Stytch API calls.

    ## Key questions and considerations

    Before you start, you should consider the following questions about your migration requirements:

    * What are your application surface areas? Do you have a web app, mobile app, or both?
    * Does your user base use passwords? Are there passwordless users? A mix of both?
    * How many authentication factors do your users have? Do your users have only one primary factor like email? Or multiple factors like email and phone?
    * Where is authentication handled in your stack? Will you be integrating the Stytch API and SDKs into your backend or frontend?

    ## Migration guides

    Depending on how you answered the previous questions, our recommended approaches and strategies will differ. We've split them into multiple step-by-step guides organized by migration use cases:

    1. [Static data migration strategy](/resources/migrations/migrating-user-data#static-migration-recommended-for-passwords)
    2. [Dynamic data migration strategy](/resources/migrations/migrating-user-data#dynamic-rolling-migration-recommended-for-passwordless)
    3. [Migrating authentication related logic](/resources/migrations/additional-migration-considerations#consumer-auth)
    4. [Deploying your Stytch integration to production](/resources/migrations/zero-downtime-deployment)
    5. [Exporting from Stytch](/resources/migrations/exporting-from-stytch#consumer-auth)

    To understand if migrating data statically or dynamically is a better strategy for you, see our high level recommendations below:

    <img src="https://mintcdn.com/stytch-34ca0595/jCmOQoXV28mXNOhP/images/consumer/from-old-docs/migration-strategy-chart.svg?fit=max&auto=format&n=jCmOQoXV28mXNOhP&q=85&s=c942886883f6c092283c06bae5108a65" alt="migration strategies" width="1413" height="599" data-path="images/consumer/from-old-docs/migration-strategy-chart.svg" />

    ## What's next

    To start, we recommend checking out the migrating user data guides — [statically](/resources/migrations/migrating-user-data#static-migration-recommended-for-passwords) or [dynamically](/resources/migrations/migrating-user-data#dynamic-rolling-migration-recommended-for-passwordless).
  </Tab>

  <Tab title="B2B auth">
    Below is a high level overview of the sequenced steps involved in migrating to Stytch. Each step has its own detailed guide that will walk you through the key decisions and considerations based on your current authentication setup.

    <Steps>
      <Step title="Define your data model">
        The first step of planning your migration to Stytch is planning out how you want to connect your current data model to Stytch's core entities: <Tooltip tip={organization}>Organization</Tooltip> and <Tooltip tip={member}>Member</Tooltip>.

        If you're unsure how your end user and tenant entities should map to Stytch's Members and Organizations, the [reconciling data models guide](/resources/migrations/reconciling-data-models#b2b-auth) covers the key considerations around multi-tenancy, account deduplication and more.
      </Step>

      <Step title="Dual-write and backfill members and organizations">
        In order to achieve a smooth, zero-downtime migration without any issues around data reconciliation, we recommend setting up dual-writes prior to kicking off a backfill to Stytch. This allows any create, update, or delete requests during the backfill period are reflected in both your current system as well as in Stytch, ensuring that you can cut over to Stytch as the read source of truth without any customer impact or downtime.

        However, if you have a relatively small user base you can always run the backfill without a dual write.

        For more details setting up the dual-write, backfill and considerations depending on if you're coming from an in-house build or a legacy provider like Auth0, check out the [migrating user data guide](/resources/migrations/migrating-user-data#b2b-auth).
      </Step>

      <Step title="Migrating other data and logic">
        Depending on your current system and offerings you might need to migrate other data to Stytch, such as:

        * <Tooltip tip={sso}>Single Sign-On (SSO)</Tooltip> Connections
        * Roles and permissions
        * Ingesting events
        * Password policies

        Review [additional migration considerations](/resources/migrations/additional-migration-considerations#b2b-auth) to see if any of these apply to your migration.
      </Step>

      <Step title="Cutting over to Stytch">
        If you're migrating to Stytch from Auth0 (or other 3rd party providers that use OIDC JWTs) we offer a **Zero-Downtime Session Migration** feature that allows you to mint Stytch Sessions from an external session -- ensuring that your users can stay logged in as your cutover to Stytch.

        We discuss the details of how this works, and alternative deployment strategies if you're moving from in-house or a non-OIDC compliant authentication provider in the [zero down-time deployment](/resources/migrations/zero-downtime-deployment#b2b-auth) guide.
      </Step>

      <Step title="You're done!">
        You've switched to Stytch! Time to cut a satisfying PR to delete the deprecated code!
      </Step>
    </Steps>
  </Tab>
</Tabs>