when SendPulse is the right move.
SendPulse is a strong fit for teams that want sendpulse teams moving address books, contacts, tags, variables, blacklist entries, and campaigns into a cleaner operating model. The migration risk is rarely the CSV — it is the automation graph: triggers, delays, branches, template references, and consent state. mailexodus puts a portable schema in the middle so those objects are inspected before they become SendPulse objects.
// inboundwhat SendPulse receives.
- +subscribers
- +lists
- +tags
- +custom fields
- +suppressions
- +campaigns
- ?destination mappings still need final operator review
- xsegments
- xtemplates
- xautomations
Partial automated adapter
Address books map to lists. Contacts map to subscribers. Tags map to tags. Variables map to custom attributes. Blacklist entries map to suppressions. Campaigns and templates map to content items
Automation360 content, reusable templates, and saved segments are not covered by the current canonical migration surface Dry-run the report first, then approve writes when the counts and destination gaps look right.
plan the move to SendPulse.
- Authenticate your sending domain in SendPulse (SPF, DKIM, DMARC) and plan a warmup window — sender reputation is earned here, it does not transfer.
- Bring consent and suppression state across first, so unsubscribes and bounces are honored from the first send in SendPulse.
- QA migrated templates and segments inside SendPulse, and send seed tests before any live campaign.
- Keep your current platform active until in-flight automations finish and SendPulse is warmed and trusted.
start with the route playbook.
The agent prompt returns a route report with source exports, destination imports, skipped objects, and manual-review tasks. When it looks right, wire credentials and approve writes from a controlled machine.
destination coverage
npx mailexodus@latest info sendpulse
agent playbook
Ask mailexodus for a migration_playbook with to=sendpulse
Use mailexodus skill: your source → SendPulse playbook