The real checklist for migrating email providers

This is the general version of the provider-specific migration guides (Resend, SendGrid, Postmark, Mailgun, Mandrill), pulling the steps that are true regardless of which provider you're leaving. Read the provider-specific guide for the exact field mapping, use this for the sequence.

Before you write any code

• Confirm your current provider's exact request shape and any provider-specific features you actually use (templates, tagging, batch sending) so you know what needs a manual equivalent versus what's a straightforward field rename
• Add Envello's SPF include and DKIM records alongside your existing provider's records, don't remove anything yet
• Verify your sending domain in Envello and confirm DNS has propagated

Code changes

• Swap the sending client and API key behind a flag or environment variable that lets you route a percentage of traffic to either provider
• Update error handling for the new provider's error codes, don't assume they match your old provider's
• If you used server-side dynamic templates with loops or conditionals, render that logic in your own application code instead, Envello's template system does variable substitution only

Rollout

• Start at a small percentage of traffic, watch delivery status and bounce rate in log search for at least a day
• Widen gradually, not all at once, over days rather than hours
• Only remove your old provider's DNS records and API integration once you've held at 100% with no issues for a few days

Webhook consumers need their own migration step

It's easy to migrate the outbound send call and forget that your application also listens for inbound delivery events. Update your webhook endpoint to handle Envello's event shape and verify its HMAC signature (a different secret and payload structure than your old provider's), and register the new webhook URL in the dashboard before cutting traffic over, not after. A migration that swaps sends but leaves the old webhook consumer running against a provider you've stopped using is a silent gap in your bounce and complaint handling.

Exporting historical data before you fully cut over

Your old provider's delivery logs typically don't transfer, export anything you need for compliance or historical debugging (past send records, bounce history) before decommissioning that account, not after. This matters most for anyone with a data retention obligation that predates the migration itself.

The one step people skip

Actually watching log search during the rollout window. A staged migration only catches problems early if someone is looking. Set a calendar reminder to check delivery status at each stage rather than assuming silence means success.