when Buttondown is the right move.
Buttondown is a strong fit for teams that want buttondown teams with subscriber data, campaigns, and automation branches that need a migration report before rebuild. 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 Buttondown objects.
// inboundwhat Buttondown receives.
- +subscribers
- +lists
- +tags
- +custom fields
- +suppressions
- +campaigns
- +automations
- ?destination mappings still need final operator review
- xsegments
- xtemplates
Partial automated adapter
Subscriber metadata maps to custom attributes. Tags map to tags. Newsletters can map to lists. Emails map to campaigns
Template and automation coverage is limited and should not be treated as full export support Dry-run the report first, then approve writes when the counts and destination gaps look right.
plan the move to Buttondown.
- Authenticate your sending domain in Buttondown (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 Buttondown.
- QA migrated templates and segments inside Buttondown, and send seed tests before any live campaign.
- Keep your current platform active until in-flight automations finish and Buttondown 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 buttondown
agent playbook
Ask mailexodus for a migration_playbook with to=buttondown
Use mailexodus skill: your source → Buttondown playbook