Migration Guides — Switch Services Without Pain (2026)

Switching services? These guides cover the common migration paths — what changes, what breaks, and how long it takes.

Email Migrations

SendGrid → Resend

Why migrate: SendGrid trust declining post-Twilio, free tier removed March 2025, deliverability issues reported.

Difficulty: Low (1-2 hours)

What changes:

• Package: @sendgrid/mail → resend
• API key format: SG_* → re_*
• Send call: sgMail.send({to, from, subject, html}) → resend.emails.send({to, from, subject, html})
• Webhooks: Different payload format — update your webhook handler

What doesn’t change: DNS records (DKIM/SPF) work with any provider. Your sending domain stays the same.

Migration steps:

1. Sign up at resend.com, get API key
2. npm uninstall @sendgrid/mail && npm install resend
3. Replace send calls (API is simpler — fewer lines of code)
4. Update webhook endpoint to handle Resend’s payload format
5. Test in staging (watch the 100/day free tier cap)
6. Switch production, monitor deliverability for 48 hours

Risk: Low. Email APIs are stateless — you can run both in parallel during migration.

SendGrid → Postmark

Why migrate: Better deliverability, focused on transactional email.

Difficulty: Low-Medium (2-4 hours)

What changes:

• Package: @sendgrid/mail → postmark
• API: sgMail.send() → client.sendEmail()
• Must configure message streams (transactional vs broadcast)
• DKIM/SPF: Postmark requires its own DKIM record alongside your existing one

Migration steps:

1. Sign up at postmarkapp.com, create a server
2. Add Postmark’s DKIM record to your DNS (keep existing records)
3. npm uninstall @sendgrid/mail && npm install postmark
4. Replace send calls, set up message streams
5. Test deliverability — Postmark publishes real-time stats

Auth Migrations

Auth0 → Clerk

Why migrate: Better DX, simpler pricing at low-to-mid scale, pre-built UI components.

Difficulty: Medium (1-2 days)

What changes:

• SDK: @auth0/nextjs-auth0 → @clerk/nextjs
• Session management: Auth0 OIDC sessions → Clerk managed sessions
• UI: Auth0 Universal Login → Clerk’s <SignIn /> and <UserButton /> components
• User data: Must export from Auth0 and import to Clerk

What breaks:

• Password hashes: Auth0 uses bcrypt — Clerk can import bcrypt hashes, but the process requires Clerk support
• Custom claims/roles: Auth0 Actions → Clerk metadata (different API)
• Webhooks: Different payload format

Migration steps:

1. Set up Clerk project, configure OAuth providers (Google, GitHub, etc.)
2. Export users from Auth0 (Management API → GET /users)
3. Import to Clerk via Backend API (batch user creation with password hashes)
4. Replace SDK calls: useUser() (Auth0) → useUser() (Clerk) — similar API
5. Replace UI components
6. Run parallel auth for 1-2 weeks (accept tokens from both)
7. Cut over, decommission Auth0

Risk: Medium. User migration is the hardest part. Test password hash import thoroughly.

Auth0 → Better Auth

Why migrate: Zero per-user cost, full data ownership, GDPR compliance.

Difficulty: High (3-5 days)

What changes:

• Everything. Auth0 is managed; Better Auth is self-hosted.
• You now own: session management, user storage, password hashing, token generation
• UI: Must build login/signup from scratch

What breaks:

• All Auth0-specific features (Actions, Rules, custom domains)
• Social login config moves from Auth0 dashboard to your code
• Password hashes: Auth0 bcrypt → Better Auth’s built-in hashing (migration possible)

Risk: High. Full auth rewrite. Only do this if Auth0 costs are truly painful or GDPR compliance requires it.

Database Migrations

Render → Neon

Why migrate: Serverless scaling, database branching, better CI/CD workflows.

Difficulty: Low-Medium (2-4 hours)

What changes:

• Connection string: postgres://...@render.com → postgres://...@neon.tech
• Driver: pg still works; optionally switch to @neondatabase/serverless for edge
• No schema changes needed — both are standard PostgreSQL

Migration steps:

1. Create Neon project, get connection string
2. pg_dump from Render → pg_restore to Neon
3. Update DATABASE_URL in your environment
4. Test with your ORM (Prisma/Drizzle migrations should work unchanged)
5. Switch production

Migrated a service? Report your experience → — help the next agent avoid surprises.