User accounts + auth
What Happens to Your Base44 Users When You Migrate
OffRamp · November 5, 2026 · 8 min read
Short answer: your users move — their logins don't. The names, emails, and roles in your user list come with you. The passwords, the live sessions, and the Google and Apple connections Base44 holds do not. Nobody loses their account; everybody signs in once more, with a fresh password. This page maps the split piece by piece, so you can tell your users exactly what to expect.
The good news first
What moves: your users' profile records
Start with what is not a problem. Your user list is data, and data moves. Every Base44 app has a built-in User entity — the roster of everyone who signed up, with their name, email address, and role. That entity is readable from inside your own app: a backend function running with the service role can list every user profile, and the profiles copy across to the new system with their fields intact.
Roles matter here, and they travel with the profiles. If your app has admins, members, and read-only users, those roles are part of the profile record — carry each user's role into the new system, because the permissions your app enforces depend on it. Before cutover, test the sign-in and the permissions on one user per role, so a role that silently failed to carry does not lock someone out on launch day.
So the roster is safe. What your users built, bought, or saved inside the app is safe too — that lives in your database tables, which export one at a time as CSV. The user question is narrower than the data question, and it is also simpler: the people move. It is the keys to their accounts that do not.
The hard part
What doesn't move: passwords
Here is the sentence to plan around: there is no way to export your users' passwords from Base44. Base44's documentation and dashboard offer no export for password hashes. The User entity exposes profile fields — name, email, role — not credentials. Every independent migration guide says the same thing, because it is the same fact from every angle: passwords do not transfer between auth systems unless the old system hands over the hashes, and Base44 does not.
That is the secure design, not an oversight. Password hashes that could be copied out by an app owner could also be copied out by anyone who got into the account. Base44 keeps them locked in its own auth system, behind the login pages it builds for you — the same pages that handle your users' sign-ups, email verification codes, and password resets today. The lock-in is a side effect of a real security boundary.
The fix is the standard one, and it is a single email, not a project: on cutover day, every user who signed in with an email and password gets a password-reset email from the new system, and sets a fresh password once. Their account, data, and role are already waiting for them — the reset is the only step that belongs to them. Tell them in advance, in plain language, and almost nobody will be surprised by it.
The rest of the login
What doesn't move: sessions, Google logins, and SSO
Passwords are the headline, but three more pieces of the login stay behind with them. First, sessions. When your users sign in to a Base44 app, Base44 keeps them signed in with HTTP-only cookies on Base44's domain. Those sessions live on the platform, not in your data, so they die the day the app leaves. Every user signs in again the first time they open the migrated app. That is a one-time inconvenience, not a data loss — but warn them, or the first support tickets after launch will all be the same confused question.
Second, social logins. If your users signed in with Google, that connection runs on Base44's OAuth client by default — Base44's own docs say the Google consent screen shows "base44.com" unless you set up a custom OAuth client with your own Google Cloud credentials. Either way, the connection belongs to Base44's side of the arrangement and does not move. On the new stack you set up your own Google OAuth client, and each user re-consents once, with the same Google account. The same is true for Microsoft, Facebook, and Apple sign-in: Apple login runs on Base44's own Apple credentials, so it is re-created on your side too. One edge case to check before you migrate: users who signed in with Apple and chose to hide their email got a private Apple relay address instead of their real one — make sure your profile export has a reachable address for every user before you send reset emails to addresses that cannot receive them.
Third, SSO — and here it pays to keep two things straight. Workspace SSO, like Microsoft Entra ID, signs your building team into the Base44 workspace; app-level SSO signs your app's users in, and on Base44 it is mutually exclusive with social login. Whichever kind you use, the connection is registered inside Base44 and has to be re-registered against the new auth system before cutover. Do that before the reset emails go out, so SSO users have a working door on day one instead of a reset link they do not need.
How the rebuild works
How OffRamp rebuilds your users' auth
The rebuild follows the split above, in order. First, the profiles: every user record is pulled from the User entity — name, email, role — and recreated as an account on the new auth system, in your own Supabase project, with the roles carried over. Then the sign-in: email-and-password users get a reset email each, so they set a fresh password once; users who signed in with Google, Microsoft, or Apple re-link by signing in with the same provider account through your own OAuth client; SSO users get the re-pointed identity provider.
Nothing about this requires your users to re-register, re-verify an email they already verified, or rebuild anything on their side. The account they had is the account they get back, under the same email, with the same role and the same data attached. The only thing that changes for them is the password — once — and the sign-in screen, which now says your app's name instead of Base44's. That is the whole user-facing cost of the hardest piece of the migration, and it is worth saying plainly in the cutover email: your account moved with the app; please set a new password.
If you are weighing the move and the user question is what is holding you back, that is the right instinct — auth is the piece that touches every user at once, and it deserves a careful cutover. But it is a solved piece: profiles out, accounts recreated, one reset email each, and your users are yours again, on infrastructure that answers to you. The migration guides that cover this ground all land in the same place, because there is only one honest version of the story: the people move, the passwords don't, and one email closes the gap. Our security guide covers the other half of the same question — what "safe" means once the app is yours.
FAQ
Questions, answered honestly
What happens to my Base44 users when I migrate?
Their profile records move — names, email addresses, and roles — but their logins do not. Passwords, live sessions, and the social-login connections Base44 holds stay behind. On the new stack every account is recreated from the exported profile list, and each user sets a fresh password once, by email.
Can I export my users' passwords from Base44?
No. Base44's docs and dashboard offer no export for password hashes — the User entity exposes profile fields, not credentials. That is the secure design, not an oversight: hashes that could be copied out could also be stolen. The standard, safe move is a password-reset email to every email-and-password user on cutover day.
Do my users have to create new accounts after migration?
No. Their accounts are recreated for them on the new system, with the same email addresses and the same roles. The only thing each user does is set a new password once, from the reset email. Their data, history, and permissions travel with the profile — the sign-in is the only part that is rebuilt.
What happens to users who signed in with Google?
They sign in with Google again — same Google account, new connection. On Base44, default Google login runs on Base44's own OAuth client (the consent screen shows base44.com); that connection belongs to Base44 and does not move. On the new stack you set up your own Google OAuth client, and each user re-consents once. If you had already switched to a custom OAuth client on Base44, the same client can be reused.
What happens to SSO users when I leave Base44?
SSO has to be re-pointed, because the connection lives in Base44. Keep the two kinds straight: workspace SSO (for example Microsoft Entra ID) signs your building team into the Base44 workspace, while app-level SSO signs your app's users in — and app SSO is mutually exclusive with social login on Base44. Either way, the identity provider is re-registered against the new auth system before cutover, and users sign in through it again.
Will my users be signed out during the migration?
Yes, once — at cutover. Base44 sessions are HTTP-only cookies on Base44's domain, so they die with the platform. Every user signs in again the first time they open the migrated app, with their new password or their Google account. Plan the cutover email for that moment: one message, one reset link, and the reason in plain language.
Your users stay yours — their logins just need one reset
Profiles move, passwords don't, and one email closes the gap. Migrate your app off Base44 onto Supabase, Vercel, and GitHub accounts in your name: your users recreated with their roles intact, reset emails handled, and the app verified live before the old one retires. Connect the Base44 account from the OffRamp home page. The free analysis takes about a minute, and your fixed quote comes with it.
Start your free analysis