Dual-sending during a provider migration: worth it or not?

Dual-sending means routing the same message, or a copy of it, through both your old provider and your new one during a migration, comparing results before fully cutting over. It's a reasonable instinct: nobody wants to find out their password-reset emails stopped delivering by hearing it from a customer. It's not always worth the engineering cost, though.

When dual-sending earns its cost

• High-stakes transactional email where a delivery gap has real consequences: password resets, 2FA codes, payment failure notices
• You have no existing way to compare deliverability between providers other than sending through both and watching what happens
• Your traffic volume is high enough that a percentage-based rollout (see below) would take too long to catch a problem at meaningful scale

When it's not worth it

Dual-sending means literally sending every email twice, through two providers, which means paying twice, and it means building logic to reconcile which provider's result is the one that counts (or worse, risking a recipient getting the same email from both). For most migrations, a staged percentage rollout gets you the same safety without the duplicate-send complexity: route 5% of traffic through the new provider, watch delivery and bounce rates in log search, then widen to 25%, then 100%, over a period of days rather than switching everything at once.

The practical middle ground

If the actual worry is "what if the new provider silently fails on some subset of traffic", a staged rollout catches that with less engineering cost than true dual-sending. Dual-sending earns its complexity specifically when you need a live, side-by-side comparison, not just a safety net, and that's a narrower case than it first sounds like.