MVP auth is fine until it’s not. Most teams ignore the “not” signals for one quarter too long, and end up migrating under duress — during an incident, a compliance review, or a customer crisis. Here’s how to recognize the signals early and migrate without pain.
The four signals
1. You’ve been paged for auth twice this quarter
MVP auth is simple code. When simple code fails at 2am, it’s usually because it hit a scale or edge case you didn’t anticipate. One incident is noise. Two is the system telling you it’s outgrown its design.
2. A customer asked for SSO and you stalled the deal
This is the one that costs you money. Enterprise SSO (SAML, SCIM) is a weeks-to-months integration if your auth wasn’t architected for it. If you’re at the “I’ll get back to you on SAML” stage with a qualified buyer, migration is overdue.
3. You’re hashing with something weaker than Argon2id
If your auth code has comments like // TODO: upgrade from MD5 or // using SHA-256 for now, will switch to bcrypt — you already know. Weak hashing is a compliance finding and a breach waiting to happen.
4. Your sessions table is over a million rows
Not necessarily broken — Postgres handles a million rows fine — but it’s the symptom that your auth system is doing more than it was designed to. Session cleanup jobs, index strategy, multi-tenant filters: these were afterthoughts in MVP. They’re now your biggest performance variable.
The migration path
A good auth migration is incremental. You don’t flip a switch; you phase in a new system while the old one still runs.
Phase 1: Stable user ID
Make sure every user has a stable, immutable ID that’s separate from their email. If your primary key is the email (a classic MVP shortcut), fix this first. It’s the pivot everything else hangs on.
Phase 2: New auth system runs alongside
Deploy your new auth (managed service or new internal system) in parallel. Don’t migrate users yet. Route new signups to the new system.
Phase 3: Lazy migration
Each existing user migrates on next sign-in. The user enters their password; your old system verifies it; if valid, create the user in the new system (by ID), issue a new session from the new system, delete the old session. Done. User noticed nothing.
Phase 4: Forced migration
After 90 days, users who haven’t signed in get a “verify your account” email with a migration link. Clicks the link, goes through the new system’s sign-up.
Phase 5: Decommission
Once 99%+ of users have migrated, you can safely turn off the old system. Keep the user data available for support edge cases, but the live auth flow is entirely new-system.
What not to do
- Don’t do a forced migration all at once. Broken sign-ins will avalanche your support inbox.
- Don’t change user-facing URLs mid-migration. Bookmarks and saved links break.
- Don’t skip the sessions. Existing users with valid sessions should stay signed in through the migration.
The entire migration is usually 2-4 weeks of engineering work, spread over 3-6 months of rollout. Total user-visible downtime: zero, if you do it right.