when Mautic is the right move.
Mautic is a strong fit for teams that want mautic 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 Mautic objects.
// inboundwhat Mautic receives.
- +subscribers
- +lists
- +tags
- +segments
- +custom fields
- +suppressions
- +campaigns
- +templates
- +automations
- ?destination mappings still need final operator review
- xno canonical import gaps in the current coverage model
Automated adapter
Contacts map to subscribers. Segments map to segments. Do-not-contact records map to suppressions. Emails and templates map to content items. Campaign email steps map to automation emails when available
Self-hosted versions and plugins can change API shape Dry-run the report first, then approve writes when the counts and destination gaps look right.
plan the move to Mautic.
- Authenticate your sending domain in Mautic (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 Mautic.
- QA migrated templates and segments inside Mautic, and send seed tests before any live campaign.
- Keep your current platform active until in-flight automations finish and Mautic 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 mautic
agent playbook
Ask mailexodus for a migration_playbook with to=mautic
Use mailexodus skill: your source → Mautic playbook