I’ve got Auth0 almost completely set up now for our production environment, and I am trying to finish it off with hooking in the migration of existing users with a custom database. I’ve followed all the steps here so far: https://auth0.com/docs/connections/database/migrating.
When doing my testing using the “Try” button on the Login script, I see the calls going to my legacy server as expected. I’ve named my new DB “Legacy-Database-Users-Do-Not-Remove” and enabled my client to use it as a connection along with the default “Username-Password-Authentication” where I plan on making my net new users going forward.
I am now not clear how to actually login using my client. When I get to the lock screen, there is no way to select a legacy database, and if I put in a user that only exists in the legacy database I don’t see any calls occur, just an error saying that I have the wrong user.
Should I instead be changing my main “Username-Password-Authentication” database to be a “custom” database, so there is only one database, or do I need to customize the lock page to select which database to use? Are there pro/cons to each approach that I should be considering?
To be clear about my use case, I want users who exist in my current legacy database to be able to login using their existing password, which will then automatically put them into my default connection and they will never hit my legacy database again. I do not want to migrate users from one connection to another and force them to re-set their password.
For the scenario you mentioned you should really only user database connection, in particular, that connection should be a custom database with the migration toggle enabled. When configured as mentioned an existing user in your legacy store will be authenticated by calling into your legacy user store in order to validate the credentials. However, this will only happen the first the end-user authenticates because at that time both the credentials and user profile information you return from the custom script will be moved to Auth0 storage; subsequent authentication requests for that user will be completed without calling into your legacy storage.
For completely new users (aka an end-user signing up for your service) the process will check if the user already exists either in Auth0 storage or in your own legacy store; if it does not yet exist it will be created directly in Auth0 storage so subsequent authentication from that user will also not due any calls to your legacy store.
In conclusion, the custom scripts will only have to actually perform live calls to your legacy store while there are still users to migrate. When you confirm that all users have been migrated you can update those scripts to provide canned responses and just switch off your legacy store. For example, signup would still want to try to check your store to see if the user already exists, but if you know the migration as completed you can provide a canned response in the get user script to signal that the user does not exists in the legacy store so that signup can be completed.
With the above, there will only be one database connection so using Lock will be much simpler.
Thanks! I was able to successfully able to get this working with this guidance.