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.