Should we rewrite our old login system or fix it piece by piece?
We have a 6-year-old custom auth system. Sessions, OAuth, password resets, MFA — all hand-rolled. It works but it's fragile and slows every feature. Do we rewrite it on a managed provider (Auth0/Clerk/Supabase Auth) or strangle-fig it module by module?
Run this exact prompt as a real Premium debate to confirm the current prompt & schema produce the intended structure. Uses your wallet balance.
Strangle it. Migrate password reset first, behind a feature flag, on Clerk or Auth0.
- →Big-bang auth rewrites have a near-100% rate of leaking sessions or locking users out on cutover — the blast radius isn't worth the speed.
- →A strangler pattern lets you migrate one flow at a time (password reset → MFA → OAuth → sessions) with rollback measured in minutes, not weeks.
- →Managed providers eliminate ~80% of the ongoing maintenance (MFA, social, audit logs, compliance) without forcing you to own the migration risk.
Every agent independently arrived at the same top-line answer: incremental migration wins. The disagreement isn't whether to strangle-fig — it's which provider to strangle onto, and how long to run the two systems in parallel. Clerk optimizes for shipping speed at your current scale; Auth0 optimizes for enterprise credibility; Supabase Auth optimizes for stack simplicity if you're already on Postgres.
The non-obvious insight from the debate: the biggest risk isn't the rewrite itself, it's the six months of ambiguity where two systems both claim ownership of the session. Two agents (GPT-5 and Grok) flagged the dual-write window as the single most common failure mode in real-world auth migrations — teams either shut down the legacy path too fast (locking out monthly-active users) or leave it running for a year (rotting the codebase and doubling the on-call load).
Start with password reset because it is low-traffic, idempotent, and has clear success signals. If it works, MFA is the next slice. Save session/token migration for last — it is the highest-risk, and by the time you get there your team will have muscle memory from the earlier cutovers.
- ✓Don't ship a flag-day cutover. Every agent rejected the all-at-once rewrite.
- ✓Password reset is the safest first slice — low traffic, idempotent, easy to roll back.
- ✓Pick the managed provider before you start; migrating to a TBD target doubles the work.
- ✓Instrument first: you cannot migrate what you cannot measure. Add per-flow success/failure telemetry to the legacy system this sprint.
- ✓Communicate the migration to users only when a flow is at 100% cutover. Mid-migration announcements confuse support tickets.
While both systems can mint sessions, an attacker who compromises the legacy path can create a session that the new provider trusts. This is the failure mode behind the majority of publicly-postmortemed auth migrations.
Managed providers send from their own domains by default. Users trained to trust your domain may mark the new emails as spam, spiking reset failures 20-40% in week 1.
Managed providers request their own default scopes, which often differ from your legacy scopes. Users see the consent screen again and a fraction will bounce.
If your legacy MFA uses a home-rolled TOTP secret store, users may lose their second factor at migration and be unable to complete recovery.
Two systems means two failure surfaces. Expect a 1.8-2.2x increase in auth-related pages during the parallel window.
- ?What % of your MAUs authenticate at least once per 30 days — the number that decides the parallel-window length.
- ?Whether your enterprise contracts include specific auth-provider clauses (Okta-required, SAML-required, etc.).
- ?The exact scope list your legacy OAuth requests from each provider.
- ?How much of your custom auth logic is actually business logic (rate limits, custom claims, feature flags) vs plain auth — the former does not migrate cleanly to any managed provider.
- ?Whether your compliance posture (SOC 2, HIPAA, PCI) will require re-audit of the new provider before cutover.
- □Add per-flow success/failure telemetry to the legacy auth system.
- □Pick the provider (write a one-page memo, force the call).
- □Run a security audit on current session storage — patch anything critical this week regardless.
- □Ship password reset behind a 10% feature flag.
- □Ramp password reset to 100% once error rate is within 0.5% of legacy baseline.
- □Configure custom-domain SMTP on the provider and warm the IP.
- □Draft the MFA migration plan including TOTP secret import path.
- □Complete MFA migration with re-enrollment fallback path production-tested.
- □Cut OAuth (Google/Apple/Microsoft) over to provider.
- □Begin session migration — dual-write for a defined 60-day window with explicit MAU cutover threshold.
- □Deprecate legacy auth codepaths once >99% of 30-day MAUs have authenticated on the new system.
Rip the bandage off — the incremental path is a slow-motion year of parallel bug reports.
Grok's steel-manned case: strangler-fig migrations optimize for reduced blast radius, but they trade it for cumulative distraction. A 4-person team doing incremental auth migration will lose 20-30% of engineering throughput for two quarters — often more than the cost of a single, well-planned two-week cutover with rollback. The teams that succeed with big-bang cutovers do three things right: they freeze the legacy codebase two weeks before, they ship the new system to a 5% canary the weekend prior, and they staff the on-call at 3x during the cutover window.