Migrating to Notifiva Without Downtime

Teams put off changing transactional email providers for one reason: the mail they send is load-bearing. If the cutover drops password resets or receipts for even an hour, real users can't get into their accounts. So migrations get delayed for years on a working-but-unloved provider. The fix isn't courage — it's a staged plan where nothing ever fully depends on the switch working the first time. Done right, a provider migration has zero downtime and instant rollback at every step.

A safe migration never has a single moment where everything depends on the new provider working. You always have the old one live behind you.

The principle: parallel, then gradual#

The unsafe way to migrate is a hard cutover: change everything at midnight and hope. The safe way rests on two ideas.

• Parallel run. Both providers are configured and able to send at once. You're not replacing, you're adding — then shifting.
• Gradual shift. Move a small percentage of sends first, verify delivery via events, then ramp. A problem shows up at 5% of traffic, not 100%.

Every provider — whether you're coming from SendGrid, Amazon SES, Mailgun, Postmark, or anything else — supports this pattern, because it lives in your sending code, not theirs. No disparagement of your current provider is needed or implied; this is just how you de-risk any infrastructure swap.

Step 1 — Authenticate on Notifiva (no DNS conflict)#

Set up domain authentication on Notifiva before moving any traffic. DNS allows multiple authenticated senders at once:

• SPF — add Notifiva's mechanism alongside your current provider's. SPF is designed to list several senders; you don't remove the old one yet.
• DKIM — DKIM uses distinct selectors per provider, so Notifiva's DKIM key coexists with your existing provider's. No conflict.
• DMARC — you already have a DMARC record (or should); it doesn't change during migration. Both providers just need to align to your From: domain.

This step is invisible to users and reversible — you're adding records, not removing them.

Step 2 — The smallest first move: SMTP relay#

Because Notifiva's SMTP relay and REST API feed the same pipeline, the lowest-risk way to start sending is to point your existing framework mailer at the relay. Change host, port and credentials — no new send code:

SMTP host: smtp.notifiva.com
Port:      587 (STARTTLS)   # or 465 for implicit TLS
Username:  your_smtp_username
Password:  your_smtp_password

That's the entire integration for many apps. If you'd rather send via the API (for idempotency keys and metadata), that's Step 4 — but SMTP-first gets you delivering on the new provider with the smallest possible change. (The trade-offs are in email API vs SMTP relay.)

Step 3 — Parallel run and gradual cutover#

Now shift traffic deliberately, watching the delivery webhooks (email.delivered, email.bounced, email.complained) as you go:

• Route a slice. Send a small percentage (say 5–10%) through Notifiva; the rest stays on the old provider. A feature flag or a simple hash-on-recipient split works.
• Verify. Watch delivery, bounce and complaint events on the Notifiva side. Compare placement against your current provider using seed inboxes.
• Ramp. Increase the share as confidence grows — 25%, 50%, 100% — over days, not minutes, so the new sending identity warms gradually.
• Keep the old provider live. Until you're at 100% and stable, rollback is just moving the slider back.

Step 4 (optional) — Move critical flows to the API#

Once SMTP traffic is stable on Notifiva, you can move high-value flows — password resets, OTP, receipts — to the REST API to gain idempotency keys (no duplicate resets on a retry) and per-message metadata. Do this flow by flow, not all at once, reusing the same parallel-then-ramp discipline. Reads on delivery status move to GET /v1/messages/{id} and the webhooks you're already consuming.

Step 5 — Decommission cleanly#

Only after 100% of traffic has been stable on Notifiva for a sensible window:

• Tighten SPF by removing the old provider's mechanism (keeping SPF within its lookup limits).
• Retire the old DKIM selector and revoke the old provider's API keys.
• Keep historical logs you may need from the old provider before you close the account.
• Update runbooks so on-call knows the new provider is now the source of truth.

Rushing decommission is the one place this plan can still bite you — leave the old provider fully live until you're certain.

A pre-migration checklist#

• [ ] Inventory every system that currently sends mail (app, workers, CRM, helpdesk, cron jobs).
• [ ] Authenticate the domain on Notifiva (SPF add, DKIM selector, confirm DMARC alignment).
• [ ] Stand up webhook consumption for delivery events before cutover.
• [ ] Choose the split mechanism (flag / hash-on-recipient).
• [ ] Define rollback (move the slider back) and who can trigger it.
• [ ] Set the ramp schedule and the metrics that gate each step (delivered %, bounce %, complaint %).

Example scenario: the year-long delay, resolved in a week#

(Illustrative scenario, not a customer case.) A team wants to move providers but has postponed for over a year, afraid of dropping resets. They finally run the staged plan: authenticate on Notifiva (a morning), point SMTP at the relay behind a flag (an afternoon), route 5% of traffic and watch the delivery webhooks (a day), then ramp to 100% over the rest of the week while the old provider stays live. At no point is there a window where sending depends solely on the new provider. The migration they'd feared for a year takes about a week of low-stress, reversible steps — and the scariest moment never comes, because it was engineered out.