In May 2026, an article titled From Supabase to Clerk to Better Auth hit the front page of Hacker News, sparking spirited discussions around a developer's candid experience of "migrating an authentication stack from Supabase to Clerk to Better Auth." It marks a symbolic shift in SaaS authentication selection: "choosing for features → migrating due to pricing → settling on self-controlled OSS."
In our custom development practice, inquiries regarding "auth infrastructure migration" have increased noticeably over the past six months. We are simultaneously fielding requests from clients looking to "migrate away from Auth0, Cognito, or Firebase Auth" and those seeking to "move to Better Auth to maintain in-house control." In this article, we outline a playbook for safely executing auth migrations in custom development.
Why "rethinking SaaS authentication" is happening
Behind the migration away from SaaS authentication lie three structural shifts.
| Shift | Details | Impact on custom development |
|---|---|---|
| Pricing model volatility | MAU pricing suddenly increases | Unpredictability of monthly costs |
| Data sovereignty requirements | PII cannot be stored on third-party SaaS | Mandatory requirement in regulated industries / B2B |
| Vendor lock-in concerns | Migration is difficult due to poor export APIs | Exit planning left as an afterthought |
| Maturity of open-source software | Practical OSS solutions like Better Auth have emerged | Self-hosting becomes a realistic solution |
| AI agent integration | Agent authentication requirements are increasing | Customizability is essential |
In particular, "pricing model volatility" is the most frequent discussion point in custom development; we have seen multiple cases where "monthly costs suddenly tripled before anyone noticed." For development partners budgeting projects based on unit costs agreed upon at contract signing, SaaS price increases present a direct financial deficit risk.
This represents an extension of the mindset of "controlling the authentication layer as an independent component" discussed in Implementing MCP Server OAuth 2.1 Authentication in Client Projects, with growing consensus that "authentication is an area development partners should control themselves."
Decision criteria for selecting a "migration destination" in custom development
Better Auth is not a silver bullet. Below are the decision criteria when selecting a migration destination in custom development projects.
[Better Auth が最適なケース]
├ Node.js / TypeScript ベースのプロダクト
├ 自前で DB / インフラを握れる体制
├ 規制業界（金融 / 医療）
├ MAU 10 万超で SaaS 課金が辛い
└ AI エージェント統合のカスタマイズ要件
[Clerk / Supabase Auth で十分なケース]
├ MVP / PoC 段階
├ MAU 1 万以下
├ 自前運用の体制がない
├ 標準的な認証要件のみ
└ 開発速度最優先
[Auth0 / Cognito が最適なケース]
├ Enterprise SSO 必須
├ 既存の AWS / Auth0 投資が大きい
├ コンプライアンス監査の取得実績重視
└ MAU の予測が立つ大規模案件Rather than assuming that "migrating to Better Auth solves everything," the development partner's responsibility lies in making a selection tailored to the project's phase and team capabilities.
Standard migration flow for custom development — Switching safely in four phases
Authentication migrations represent a major disaster zone where "users could be locked out from logging in." In custom development, we standardize on the following four phases.
[Phase 1: 並行運用 (2〜4 週間)]
├ 旧認証 / 新認証を両方有効化
├ ログイン時に新側にユーザーをコピー
├ ハッシュ移行（パスワード再設定不要）
└ 全ユーザーの 80% が新側に移行するまで継続
[Phase 2: 新規ユーザー新側 (1〜2 週間)]
├ 新規登録は新側のみ
├ 既存ユーザーは新旧どちらでもログイン可
└ 残り 20% を能動的に新側へ誘導
[Phase 3: 旧側読み取り専用 (2〜4 週間)]
├ 旧側の新規登録停止
├ ログインは新側のみ受付
├ 旧側はパスワードリセット用の参照のみ
└ 残ユーザーをメール通知で誘導
[Phase 4: 旧側停止 (完了)]
├ 旧 SaaS の解約
├ データのバックアップ取得
└ 監査ログのアーカイブIn particular, Phase 1's "hash migration" is the most critical milestone; an operational approach of sending a "password reset email to all users" leads to disasters like a 30% drop in e-commerce sales. By verifying bcrypt and argon2 hash format compatibility in advance, you can achieve a completely transparent migration.
Data integrity — Five checks learned from failure cases
Here are the data integrity check items prone to failure in custom development.
| Check item | Impact if overlooked |
|---|---|
| Email address normalization | The same user is registered redundantly |
| Carrying over MFA settings | MFA gets disabled (critical incident) |
| Social login ID mapping | Logging in via Google links to a different user |
| Sessions and refresh tokens | All users are forcibly logged out |
| Migration of admin privileges and roles | Nobody can access the admin dashboard |
In particular, "social login ID mapping" is the point where most incidents occur in custom development. Always verify using both provider_id and email, and establish a manual review workflow when conflicts occur.
This belongs to the same domain as the "handling of authentication credentials" discussed in Operating Source Code Secrets Audits in Custom Development, representing an area that requires doubled vigilance during migration.
"Auth migration clauses" to include in client contracts
When handling authentication migration in custom development contracts, explicitly specify the following clauses.
| Clause | Details | Client alignment points |
|---|---|---|
| Migration scope | Target user count / SSO requirements | Agreement on projected MAU |
| Downtime allowance | Feasibility and timing of planned maintenance | Maintenance window |
| Rollback conditions | Criteria for aborting the migration | Failure rate / error rate thresholds |
| Data retention period | Retention period for legacy platform data | Legal compliance / audit requirements |
| Liability for damages | Scope of liability during login outages | Demarcation of responsibility between contractor and client |
| AI agent authentication | API keys / OAuth for agents | Auth requirements for agent integrations |
In particular, unless you clearly define the "rollback criteria" upfront, overreactions occur where "everything is rolled back over the slightest issue." Agree on concrete metrics, such as a failure rate exceeding 0.5% or issues persisting for over 30 minutes.
Five common pitfalls
Pitfall 1: Rehashing password hashes casually
Executing a hash algorithm change like bcrypt → argon2 concurrently with the migration will require all users to re-login. Execute it in two steps: first migrate, then rehash upon subsequent login.
Pitfall 2: Failing to migrate email change history
If the legacy system maintained an email change history, omitting it causes incidents where users "cannot log in using their previous email address" post-migration. Migrate this data into an alias table.
Pitfall 3: Inability to migrate WebAuthn / Passkeys
Because passkeys rely on pairing between device and service, they cannot be migrated across SaaS platforms. Plan from the outset a workflow that prompts all users to re-register.
Pitfall 4: Forgetting to update corporate SSO (SAML / OIDC)
If the SP metadata registered with the IdP retains the legacy URLs, enterprise users will be unable to log in via SSO after migration. Advance notification to enterprise clients is mandatory.
Pitfall 5: AI agent API keys requiring re-issuance on the new platform
In recent custom development projects, authentication for AI agents has become vital. If reissuing API keys and OAuth tokens used by agents is omitted from the migration plan, all agents will halt post-migration.
Conclusion — Entering the era where "owning your auth is the right call"
Authentication is shifting back from the era of "delegating to SaaS and forgetting it" to "owning and controlling it yourself." With the emergence of practical OSS like Better Auth, self-hosting has become a realistic solution across the three pillars of pricing, data sovereignty, and customizability.
Authentication migration is an area where required effort varies drastically depending on target MAU, presence of SSO/MFA, and regulatory requirements. If you are experiencing issues like "running deficits due to price increases from Auth0 or Cognito" or "wanting to migrate to Better Auth while avoiding migration failures," we provide individualized estimates after evaluating your current architecture. Feel free to contact us via our contact form.
