JIT Migration

Summary

Just-In-Time (JIT) Migration migrates users on their first login after cutover. When a user attempts to log in, the system checks if they exist in the new provider. If not, it authenticates them against the old provider, creates their account in the new provider, and redirects them to complete the login. This provides the best user experience for active users with no mass password resets required.

When to Use

This strategy works best when:

  • You have an active user base where most users log in regularly
  • You want to avoid mass password resets
  • You can tolerate migration happening over time (not all at once)
  • You have a proxy or middleware layer that can handle the migration logic
  • You want the best possible user experience

Pros

  • No mass password resets - users keep existing passwords
  • Best user experience for active users
  • Migration happens naturally as users log in
  • No support ticket spike from password resets
  • Works well for active user bases

Cons

  • Requires proxy/middleware to handle migration logic
  • Dormant users never migrate automatically
  • More complex implementation than bulk reset
  • Social logins need special handling
  • Full password continuity not always possible (depends on providers)

Typical Flow

  1. 1User attempts to log in to your application
  2. 2System checks if user exists in new provider
  3. 3If not found, authenticate user against old provider
  4. 4If authentication succeeds, create user in new provider
  5. 5Handle callbacks and redirects appropriately
  6. 6User completes login in new provider
  7. 7Future logins use new provider directly
Redirect Allowlists & Branding: Configure redirect URLs in both providers and ensure your branding is consistent. The process builder helps orchestrate the migration flow.

Social Logins Considerations

Social logins require special handling in JIT migration:

  • Linking identities: When a user logs in with a social provider, you need to check if that social identity is already linked to a user in either provider
  • Account merging: If a user has accounts in both providers (e.g., email in old, social in new), you may need to merge them
  • OAuth redirects: Ensure OAuth redirect URLs are configured correctly in both providers
  • Provider differences: Different providers handle social logins differently - plan for edge cases

Password Continuity / Reset Expectations

JIT migration aims to preserve passwords, but full continuity depends on provider capabilities:

  • Password hashing compatibility: If providers use compatible hashing algorithms, passwords can be preserved
  • Provider limitations: Some providers don't support importing password hashes, requiring users to reset
  • Fallback to reset: If password preservation isn't possible, users may need to reset on first login (but only once, not a mass reset)
  • MFA considerations: MFA state may need to be re-established in the new provider
Full password continuity is not always possible. Some provider combinations don't support importing password hashes. In these cases, users will need to reset their password on first login, but this is still better than a mass reset because it only affects active users as they log in.

Operational Checklist

Before Migration

  • Set up proxy/middleware layer for migration logic
  • Configure redirect allowlists in both providers
  • Test authentication flows with both providers
  • Plan for social login edge cases
  • Set up process builder for migration orchestration
  • Test with a small user cohort
  • Verify branding consistency across providers

During Migration

  • Update application to use proxy/middleware
  • Monitor migration success rates
  • Track users migrating on first login
  • Handle edge cases and errors gracefully
  • Monitor performance impact of dual-provider checks

After Migration

  • Monitor migration completion rate over time
  • Handle dormant users (may need separate strategy)
  • Decommission old provider after migration period
  • Archive migration logs

Common Pitfalls

  • No proxy layer: JIT requires middleware to handle the migration logic. Don't try to implement this in your application code.
  • Redirect loops: Incorrect redirect configuration can cause infinite loops. Test thoroughly.
  • Dormant users: Users who never log in won't migrate. Consider hybrid approach for inactive users.
  • Social login complexity: Linking identities across providers is complex. Plan for edge cases.
  • Performance impact: Dual-provider checks add latency. Monitor and optimize.