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.

How to actually implement dual-sending without double delivery

If dual-sending is genuinely warranted, the pattern that avoids the recipient getting two copies: send through the new provider as the real send, and route a copy to a shadow inbox or logging endpoint through the old provider (or the reverse), rather than sending the same message to the real recipient through both. This gets you the side-by-side comparison of deliverability and rendering without ever risking a duplicate landing in someone's actual inbox.

What to actually compare during the dual-send window

Delivery rate and time-to-delivery are the obvious ones, but also compare bounce classification (does the new provider correctly identify hard vs. soft bounces the same way your monitoring expects) and webhook event completeness, missing an expected event type on the new provider is a common, easy-to-miss integration gap that a short dual-send window surfaces before it becomes a production blind spot.

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.