Move an existing application to Udibo
Treat migration as two connected changes: your application starts trusting a new issuer, and your users gain identities in that issuer. You can prepare and test both before changing the login most customers see.
The hosted service is in private beta, and user import is operator-run. Coordinate access, the import method, and the cutover with Udibo before setting a launch date. There is no self-serve import endpoint or automatic ongoing sync.
1. Inventory what your current login does
List the behavior your users rely on, not just the SDK imports:
| Area | Questions to settle |
|---|---|
| Identities | Which stable user IDs does your app store? Can you export verified-email state and social provider subjects? |
| Credentials | Can the provider export password hashes? What exact algorithms, parameters, and encodings are present? |
| Recovery | Which password-reset, MFA, passkey, and email-verification flows must survive? |
| Authorization | Where do organization membership, roles, resource ownership, and paid entitlements live? |
| Sessions | Which cookies, token audiences, refresh behavior, and logout promises does the app depend on? |
| Integrations | Which webhooks, enterprise connections, mobile deep links, and background jobs use the current provider? |
Use the comparison for your current product to identify its particular migration questions. Hosted passkeys, SAML, and SCIM are not available in Udibo today; resolve any such dependency before attempting a move.
2. Connect a test application first
Complete your first sign-in with a development registration and test accounts. Keep the current login available while the new callback, session storage, and API validation are being tested.
If your app already uses OIDC, start with its existing standards-based client. Compare discovery, claims, audience, logout, and refresh expectations before replacing application code. A shared protocol does not make provider-specific SDK hooks or management APIs interchangeable.
When accepting both providers during a rollout, validate each against its own configured issuer, keys, and audience. Do not let unverified token content choose an arbitrary issuer or disable verification to accept both.
3. Preserve the connection to your product data
Keep your application's existing user ID where possible. Add an explicit mapping
from the old external identity to the new (issuer, subject) identity. Test
that the mapping still finds the person's projects, purchases, and organization
memberships.
Do not merge accounts solely because two records contain the same email address.
Resolve duplicate or ambiguous identities before rollout using verified
ownership and a reviewed mapping. Treat imported social identities as
(provider, subject) pairs, not display names.
Your application's role assignments and resource ownership are a separate migration. Importing a user does not reproduce the authorization model from another product. Recreate and test the necessary organizations and permissions.
4. Choose a credential strategy
| Situation | Plan |
|---|---|
| You can export a supported password-hash format | Use the user import format; a successful sign-in upgrades the imported credential |
| The provider cannot export hashes, or the encoding is unsupported | Import the account without a password and plan a supported recovery or sign-in flow |
| The account uses only a social provider | Import its supported provider/subject association and verify the connection configuration |
| You run authentication in your own app instead of using the service | Use the package migration guide and your own storage implementation |
The hosted importer accepts a defined subset of bcrypt, PBKDF2, and scrypt encodings. It does not accept Argon2 or every provider's format. Read the exact limits before promising a migration without password resets. A password import does not transfer MFA enrollments, passkeys, active sessions, or refresh tokens.
Agree on a secure transfer channel with Udibo before sending credential material. Do not email password exports or put them in an issue or agent chat.
5. Rehearse a small cohort
Include a password user, a social-only user, a user needing recovery, a user with multiple organizations, and a disabled user. Test successful behavior and refusals: an invalid password, a revoked session, an unverified email, and a request for another customer's data.
Reconcile the import's accepted, skipped, and rejected records. A repeated import is not an incremental synchronization mechanism; existing live-email accounts are skipped. Decide how you will handle accounts created or changed between the export and cutover.
6. Cut over with a rollback plan
Write down the rollout cohort, the final export window, how users will sign in, and who can pause the change. Keep the old provider available for the agreed rollback period. Do not immediately delete credentials, mappings, or the configuration needed to return traffic to it.
Rollback also needs a data plan: an account created only in Udibo will not automatically exist in the previous provider, and a password changed after cutover will not automatically work there. Resolve those cases before widening the rollout. Watch sign-in failures, recovery requests, and authorization refusals as each cohort moves.
Next: prepare the import file and review production readiness.
Last verified 2026-09-06.