when Drip is the right move.
Drip is a strong fit for teams that want drip 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 Drip objects.
// inboundwhat Drip receives.
- +subscribers
- +tags
- +custom fields
- +campaigns
- ?campaigns
- xlists
- xsegments
- xsuppressions
- xtemplates
- xautomations
Automated adapter
Subscribers map to subscribers. Tags and custom fields map directly. Broadcast and campaign emails map to content items. Workflow email steps map to automation inventory when bodies are available
Drip can receive subscribers, tags, custom field values, and single-email campaign drafts. Drip campaign/list-like structure is not a clean list import surface, and workflow graph creation is not treated as an importable destination surface. Dry-run the report first, then approve writes when the counts and destination gaps look right.
plan the move to Drip.
- Authenticate your sending domain in Drip (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 Drip.
- QA migrated templates and segments inside Drip, and send seed tests before any live campaign.
- Keep your current platform active until in-flight automations finish and Drip 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 drip
agent playbook
Ask mailexodus for a migration_playbook with to=drip
Use mailexodus skill: your source → Drip playbook