Migrate from Mailchimp to Mautic

Migrate from Mailchimp to Mautic when you need automation, forms and scoring

Moving from Mailchimp to Mautic when you need automation, forms and lead scoring is a contact, consent, journey and sending migration, and it is handled either by an internal team or by an implementation partner. The effort depends mostly on audience size and on how many journeys you need to rebuild, not on the newsletters themselves. Teams that only send announcements usually find the work lighter than teams with branching journeys, scoring rules and form-driven segmentation.

The people who usually run this are a marketing operations lead who owns the journeys, an engineer or platform administrator who installs and maintains Mautic, and someone responsible for the sending domain and email provider. Mautic is written in PHP on Symfony and needs a server you control, with its database, cron jobs and a messenger consumer for queued email. Confirm the PHP and database versions against the requirements for the release you choose before you size the server, and confirm which Mautic release line your organization will support. Plan for the operational work that Mailchimp currently hides: scheduled cron jobs, queue processing, backups and patching.

The main risk areas are consent, deliverability and rebuilt logic. Export consent and opt-in evidence from Mailchimp before you import anything, and map it to Mautic fields so that suppressed or unsubscribed contacts stay suppressed. Your new sending path must authenticate your domain, warm up gradually and handle bounces and complaints, because a new sender can damage reputation quickly. Finally, treat each Mailchimp automation as a specification to test again rather than a template to copy, and ask your partner or internal team to confirm how each trigger, delay and score change behaves in Mautic before you switch off the old journey.

Which Mailchimp capabilities map to Mautic and which need rework

This table maps the main Mailchimp capabilities to their closest Mautic equivalents and marks each as clean, needs rework or gap. Use it to plan which items move directly and which need rebuilding. Confirm specific features against the Mautic documentation for the version you plan to run, because the feature set changes between releases.

Mailchimp capability	Mautic equivalent	Migration status
Audiences and tags	Contacts with tags, imported from CSV with column-to-field mapping	Clean: export contacts and tags, then import with mapped columns
Custom fields and merge tags	Custom contact fields, mapped during CSV import	Needs rework: recreate each field and check merge tag references in templates
Signup forms	Mautic forms, rebuilt in the form builder and embedded on your own site	Needs rework: rebuild layouts, confirm consent fields and update embed code
Segments	Segments based on contact fields, tags and campaign membership	Needs rework: rewrite each condition in Mautic's segment filters
Automations and journeys	Mautic campaigns with decision and action steps, run by cron jobs	Gap in logic: recreate each flow manually, since automation logic does not transfer
Campaigns and templates	Email templates and one-off or segment emails	Needs rework: rebuild HTML templates and test rendering in Mautic
Engagement history (opens, clicks)	Contact activity timeline starts at import	Gap: Mailchimp engagement history will not carry over automatically; archive the Mailchimp reports
Reports	Built-in email and campaign reports from Mautic's own sends	Needs rework: rebuild dashboards and compare results only from the cutover date
Integrations (CRM, e-commerce)	Plugins such as the Salesforce plugin, or custom connections	Gap: confirm each integration in current Mautic documentation before relying on it

What data can be exported from Mailchimp and imported into Mautic

Mailchimp audience data reaches Mautic through a CSV export and a CSV import, so the contents of the export decide what arrives intact. Check each item below against Mailchimp's own export documentation before you start, because the export contents are the first thing to confirm in your account.

Audience export and field mapping

Export the audience as CSV from Mailchimp, then import it through the Mautic user interface, which maps columns to contact fields automatically. Automatic mapping works best when Mailchimp merge fields such as first name and last name match fields you have already created in Mautic. Create any missing custom fields in Mautic before the import, and review the mapping screen column by column, since a misread column can write a value into the wrong field.

Consent and subscription status

Mailchimp's export carries subscription status and consent-related fields, but the exact columns depend on your audience settings and account version. Confirm which status values appear in your export, and decide how each one maps to Mautic's contact state before importing. Do not import contacts who unsubscribed or lack documented consent as marketable contacts, and keep proof of consent wherever your regulators expect it.

Tags and segment membership

Mailchimp tags usually become the basis for segments in Mautic, but Mailchimp tags are not automatically converted into Mautic tags or segment rules. Export tags as a column, then decide whether each tag becomes a Mautic tag, a segment filter or a custom field. Rebuild the segments in Mautic and compare contact counts against the Mailchimp segment before you send anything.

Large files through the import command

The user interface import suits small files. For large audiences, Mautic recommends a background import run by the mautic:import console command from cron, which processes rows in batches of 100 by default. Schedule it on the same staggered cron plan you use for segments and campaigns, and watch the import log for rejected rows, duplicates and malformed email addresses before counting the job as complete.

CRM integrations only where used

Mautic documents Salesforce and HubSpot plugins for syncing contacts with a CRM. Rebuild these integrations only if your team keeps Salesforce or HubSpot as its CRM. If you only used Mailchimp for newsletters, skip them and import contacts directly. Confirm plugin compatibility with your Mautic version and the CRM's current API terms before configuring sync, because two-way sync can overwrite records on both sides.

Engagement history and gaps

Opens, clicks, past campaign reports and signup source are commonly left out of a standard audience export. Ask Mailchimp support or check its current documentation for what engagement data you can retrieve and in what format. Plan to keep the Mailchimp report archive as a separate record, since Mautic will start tracking engagement only from the point of import and sending.

How the Mailchimp to Mautic migration runs from inventory to decommission

This five-phase sequence moves your audiences, consent records and journeys into Mautic without losing track of who may receive which message. Each phase closes with a named artifact that the next phase depends on.

Inventory audiences, journeys, forms and integrations
Work through every Mailchimp audience, tag, segment, automation, signup form and connected service, including the websites and apps that post to them. Your marketing operations lead and whoever owns the Mailchimp account should sign off on the list. The output is a field map that pairs each Mailchimp merge field and tag with a Mautic contact field, plus a consent reconciliation sheet recording how each contact opted in, when, and through which form. The step is done when every audience and form has an owner and every field has a destination.
Export audiences and engagement reports
Run the Mailchimp audience export and keep the files in a restricted location, because they contain personal data. Pull campaign and engagement reports separately, since the audience export does not carry opens, clicks or signup source. Store both sets with a dated manifest so the team can show what was exported and when. The step is done when the record counts in the export match the counts shown in Mailchimp for each audience.
Pilot one segment and one journey
Choose a single segment with clear consent and one simple automated journey, then import that segment into a test Mautic instance. Mautic's CSV import maps columns to fields automatically, but confirm each mapping against the field map before you run it. For larger files, the Mautic documentation recommends the mautic:import console command run by cron, which processes rows in batches of 100 by default. Rebuild the journey as a Mautic campaign, send test messages to internal addresses, and compare the results with the original. The pilot is done when the contact counts, consent flags and journey steps match what was agreed.
Run a parallel period with separate lists
Keep Mailchimp sending for existing audiences while Mautic sends to a separate set of lists, so no contact receives the same message from both systems. Confirm that Mautic's cron jobs for segment updates, campaign updates and triggers are staggered, and that the broadcasts command and messenger consumer are running whenever email is queued. Track bounces, complaints and unsubscribes in both systems each week and reconcile any suppression differences before the next send. The output is a suppression reconciliation log. The period ends when your team is satisfied that both platforms handle opt-outs the same way.
Cut over sending domains and forms
Point your sending domain's DNS records at your own email provider, configure the SMTP settings in Mautic, and confirm authentication records with your deliverability specialist before moving volume. Replace embedded Mailchimp forms on websites with Mautic forms, and update every integration that posted to Mailchimp. Use a cutover checklist that lists each domain, form, integration and owner, with the date each item changed and who verified it. The step is done when the checklist is signed off and no live form still posts to Mailchimp.
Decommission Mailchimp after the retention period
Once the cutover is stable, keep a read-only archive of Mailchimp data for the retention period your legal and compliance teams set, and confirm that the archive is stored where your policy requires. Cancel the Mailchimp subscription only after the archive is verified and the reconciliation records are filed. Ask the Mailchimp account team which data is available after cancellation, and record the answer. The step is done when the archive, the consent records and the final cutover checklist are stored together and the subscription is closed.

What drives the cost and duration of the Mailchimp to Mautic move

This table breaks the move into cost drivers and shows who pays for each, which costs are one-time and which recur. Use it to scope a quote, since most of the effort comes from journey rebuilds, data mapping and sending setup rather than from the software itself.

Driver	Why it changes cost or effort	What to ask for or confirm
Audience size and data quality	Larger lists, duplicate contacts and inconsistent emails lengthen import, cleanup and validation. Mautic imports CSV in batches of 100 rows by default, so large files usually run as background jobs via cron.	Record counts, duplicate rates and invalid address share, plus whether the quote includes cleanup and a test import.
Number of journeys and branching	Each Mailchimp automation must be rebuilt as a Mautic campaign with its own triggers, decisions and actions. Branching logic and wait steps take more design and testing time than a single welcome email.	An inventory of every automation, its branches and goals, and a per-journey rebuild and test plan in the written scope.
Custom fields and segments	Mailchimp merge fields and tags must map to Mautic contact fields and segments. Field types, naming and mapping decisions add work, and segment rules must be re-verified after import.	A field mapping sheet and the number of segments to rebuild and validate.
Forms, landing pages and templates	Signup forms, preference centers and email templates are rebuilt in Mautic. Consent language and double opt-in pages need legal review before go-live.	Count of forms, landing pages and templates, and who approves consent wording.
Integrations (CRM, ecommerce, APIs)	Connectors to a CRM or shop feed contacts and events. Mautic documents a Salesforce plugin, but other connectors may need custom development and testing.	A list of every system that writes to or reads from Mailchimp, with the integration method for each.
Consent records and suppression data	Consent evidence, opt-in timestamps and unsubscribe history must move with contacts. Missing consent data can force re-permissioning and shrink the audience.	Confirmation of which consent fields the Mailchimp export contains and how Mautic will store them.
Sending provider and deliverability setup	Mautic sends through your own email provider, so you pay that provider and set up SPF, DKIM and DMARC. Warming up a new sending domain is a time-based effort that cannot be shortened by the vendor.	Provider choice, expected volume and who owns DNS and domain warm-up in the plan.
Hosting and server sizing	Mautic must run on a VPS or dedicated server, not shared hosting, according to the Mautic requirements page. Cost rises with database size, send volume and redundancy requirements.	Server specification, backup scope and whether the quote covers hardware, cloud resources or both.
Cron jobs and queue monitoring	Mautic relies on cron for segment updates, campaign triggers and broadcasts, plus a messenger consumer when emails are queued. These jobs need staggering and alerting, and failures stop journeys silently.	Who owns cron monitoring, alert routing and the runbook for a stopped consumer.
Staff time and skills	Internal teams spend time on exports, testing, training and approvals. Skills in PHP hosting, databases and email authentication may be needed in-house or contracted.	Named roles, expected hours from each team, and what training is included.
Ongoing maintenance and upgrades	Mautic publishes monthly patch, quarterly minor and two-yearly major releases, and each version has a support end date. Upgrades need testing against your journeys and integrations.	Upgrade cadence, the supported Mautic version in the plan, and whether the retainer covers patching.

How the move differs for small teams, agencies and regulated organizations

A small team with one main list and a handful of automated sequences usually has the simplest move. The work centers on exporting one audience, importing it into a single Mautic instance, rebuilding a few campaigns and switching the sending domain. The bigger change is operational: someone must own the server, the cron schedule and the email provider account after the move, which Mailchimp handled for you.

Hosting: Mautic should not be installed on shared hosting. The project recommends a VPS or dedicated server, so budget for a small server you control rather than a cheap web plan.
Cron jobs: Segment updates, campaign updates and campaign triggers run on schedules that the docs say should be staggered. Someone must check that these jobs keep running.
Sending: Mautic sends through your own email provider, so you need an SMTP or API account with its own sending reputation and bounce handling.
Import: A single CSV can go through the web interface, while larger files are better run with the background import command.
Ownership: Name one person to handle upgrades, backups and monitoring after launch.

Before cutover, confirm who will maintain the server and cron jobs once the project ends, and ask whether a retainer for upgrades and backups fits your budget.",

What usually goes wrong when moving from Mailchimp to Mautic

Most failed Mailchimp to Mautic moves do not fail on the import itself. They fail on consent evidence, suppression lists, scheduled jobs and sending reputation, which only show up after the old account is closed. The checks below are the ones to build into the plan before any contact is moved.

Lost consent and opt-in evidence

Mailchimp audiences carry signup dates, opt-in settings and consent wording that you may need to show a regulator or a complaint handler. A plain CSV of email addresses drops that history, and Mautic will store each contact as if it had been created on the import day. Export the consent fields with every contact and keep the original export file under your records policy. Confirm which fields Mailchimp includes in your export before you assume they are there.

Unsubscribes and suppressions not carried over

Contacts who unsubscribed or were suppressed for bounces in Mailchimp must not reappear as sendable contacts in Mautic. An import that only loads active subscribers will silently re-enable people who opted out. Map the unsubscribed and cleaned status into Mautic's do-not-contact handling as a separate import step, then test one known unsubscribed address before any campaign runs.

Cron jobs unscheduled or overlapping

Mautic does not send campaigns or update segments on its own. Segment updates, campaign updates, campaign triggers and the broadcasts command all run from cron, and the project advises staggering them. Missing entries mean journeys stall without an error, while overlapping runs can process the same contacts twice. Schedule each job at its own offset, and monitor the cron logs for the first week of live sending.

Sending from an unwarmed domain

Moving every send to a new sending domain or IP on day one is a common cause of spam folder placement. Mautic does not warm your reputation for you, and your own email provider's reputation starts from zero. Keep the old sending identity active for a transition period, increase volume in steps, and check authentication records (SPF, DKIM and DMARC) before the first large broadcast.

Duplicate contacts across imports

Contacts often exist in several Mailchimp audiences, and some were added through forms or other tools. Importing each audience separately creates multiple Mautic records for one person, which splits engagement history and can send the same message twice. Decide the unique identifier (usually email address) before importing, deduplicate the export, and run a duplicate check after each batch.

Broken forms and links

Sign-up forms, landing page links and embedded Mailchimp hosted forms keep pointing at Mailchimp after cutover, so new subscribers never reach Mautic. Old newsletter archives also keep working links to tracking URLs and unsubscribe pages that no longer resolve. Inventory every form and link that references Mailchimp, rebuild the forms in Mautic, and submit a test entry through each one before you close the old account.

Running out of time for a parallel run

Teams often plan to run Mailchimp and Mautic side by side but cut over early because the renewal date arrives first. A short parallel period is the only way to compare open rates, unsubscribe counts and delivery results against the old baseline. Agree the parallel window and its exit criteria in writing before work starts, and keep the Mailchimp account open until those criteria are met.

What running Mautic yourself requires after cutover

Once Mailchimp is switched off, your team owns the Mautic stack, so the first decision is the platform itself. Mautic 7.0 requires PHP 8.2, 8.3, 8.4 or 8.5, MySQL 5.7 or higher with InnoDB or MariaDB 10.2 or higher, and Apache, Nginx or IIS, and npm is needed from Mautic 5.0 onward. The project also states that Mautic should not run on shared hosting and recommends a VPS or dedicated server. Check the Mautic requirements page against your chosen version before you provision anything, because the PHP and database minimums differ between releases.

Plan upgrades as a recurring workload, not a one-off task. Mautic's stated cadence is monthly patch releases, minor releases every three months and major releases every two years. Security support windows differ by version: for example, the release notes show Mautic 6.0 and 5.2 leaving security support in 2026, while Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027. Choose a version whose support window covers your planned operating life, and confirm the current support table on the Mautic releases page before you go live, since dates and planned releases can change.

Budget the administration time that comes with this. Your staff, or your implementation partner, will own OS and PHP patching, database backups, cron scheduling for segments, campaigns and broadcasts, and the messenger consumer that sends queued email. Ask any partner to document a written upgrade runbook and a staging environment that mirrors production, so each monthly or quarterly release can be tested before it reaches live campaigns.

Common questions about moving from Mailchimp to Mautic

How much effort and cost does a move from Mailchimp to Mautic involve?

The effort depends mainly on how many contacts, segments, forms and journeys you need to rebuild, and on whether you run the platform yourself or hire help. Mautic itself has no license fee, since the software is free under GPL-3.0 and mautic.org offers it as a free self-hosted download. The recurring costs are the server, the database, an email sending service, backups, and the staff time to patch and administer the platform. The one-time costs are export and import work, rebuilding campaigns, and testing. Ask any implementation partner for a written scope that lists each of these components separately so you can compare them with your current Mailchimp invoice.

How long does it take to move from Mailchimp to Mautic?

The timeline is set by the number of audiences, automations and integrations to rebuild, the hosting work you need before go-live, and how much testing your sending domain requires. Mautic needs a server that meets its requirements, so provisioning, installing and configuring cron jobs come before any data moves. Large contact files are imported in the background through the console command, which adds time for validation. Sending through your own email provider also needs domain authentication and a warm-up period that you cannot skip. Confirm the duration with the team that will do the work, and ask for milestones tied to each audience and journey.

What does our internal team need to provide for the migration?

Your team needs to supply a complete Mailchimp audience export with consent data, a list of active automations and the business rules behind them, the forms and landing pages in use, and access to your DNS records and sending domain. You also need a named owner for the Mautic server, someone who can approve the email provider contract, and a reviewer who understands your consent and suppression rules. Marketing needs to confirm which journeys still matter, because rebuilding inactive automations adds cost without value. Ask the implementation partner to list these inputs in the written scope before the work begins.

Can our own team migrate from Mailchimp to Mautic without outside help?

A team with Linux server administration, PostgreSQL or MySQL experience, and email deliverability knowledge can do the migration in-house, provided it has the time to test thoroughly. The work includes installing Mautic with Composer or the web installer, configuring cron jobs and the messenger consumer, mapping CSV columns to fields, and building campaigns. Mautic's documentation covers these steps, but the hardest parts are consent handling and sender reputation, which are easy to get wrong. Many organizations choose a fixed-scope engagement for the setup and hardening, then run the platform themselves. Decide based on the skills you have today and the risk you can accept during cutover.

Does engagement history carry over from Mailchimp to Mautic?

Engagement history does not transfer automatically through a standard audience export. A Mailchimp audience export contains contact fields, consent and tags, but opens, clicks and campaign history are reported separately and must be mapped manually if you want them in Mautic. Mautic imports contacts from CSV with automatic column-to-field mapping, so you can add custom fields for history you choose to keep. Confirm with Mailchimp exactly which reports you can download before you plan the scoring model. Lead scores and engagement timelines in Mautic will start from the point of import unless you rebuild that history from the reports you exported.

How do sending and deliverability change after moving to Mautic?

Mautic does not send mail on its own infrastructure. You connect it to an email provider or your own SMTP service, so you become responsible for sending infrastructure, bounce handling and complaint monitoring. Queued emails need the messenger consumer running, and segment emails depend on the broadcasts command, so a stopped cron job can stall campaigns without an obvious error. Plan domain authentication, a gradual volume ramp and suppression of unengaged contacts before cutover. Confirm with your email provider what their sending limits, dedicated IP options and complaint thresholds are, because those figures determine your deliverability plan.

What security and compliance work should we expect during the move?

You will move personal data and consent records into a system you operate, so access control, encryption in transit, database backups and an audit trail for consent changes become your responsibility. Mautic requires a supported PHP and database version, so confirm which release line you will run and when its security support ends, using the Mautic releases page. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports or certifications; independent auditors and certification bodies do that. Ask for the security configuration, backup restore test and access review to be written into the scope.

Which Mautic release should we choose for a Mailchimp migration?

Choose the release line whose security support window covers your planned go-live and your operating horizon. Mautic 7.2 supports PHP 8.2 to 8.5 with active and security support until 30 September 2026, and Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027. Mautic 6.0 and 5.2 have earlier end dates. Check the Mautic requirements page for the PHP, database and web server versions before provisioning, since installing on shared hosting is not recommended. Confirm the chosen release with your implementation partner before the server is built.

How DeployOpen scopes and runs a Mailchimp to Mautic migration

DeployOpen plans and implements self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a Mailchimp to Mautic move, we agree a written, fixed scope covering audiences, forms, scoring, journeys and sending before any work starts.

How we scope

Inventory every Mailchimp audience, tag, segment and automation that Mautic must replace.
Confirm which consent and opt-in records can be carried over and which need re-permissioning.
Agree in writing which email provider, domains and server environment Mautic will send through.

How we build

Install Mautic on a VPS or dedicated server, following the project's hosting requirements rather than shared hosting.
Configure the cron jobs for segment updates, campaign triggers and broadcasts, staggered as the documentation recommends.
Run contact imports in batches with the console import command, then test forms, scoring and campaigns.

How we hand over

Document the Mautic configuration, cron schedule, sending setup and import runbook for your own administrators.
Provide a reconciliation report comparing exported Mailchimp counts with imported Mautic contacts.
Deliver a rebuilt journey map so your marketing team can review every campaign before cutover.

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Ask your quote to name who runs Mautic upgrades, including the monthly patch and three-monthly minor release cadence.

Migrate from Mailchimp to Mautic