June 2026
All articlesMigrating Bubble users is not just about copying the User table. Bubble abstracts the authentication layer behind it, and that changes what a real user migration needs to handle.
The User table is one of the most important abstractions in Bubble. While it may look like a normal table, it is not just storing data, it is also connected to the authentication system, which makes migrations more complex.
A common assumption is that migrating users out of Bubble simply means migrating the User table.
But that is only part of the picture.
The User table contains the visible user data rows. What Bubble abstracts away from you is that user authentication is also part of the system, even though it is not exposed to you as a separate auth table.
That distinction matters because exporting the Bubble User table only gives you the user data. It does not recreate the authentication system in the destination.
So if you migrate only the rows, the new system may contain user-like records, but it still does not contain the actual auth identities needed for sign in.
In practice, that means users would need to sign up again in the new system, and their new accounts would not automatically be associated with their existing user data, which is a huge problem.
As you can see, migrating the Bubble User table correctly is not just about copying rows.
The proper process is:
User table into the target databaseUser table that points to auth.users as a foreign keyThat is the only way to preserve both:
Without that second step, you do not really have a completed user migration. You only have copied user data rows.
For security reasons, Bubble does not give you user passwords through the Data API.
For example, a response from the Data API when reading the User table can look like this:
{
"_id": "1703263107769x434791901267492860",
"Created Date": "2025-12-01T23:17:00.148Z",
"Modified Date": "2026-04-17T13:35:30.901Z",
"authentication": {
"email": {
"email": "account_x@gmail.com",
"email_confirmed": true
}
},
...
}As you can see, Bubble includes some authentication-specific data in the payload, such as the email, its confirmation status, and even OAuth data. However, no data regarding passwords is provided.
That means you can migrate the user records and create the destination auth accounts, but you cannot directly carry the original passwords over as plain migration data.
So in practice, users usually need to access the new system through a password recovery flow, invitation flow, magic link flow, or some other controlled reset path.
That does not mean the migration failed. It just means authentication credentials are not exported in the same way as normal database fields, so users will need to set up new credentials the first time they access your system. It is important to be aware of this so you can provide a good UX to your users.
The most important thing to understand is that exporting the Bubble User table is not the same as migrating user accounts.
The User table gives you the visible user data, but Bubble is also abstracting the authentication layer behind it.
A real migration needs to handle both parts properly.
Self-serve tools or a done-for-you service. Your app stays live while we move everything.