docs: Add migration guide for moving off legacy serverpod_auth#585
Merged
Conversation
Swiftaxe
reviewed
Jun 9, 2026
…ependencies and sign-in process for migrated users
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Apps still on
serverpod_auth_serverneed a single, ordered path to the modular auth stack now that Serverpod 3.5 shipsserverpod_auth_core,_idp,_bridge, and_migrationas the supported lineage. PRs #302, #445, and #477 each covered a slice; none merged. This PR consolidates them into one guide aligned with the currentdocs/11-upgrading/layout that Jamiu's PR #563 just established.This PR:
docs/11-upgrading/03-migrate-from-legacy-auth.mdwith an ordered checklist covering dependencies,initializeAuthServicesconfig,AuthMigrations.migrateUsers, the password-importing email endpoint, Google legacy external ID handling, and the Flutter session import.passwords.yamlentriesJwtConfigFromPasswordsrequires (jwtRefreshTokenHashPepper,jwtHmacSha512PrivateKey,serverSideSessionKeyHashPepper,emailSecretHashPepper) so the server actually starts.Endpoints/Protocolname collision thatserverpod_auth_bridge_serverandserverpod_auth_migration_servercreate with the project's own generated classes, and shows theshow/hideclauses and file layout that resolve it.sidebar_label: Migrate from legacy authso the entry fits the Upgrading sidebar.Supersedes #302, #445, #477. Those PRs can be closed with a pointer to this one after merge.
End-to-end test
Built a 2.x scaffold (
serverpod_cli 2.9.3), addedserverpod_auth_server, applied legacy schema, seeded 3 users (email-only, Google-only, email), upgraded all pubspec entries to3.5.0-beta.9, configured the modular stack per this guide, applied the modular schema, and ranAuthMigrations.migrateUsers.Verification queries
```text
-- 3 legacy users mapped:
SELECT id, "oldUserId", "newAuthUserId" FROM serverpod_auth_migration_migrated_user;
id | oldUserId | newAuthUserId
----+-----------+--------------------------------------
1 | 1 | 019ea6e9-9d54-7a02-85a2-a9de9d2385fe
2 | 2 | 019ea6e9-9db8-72d7-9756-5fa71f456a55
3 | 3 | 019ea6e9-9ddb-72fc-889b-8f84b89c7eeb
-- 2 legacy passwords carried over (email users only, Google user excluded):
SELECT count(*) FROM serverpod_auth_bridge_email_password; -- 2
-- 3 external user IDs seeded (Google sub for Bob, email fallback for Alice + Carol):
SELECT "userIdentifier" FROM serverpod_auth_bridge_external_user_id;
-- 3 new AuthUser rows:
SELECT count(*) FROM serverpod_auth_core_user; -- 3
-- Idempotency: rerunning migrateUsers returned 0.
```
Closes serverpod/serverpod#5110
Closes serverpod/serverpod#3663
Closes serverpod/serverpod#3450