Auth0's lazy migration changes on 20 January 2027, and half-imported users won't fix themselves

If your Auth0 tenant still pulls users across from an old database as they log in, the way that import finishes is about to change. Auth0 retires Legacy Custom DB User Import on 20 January 2027. Turn the new behaviour on in a test tenant first, and clean up the users who are already stuck halfway, because the change won't touch them.

This one is short notice by Auth0's own standard. Its migration process page says it tries to give at least six months between announcing an end of life and enforcing it. Here it's about three, and the holidays sit in the middle. If your change freeze starts in mid-December, you've really got about five weeks to test.

Nothing breaks for people who log in normally. The risk is in the edges, and in what you've built around them. A user who clicks a reset link now gets a full Auth0 profile on the spot, built from whatever your Get User scriptdefinitionYour script that asks the old database whether a person exists and what's on their record. Auth0 runs it at sign-up, password changes and logins. From January its answer can become the stored profile, so sloppy output sticks. returns. Reports, exports and sync jobs that read users through the Management API will start counting people who've never logged in to Auth0. Those people used to be invisible.

Then there's the backlog. Auth0 says profiles already stuck in a partial importdefinitionA half-finished migration. Auth0 has stored the user's data and password, but there's no normal user profile, so the person doesn't appear in the Dashboard or the Management API. stay stuck, even when the person goes through the same flow again. One developer on Auth0's community forum described what a stuck record can look like from the outside: a reset flow where the user lookup comes back empty, but creating the user fails with "The user already exists." Auth0's migration guide reads that as a record that's in its internal store but not in your tenant.

Step four is our reading, so test it before you rely on it. Auth0's migration guide says the Login script only runs for users who aren't in the Auth0 store yet. The deprecation notice says a reset imports the user without their old password. Put the two together and someone who abandons a reset can't log in with the old password any more. Auth0 doesn't say this in so many words, so try it in a dev tenant and write down what you see.

The table carries most of it, but one row deserves a second look. Auth0 lists network failures that interrupt a login as one cause of partial imports, then only describes the new outcome for the reset and breach cases. So don't assume every way of ending up half-imported goes away in January. Keep watching for duplicate-user errors after the switch, too.

You can do nothing. Auth0 flips every remaining tenant on 20 January regardless, so what you give up is choosing when the problems show up. The table lays out the routes we'd weigh. For most teams, switching early is the right call.

The third route only makes sense when most users have already moved. Auth0's guide says to confirm every user from the old store is in Auth0 before disconnecting. Then you change the Login and Get User scripts to return nothing, and leave Import Users to Auth0definitionThe switch on a custom database connection that turns lazy migration on. With it on, Auth0 copies each user into its own store after a successful login. switched on. One developer on Auth0's forum hit a related trap in a different setup. Accounts created while the connection ran in passthrough mode, before a bulk import, couldn't log in once the old database was cut off.

# example: removes one stuck user, so they can log in and migrate again
# needs a Management API token with delete:users
CONN_ID="con_XXXXXXXXXXXX"
EMAIL="[email protected]"
curl -s -X DELETE \
  -H "Authorization: Bearer $MGMT_TOKEN" \
  "https://$TENANT.auth0.com/api/v2/connections/$CONN_ID/users?email=$EMAIL"
# afterwards the user logs in or resets, and the import starts over

That call is Auth0's Delete a connection user endpoint, one of the fixes its migration guide gives for DUPLICATED_USER errors. It works by email, one user at a time, and only on database connections. Run it in a dev tenant first. Make sure the person really is stuck, because deleting a working user throws away their Auth0 data. URL-encode the email if it contains a plus sign, and check each response code before you move to the next user.

We plan and run Auth0 migrations, including custom database connections. For this change that means reviewing your Login and Get User scripts, running the test cases in a dev tenant, and clearing stuck users before you switch. If you've still got Rules or Hooks to move, read our post on the Auth0 Rules and Hooks deadlines too. See our Auth0 page for how we work, or book an assessment if you'd like us to look at your tenant.