kinde-oss · tamalchowdhury · Apr 28, 2026 · Apr 28, 2026 · Apr 28, 2026 · Apr 28, 2026
@@ -0,0 +1,101 @@
+---
+page_id: df969c6a-b071-46fe-958a-df2a8f913428
+title: Migrate to Kinde from AWS Cognito
+sidebar:
+  order: 6
+  label: AWS Cognito
+tableOfContents:
+  maxHeadingLevel: 3
+relatedArticles:
+  - c4bc277a-5ec7-418c-ba1c-4d58c9ddfd7d
+  - f3dc6458-7d1e-407e-bc4c-62ac0ee4c075
+  - f6eaf29b-d8d9-4caf-bc1d-5319b6fb8ffc
+  - e89d246a-5cdf-4993-9cee-94b31ec27583
+description: Export users from AWS Cognito and migrate to Kinde. Because Cognito does not export passwords, drip-feed migration is the recommended approach for a seamless user experience.
+topics:
+  - get-started
+  - switch-to-kinde
+sdk: []
+languages:
+  - bash
+  - csv
+audience:
+  - developers
+  - admins
+complexity: advanced
+keywords:
+  - aws cognito migration
+  - cognito to kinde
+  - migrate from cognito
+  - cognito export
+  - user pool export
+  - drip feed migration
+  - admin user password auth
+updated: 2026-05-04
+featured: false
+deprecated: false
+ai_summary: How to export users from AWS Cognito and migrate to Kinde. Cognito does not allow password export, so drip-feed migration using the user:existing_password_provided workflow is the recommended approach for migrating users without forced password resets.
+---
+
+Migrate your users from AWS Cognito to Kinde. The main constraint is that Cognito does not allow password export, so a direct password migration is not possible.
+
+## Key considerations
+
+- **Passwords cannot be exported** — Cognito does not provide access to hashed passwords. Users imported from Cognito will need to reset their password or sign in via a new method — unless you use drip-feed migration.
+- **Drip-feed migration is the recommended approach** — using Kinde's `user:existing_password_provided` workflow, you can validate each user's password against Cognito on first login and migrate them seamlessly with no password reset required.
+- **No native export UI** — Cognito doesn't have a one-click export. You'll need to use the AWS CLI or write a script to paginate through the user pool.
+- **Enable `ADMIN_USER_PASSWORD_AUTH`** — if using drip-feed, ensure this auth flow is enabled on your Cognito App Client before starting the migration.
+- **Track migrated users** — maintain a record of which users have been migrated in your own database to avoid re-checking Cognito on every login.
+
+## Step 1: Export users from Cognito
+
+Cognito has no UI export. Use the AWS CLI to list users from your User Pool:
+
+```bash
+aws cognito-idp list-users \
+  --user-pool-id YOUR_USER_POOL_ID \
+  --region YOUR_AWS_REGION \
+  --query 'Users[*].{email:Attributes[?Name==`email`].Value|[0], sub:Username, name:Attributes[?Name==`name`].Value|[0]}' \
+  --output json > cognito-users.json
+```
+
+For large user pools, use `--pagination-token` to page through results, or use a script to loop until all users are retrieved.
+
+Convert the JSON output to a Kinde-compatible CSV with these columns:
+
+```text
+id,email,first_name,last_name,email_verified
+{sub},{email},{given_name},{family_name},TRUE
+```
+
+The `id` field should be the Cognito `sub` (the user's UUID in Cognito).
+
+## Choose your migration method
+
+### Drip-feed (recommended)
+
+Migrate users with no downtime and no password resets. On first login, a Kinde workflow validates the user's password against Cognito using the `ADMIN_USER_PASSWORD_AUTH` flow. If valid, the user is created in Kinde and their password is set.
+
+**Before you start:**
+1. [Bulk import](/get-started/switch-to-kinde/migrate-users-bulk-import/) user email addresses (without passwords) to seed Kinde with your user list.
+2. Ensure `ADMIN_USER_PASSWORD_AUTH` is enabled on your Cognito App Client.
+3. Enable **Enumeration protection** in Kinde: **Settings > Attack protection > Enumeration protection**.
+
+[Set up drip-feed migration →](/get-started/switch-to-kinde/drip-feed-migration/)
+
+The [full tutorial](/workflows/workflow-tutorials/drip-feed-migration/) includes the Cognito-specific workflow code.
+
+### Bulk import (with password reset)
+
+If drip-feed is not an option, import users by email only. Users will be prompted to set a new password or sign in via a passwordless method on first sign-in.
+
+1. Export emails and user details using the CLI command above.
+2. Prepare your CSV (no password columns).
+3. Enable passwordless sign-in or password authentication in Kinde.
+4. Follow the [bulk import guide](/get-started/switch-to-kinde/migrate-users-bulk-import/).
+
+## Next steps
+
+- If using drip-feed, monitor the workflow logs to confirm users are migrating successfully.
+- Once migration traffic from Cognito drops to zero, disable the workflow and decommission your Cognito User Pool.
+- For users who never log in during the migration period, decide whether to keep them (force a password reset via [the API](/get-started/switch-to-kinde/create-users-with-api/)) or remove inactive accounts.
@@ -0,0 +1,133 @@
+---
+page_id: d0e70a47-6e28-4a63-8215-76eec9fee0a0
+title: Migrate to Kinde from Azure B2C
+sidebar:
+  order: 7
+  label: Azure B2C
+tableOfContents:
+  maxHeadingLevel: 3
+relatedArticles:
+  - c4bc277a-5ec7-418c-ba1c-4d58c9ddfd7d
+  - f3dc6458-7d1e-407e-bc4c-62ac0ee4c075
+  - f6eaf29b-d8d9-4caf-bc1d-5319b6fb8ffc
+  - e89d246a-5cdf-4993-9cee-94b31ec27583
+description: Export users from Azure B2C and migrate to Kinde. Azure B2C does not export passwords, so choose between bulk import with password reset, API-based migration, drip-feed, or a hard cutover.
+topics:
+  - get-started
+  - switch-to-kinde
+sdk: []
+languages:
+  - bash
+  - csv
+audience:
+  - developers
+  - admins
+complexity: advanced
+keywords:
+  - azure b2c migration
+  - azure ad b2c
+  - migrate from azure
+  - azure b2c export
+  - user migration
+  - drip feed migration
+  - ropc
+  - resource owner password credentials
+updated: 2026-05-04
+featured: false
+deprecated: false
+ai_summary: How to export users from Azure B2C and migrate to Kinde, covering four migration methods including bulk import, API-based sync, drip-feed via ROPC, and hard cutover during a maintenance window.
+---
+
+Migrate your users from Azure B2C to Kinde. Azure B2C does not export passwords, so the migration approach you choose will determine how users authenticate on first sign-in.
+
+## Key considerations
+
+- **Passwords cannot be exported** — Azure B2C does not provide access to hashed passwords. Users will need to reset their password or use a new sign-in method, unless you use drip-feed migration.
+- **Drip-feed uses the ROPC endpoint** — the Azure B2C Resource Owner Password Credentials (ROPC) token endpoint allows the workflow to validate credentials on first login.
+- **Enable Enumeration protection** — before enabling drip-feed, go to **Settings > Attack protection > Enumeration protection** in Kinde and turn it on.
+- **Block registrations, not logins, during a maintenance window** — if using a hard cutover, blocking only new registrations (not logins) is sufficient since passwords are not being migrated.
+- **Local accounts vs. federated identities** — users who signed in via social providers (Google, Facebook, etc.) in Azure B2C can be imported by email and prompted to re-link their social login.
+- **MS Entra ID connection** — if you use Azure AD-based logins, [set up the MS Entra ID connection in Kinde](/authenticate/enterprise-connections/azure/) before importing users so Kinde can match them to the right connection.
+
+## Step 1: Export users from Azure B2C
+
+### Option A: Azure portal
+
+1. In the [Azure portal](https://portal.azure.com/), go to **Azure AD B2C**.
+2. Select **Users** from the left menu.
+3. Select **Download users** to export a CSV of all users.
+
+The portal export includes basic user properties (email, display name, object ID). It does not include passwords.
+
+### Option B: Microsoft Graph API (recommended for large user bases)
+
+Use the Microsoft Graph API to export users programmatically with full control over which attributes are included:
+
+```bash
+GET https://graph.microsoft.com/v1.0/users?$select=id,displayName,mail,userPrincipalName,accountEnabled
+Authorization: Bearer {access_token}
+```
+
+Paginate using the `@odata.nextLink` value in the response. Convert the output to a Kinde-compatible CSV.
+
+**Column mapping:**
+
+| Azure B2C field | Kinde column |
+|-----------------|--------------|
+| `id` | `id` |
+| `mail` or `userPrincipalName` | `email` |
+| `givenName` | `first_name` |
+| `surname` | `last_name` |
+| `accountEnabled` | `email_verified` (use `TRUE`/`FALSE`) |
+
+## Choose your migration method
+
+### Drip-feed (recommended)
+
+Migrate users seamlessly as they log in. A Kinde workflow validates each login against Azure B2C's ROPC endpoint, creates the user in Kinde on success, and takes over authentication going forward.
+
+**Before you start:**
+1. [Bulk import](/get-started/switch-to-kinde/migrate-users-bulk-import/) user email addresses (without passwords) to seed Kinde.
+2. Enable **Enumeration protection** in Kinde (**Settings > Attack protection > Enumeration protection**).
+3. Enable the ROPC user flow in your Azure B2C tenant.
+
+[Set up drip-feed migration →](/get-started/switch-to-kinde/drip-feed-migration/)
+
+The [full tutorial](/workflows/workflow-tutorials/drip-feed-migration/) includes the Azure B2C-specific workflow code.
+
+### Bulk import with API sync (catch new registrations)
+
+Export users and import into Kinde. During the migration window, use the Kinde API to push any new sign-ups from Azure B2C directly to Kinde so no one is missed.
+
+1. Set up an API integration to push new Azure B2C registrations to Kinde in real time.
+2. Export existing users using the portal or Graph API.
+3. Import into Kinde via [bulk import](/get-started/switch-to-kinde/migrate-users-bulk-import/).
+4. Switch to Kinde.
+5. Users will be prompted to set a new password or sign in via passwordless on first sign-in.
+
+See [Create users with the API](/get-started/switch-to-kinde/create-users-with-api/) for the Kinde API steps.
+
+### Bulk import only
+
+Simplest option. Export users, import into Kinde, switch. No API integration needed.
+
+1. Export users using the portal or Graph API.
+2. Re-import before cutover to catch any new registrations.
+3. Follow the [bulk import guide](/get-started/switch-to-kinde/migrate-users-bulk-import/).
+4. Users set a new password or sign in via passwordless on first sign-in.
+
+### Hard cutover (maintenance window)
+
+For the cleanest cutover when a short service interruption is acceptable:
+
+1. Block new registrations in Azure B2C (not logins — since passwords aren't migrated, existing logins don't affect the migration).
+2. Export all users.
+3. Import into Kinde via [bulk import](/get-started/switch-to-kinde/migrate-users-bulk-import/).
+4. Switch to Kinde.
+5. Users set a new password or sign in via passwordless on first sign-in.
+
+## Next steps
+
+- If using drip-feed, monitor the workflow logs to confirm users are migrating successfully.
+- Once migration traffic from Azure B2C drops to zero, disable the workflow and decommission your Azure B2C tenant.
+- Notify users of the change before go-live — especially that they will need to verify their email or set a new password on first sign-in.
@@ -0,0 +1,115 @@
+---
+page_id: 8b3e1d47-2f96-4a0c-c8d5-6e7a2b9f3150
+title: Migrate to Kinde from Clerk
+sidebar:
+  order: 3
+  label: Clerk
+tableOfContents:
+  maxHeadingLevel: 3
+relatedArticles:
+  - c4bc277a-5ec7-418c-ba1c-4d58c9ddfd7d
+  - f6eaf29b-d8d9-4caf-bc1d-5319b6fb8ffc
+  - b338980f-7dd6-4ba5-90aa-330247a45536
+  - e89d246a-5cdf-4993-9cee-94b31ec27583
+description: Export users and hashed passwords from Clerk and import them into Kinde. Clerk supports bcrypt exports, so users keep their existing passwords.
+topics:
+  - get-started
+  - switch-to-kinde
+sdk: []
+languages:
+  - csv
+audience:
+  - developers
+  - admins
+complexity: intermediate
+keywords:
+  - clerk migration
+  - clerk to kinde
+  - migrate from clerk
+  - user import
+  - password migration
+  - hashed passwords
+  - csv import
+  - authentication migration
+  - clerk export
+updated: 2026-05-04
+featured: false
+deprecated: false
+ai_summary: How to export users and hashed passwords from Clerk and import them into Kinde. Clerk exports bcrypt-hashed passwords which Kinde supports natively, so users can sign in without resetting their password.
+---
+
+Migrate your users from Clerk to Kinde. Clerk supports exporting hashed passwords, and Kinde supports bcrypt — so your users can sign in with their existing passwords without a forced reset.
+
+## Key considerations
+
+- **bcrypt passwords are fully supported** — Kinde imports bcrypt hashes directly. Users keep their existing password with no reset required.
+- **No drip-feed needed** — because passwords can be migrated cleanly, a straightforward bulk import is the recommended approach for most Clerk migrations.
+- **File format** — Clerk exports a CSV file. You'll need to map the Clerk column names to Kinde's expected column names before importing.
+
+## Migration guide
+
+### 1. Export users from Clerk
+
+1. Sign in to your [Clerk dashboard](https://dashboard.clerk.com/apps).
+2. Select the application you are exporting users from.
+3. Go to **Configure > Settings**.
+4. Under **User exports**, select **Export users**.
+5. When the export is ready, select **Download**. This downloads a CSV file.
+
+![Clerk export users](https://imagedelivery.net/skPPZTHzSlcslvHjesZQcQ/466e727b-0a72-4475-a019-4a685579a200/socialsharingimage)
+
+See Clerk's documentation on [exporting users](https://clerk.com/docs/guides/development/migrating/overview#export-your-users-data-from-the-clerk-dashboard).
+
+### 2. Map Clerk columns to Kinde's CSV format
+
+Modify your Clerk CSV to use the column names Kinde expects. The only required column is `email` — everything else is optional but recommended.
+
+**Required:**
+
+| Column | Notes |
+|--------|-------|
+| `email` | Minimum required field |
+
+**Password columns (recommended — preserves existing passwords):**
+
+| Column | Notes |
+|--------|-------|
+| `hashed_password` | The user's bcrypt-hashed password from Clerk |
+| `hashing_method` | Set this to `bcrypt` for all Clerk exports |
+
+**Recommended:**
+
+| Column | Notes |
+|--------|-------|
+| `first_name`, `last_name` | User's name |
+| `email_verified` | `TRUE` or `FALSE` |
+| `id` | Clerk user ID — helps match records on re-import |
+| `phone` | International format, e.g. `+61555111555` |
+| `external_organization_id` | Organization ID (if applicable). Comma-separate multiple values |
+| `role_key` | Role key(s) to assign. Comma-separate multiple values |
+| `permission_key` | Permission key(s) to assign. Comma-separate multiple values |
+
+<Aside title="Enable password authentication first">
+
+If you are importing hashed passwords, enable password authentication in Kinde before importing. See [Password authentication](/authenticate/authentication-methods/password-authentication/).
+
+</Aside>
+
+### 3. Import into Kinde
+
+1. In Kinde, go to **Users**, then select **Import users**.
+2. Select **Custom CSV**.
+3. Follow the on-screen prompts to upload your file.
+4. Review any errors reported after import. Fix the CSV and re-import to resolve them.
+
+See the [bulk import guide](/get-started/switch-to-kinde/migrate-users-bulk-import/) to learn more.
+
+## Troubleshooting
+
+Review the CSV for missing or duplicated values before importing. Kinde flags errors during import and reports them. Most errors can be fixed by editing the CSV and re-importing — records already imported without changes are skipped.
+
+## Next steps
+
+- Verify users can sign in to Kinde with their existing Clerk credentials.
+- Notify users of any changes to their sign-in experience before going live.
+- [Get support](/get-started/get-support/) if you need help with your migration.