Migrate from ActiveCampaign to Mautic

Migrate from ActiveCampaign to Mautic: what the move involves

If your ActiveCampaign renewal, pricing change or data residency requirement has pushed you toward self-hosting, the move to Mautic is a data, automation and sending-domain project, and the team that owns the platform will do most of the work. The short answer on effort is that the contact import is the easy part; rebuilding automations as campaigns, re-creating forms and tracking, and warming a new sending domain are where time and risk accumulate. Mautic itself is free to self-host under the GPL-3.0 license, so what you pay for is the infrastructure, the database, the cron jobs that drive segments and campaigns, and an email delivery provider, all of which fall on the owner. Plan for a named internal owner who can run the platform after cutover, not only a project team that disbands at go-live.

Start with an inventory before you export anything. Pull the contact list, tags and custom fields from ActiveCampaign, and record which automations are live, which forms feed them and which sending domain and authentication records each one depends on. Mautic imports contacts from CSV with automatic column to field mapping in the user interface, but for large files the project recommends background imports with the mautic:import console command run by cron, processed in batches of 100 rows by default. Confirm with your ActiveCampaign administrator exactly which export formats and limits apply to your account, and check that every consent or opt-out flag travels with each contact, because suppression lists are the data you can least afford to lose.

Treat the sending domain as a separate workstream that starts early. Mautic does not send mail on its own reputation; you connect an email provider and must set up authentication for the domain you send from. Begin warming new sending infrastructure well before your ActiveCampaign contract ends, starting with engaged segments and ramping volume slowly, so that inbox placement is established before you move your full list. Mautic's cron jobs for segment updates, campaign triggers and broadcasts, plus a messenger consumer for queued email, must be running and monitored from day one, because a stopped cron job stops campaigns silently. Confirm the Mautic release you will deploy against the project's support windows on the Mautic releases page before you commit to a version.

Which ActiveCampaign capabilities map to Mautic, and which need rework

This table maps each main ActiveCampaign capability to its nearest Mautic equivalent and marks it clean, needs rework or gap. Clean means data moves through a file import, needs rework means the logic or assets must be rebuilt by hand, and gap means you must supply something Mautic does not provide. Confirm exact feature parity against your ActiveCampaign plan and the current Mautic release before scoping.

Capability	Mautic equivalent	Status	What to confirm
Contacts, tags and custom fields	Contacts, tags and custom fields imported from CSV with automatic column mapping	Clean	Field types and tag names survive the export intact
Lists and segments	Segments built from contact fields and tags, refreshed by cron jobs	Needs rework	Rebuild each ActiveCampaign list as a Mautic segment
Automations	Campaigns with triggers, decisions and actions, evaluated by cron jobs	Needs rework	Rebuild each automation by hand and test every branch
Forms and landing pages	Built-in form and page builders embedded on your own domain	Needs rework	Recreate forms and pages, then update every embed on your sites
Site tracking	Mautic tracking script added to your site templates	Needs rework	Replace tracking code on every site and confirm consent settings
Email sending	Mautic sends through a provider you connect and does not supply sending infrastructure	Gap	Choose and configure a provider, then warm the new sending domain
CRM sync	Documented plugins cover Salesforce and HubSpot	Gap	Confirm coverage for your CRM and scope a custom integration if needed
Reporting	Built-in reports for campaigns and contacts	Needs rework	Export ActiveCampaign reports first and confirm the metrics you need

What data moves, and which integrations you rebuild

Contacts, tags and custom fields move as CSV files, but the integrations around them do not. Forms, site tracking, the sending provider and any CRM link each need a deliberate rebuild in Mautic, and each one has its own check before you cut over.

Export contacts, tags and fields

Export your contact list from ActiveCampaign as CSV, with one row per contact and columns for email, name, tags and every custom field you rely on. Confirm with your account owner which export options your plan includes, including whether tags and custom fields come out in the same file or need separate exports. Keep the original export as an archive, and record the row count so you can reconcile it after import. Unsubscribe and bounce status should be exported too, because importing those contacts as active would breach their opt-out.

Import with automatic column mapping

Mautic's import screen maps CSV columns to contact fields automatically, so check each mapping before you confirm, especially for similarly named columns such as phone and mobile. Create the custom fields in Mautic first, using matching aliases, or the import will leave those columns unmapped. Use the interface only for small files. For larger lists, the mautic:import console command runs the import in the background from cron, processing batches of 100 rows by default.

Large file imports and batch runs

A large import in the background needs a PHP process with enough memory, a cron job that runs the import, and a log you can read after it finishes. Run a test import of a few hundred contacts into a staging instance first and compare the counts. Schedule the full run outside business hours, and confirm that the cron entry is removed afterwards so it does not keep re-reading the same file. Keep the source file in a location the web server user can read but that is not publicly served.

Rebuild forms and site tracking

ActiveCampaign forms and site tracking code do not move with the contact list. Rebuild each sign-up form as a Mautic form, then point the existing embed or landing page at the new form endpoint. Install the Mautic tracking script on every page where you need visitor and campaign attribution, and test that a form submission creates a contact with the expected tags. Remove the old tracking snippet once the new one is confirmed, so visitors are not tracked twice.

Connect the email sending provider

Mautic sends mail through a transport you configure, typically an external SMTP relay or API-based provider, rather than the server sending directly. Choose the provider before you rebuild campaigns, then configure bounce and complaint handling so suppression data flows back into Mautic. Confirm the provider's sending limits and whether it supports the authentication records your domain needs. This is the integration most likely to affect whether mail reaches the inbox.

Check CRM and third-party links

If ActiveCampaign syncs with a CRM, Mautic does not inherit that sync. Mautic provides a Salesforce plugin and a HubSpot plugin, so confirm whether your CRM is one of those before planning the link, and whether the plugin's current version supports your Mautic release. If your CRM is neither, plan a scheduled CSV exchange or API integration with the team that owns the CRM. Also list every webhook, zap or API call that writes to ActiveCampaign, because each one needs a new target.

Migration sequence from inventory to decommission

This sequence moves an ActiveCampaign program to self-hosted Mautic in controlled stages, so each stage has a documented output before the next one starts. It ends with ActiveCampaign switched off only after data retention has been confirmed.

Inventory contacts, automations and sending setup
Your marketing operations lead exports the contact list, tags, custom fields, lists and segments from ActiveCampaign, then documents every automation, its trigger, its branches and the emails it sends. Record the sending domain, DKIM and SPF setup, forms, landing pages and any site tracking code. Done means you hold an inventory of automations with a plain-language description of each one, a field map showing how every ActiveCampaign field will land in Mautic, and a count of contacts by status (subscribed, unsubscribed, bounced).
Build the Mautic environment and map fields
Your platform team installs Mautic on a VPS or dedicated server, not shared hosting, following the project's requirements, and connects the cron jobs and messenger consumer that Mautic needs for segments, campaigns and queued email. Create the custom fields and tags in Mautic to match the field map from the inventory. Done means a test contact can be imported, tagged, placed in a segment and sent a test message through the email provider you have chosen.
Run a pilot with a small segment
Import a small, low-risk segment of engaged subscribers through the Mautic interface or the mautic:import console command, then rebuild one simple automation as a Mautic campaign. Send a limited test campaign from the new sending domain or subdomain and check inbox placement, bounce handling and unsubscribe behavior in Mautic. Done means the pilot contacts, tags and campaign results reconcile with the ActiveCampaign source and you have a written list of defects to fix before the wider import.
Import the full list and reconcile counts
Import the full contact set in batches, using the background import for large files as Mautic recommends, and keep the source export files for audit. Compare the imported totals per status, tag and list against the ActiveCampaign inventory and record every difference with its cause, such as invalid rows, duplicates or rejected fields. Done means you have a reconciled contact count signed off by the data owner, with exceptions logged and resolved.
Run in parallel with suppression and consent checks
Keep ActiveCampaign sending for existing programs while Mautic runs the rebuilt campaigns for a defined set of contacts, so you can compare results. Before each send, confirm that unsubscribed, bounced and complained contacts are suppressed in Mautic and that consent records and lawful basis are carried over for every contact. Assign each contact to only one platform to avoid duplicate sends. Done means a consent and suppression check has been reviewed by the privacy or compliance owner and no contact appears as sendable in both systems.
Cut over sending domain and tracking
Switch the sending domain or subdomain, DNS records and tracking code on forms, landing pages and the website to Mautic in a planned window agreed with the business owners. Verify authentication records and tracking after the change, and keep the rollback steps written down before you start. Done means a signed-off cutover checklist shows each DNS change, tracking update and test result, and the owner has accepted it.
Confirm retention and decommission ActiveCampaign
Once Mautic is the only sending platform, export final ActiveCampaign reports, automation definitions and contact records that your retention policy requires you to keep, and store them in your own controlled archive. Confirm with legal or compliance which records must be retained and for how long, and check the terms of your ActiveCampaign agreement for the export and closure steps. Done means retention is confirmed in writing, the archive is verified, and the ActiveCampaign account is closed.

Running both platforms in parallel without double sending

The first rule of a parallel run is that only one system may send campaigns to a given contact at any time. Decide, per segment and per date, which platform is authoritative for sending, and write that decision down before the first Mautic campaign goes live. A practical pattern is to keep ActiveCampaign authoritative for all existing automations and broadcasts while Mautic receives only a test segment of internal addresses, then move one segment at a time. Before each move, remove the moved contacts from every active ActiveCampaign automation and list you are retiring, so a journey already in progress does not send its next step from the old platform. Mautic's contact import records tags and custom fields, but it does not stop ActiveCampaign from emailing the same person, so the suppression has to be done by hand or by an export-and-remove step on the ActiveCampaign side.

Unsubscribes and consent records are the easiest data to lose during overlap. Export the unsubscribe and do-not-contact status from ActiveCampaign as a separate file, not only as a column in the contact export, and import it into Mautic as a do-not-contact flag before any Mautic send to that address. Keep the ActiveCampaign export as the record of what was known at the time of cutover, and confirm with your privacy or legal owner how consent evidence (source, date and wording) should be retained. Treat any address that unsubscribed in either system as suppressed in both until the cutover is complete.

Mautic depends on cron jobs for segment updates, campaign updates and campaign triggers, and the Mautic cron jobs documentation advises staggering these commands rather than running them all at the same minute. It also depends on a broadcasts command for segment emails and a messenger consumer when emails are queued. A parallel run can look healthy while none of these jobs is running: the Mautic dashboard shows contacts and campaigns, but segments never refresh and scheduled sends sit in the queue. Confirm each job's last successful run, check the queue depth after each scheduled send, and alert on a missing run. Verify the schedule against the current version's cron documentation, because command names and staggering guidance can change between releases.

How the migration changes by list size and starting point

A small contact base with a handful of automations is the simplest starting point. The contact import is usually a single CSV export and import, and the automation logic is short enough to rebuild by hand and test end to end. Most of the effort goes into the new server setup, the sending domain and the forms. The main risk is skipping the checks that come after go-live, not the data itself.

Import volume: A small file can go through the Mautic web import, which maps columns automatically, so no cron-driven background import is needed.
Rebuild scope: A few flows can be rebuilt as Mautic campaigns and tested with a small set of test contacts before any live send.
Sending domain: Warm-up still applies, so a small list does not remove the need for a gradual volume increase on the new domain.
Hosting: Mautic runs on a VPS or dedicated server, not shared hosting, so the server is still a fixed cost even for a small list.
Operations: Cron jobs for campaigns and segments still need to be set and monitored after the move.

Confirm with your own team how many automations you actually run and whether each one has a clear owner who can sign off on the rebuilt version.",

What drives cost and duration, and how to keep each down

This table lists the factors that change the effort and recurring spend of moving from ActiveCampaign to Mautic, with the party usually paid for each and how to reduce it. Read the one-time rows as the migration project and the recurring rows as the ongoing operating cost after cutover.

Driver	Why it changes cost or effort	How to keep it down
Automations to rebuild	Each ActiveCampaign automation must be recreated as a Mautic campaign with its own triggers, conditions and actions, so the count sets most of the one-time build effort.	Inventory every automation, retire unused ones, and rebuild only active journeys first.
Data quality and duplicates	Duplicate contacts, stale addresses and inconsistent tags add cleanup time before import and can distort segments after it.	Deduplicate and validate the export, and agree a single identifier such as email address before importing.
Custom field count	Each custom field needs a matching Mautic field, a mapping decision during CSV import and checks that values load correctly.	Remove unused fields and map overlapping ones to a single field where the data meaning matches.
Forms and tracked sites	Each form must be rebuilt in Mautic, and each site needs the tracking script and any landing pages reconnected.	List every live form and tracked domain, then rebuild only those still receiving traffic.
CRM integration scope	If ActiveCampaign feeds a CRM, the Mautic Salesforce plugin or a custom sync must be designed, tested and maintained, which is usually the largest variable add-on.	Confirm in writing which objects and fields sync in each direction before any build starts.
Email provider setup	Mautic sends through an email transport you configure, so you pay for the provider, its setup, and any bounce and complaint handling.	Choose the provider early, compare its per-message pricing with your volume, and ask the provider for its current rates.
Sending domain warm-up	A new sending domain needs authentication records and a gradual volume ramp, and mistakes here affect deliverability for months.	Plan the ramp with the migration schedule and keep the old ActiveCampaign sends running until the new domain is stable.
Recurring hosting and upgrades	Mautic needs a VPS or dedicated server, not shared hosting, and each release line has a support end date that requires a planned upgrade.	Check the support dates on the releases page before choosing a version, and budget for upgrades each cycle.
Recurring cron and queue operation	Segment updates, campaign triggers and broadcasts run on staggered cron jobs, and queued email needs a messenger consumer kept running.	Automate monitoring of cron and the consumer so failures are caught before campaigns miss their send window.

What usually goes wrong, and how to prevent it

Most failed ActiveCampaign to Mautic moves fail in predictable places: consent records, overlapping sends, background jobs, hosting and sending reputation. Each risk below has a prevention step you can check before cutover, and each assumes the platform requirements you confirm on the day you install.

Lost unsubscribes and consent history

Contact exports often carry the subscription status but not the full trail of when and how a contact opted in or out. If unsubscribes are imported as ordinary tags or fields, suppressed contacts can be emailed again. Export opt-out status and consent dates from ActiveCampaign, map them to Mautic's do-not-contact handling, and confirm that a sample of unsubscribed addresses is blocked in Mautic before any send.

Duplicate sends during overlap

Running both platforms at once is common while teams verify the new setup. A contact who sits in an active ActiveCampaign automation and also in a Mautic campaign receives two messages. Freeze new automations in ActiveCampaign on a set date, copy only active lists you intend to keep, and record which platform owns each sequence so no journey runs in both systems.

Cron jobs that silently stop

Mautic relies on cron jobs for segment updates, campaign updates and campaign triggers, and the docs say these should be staggered. If they are not scheduled, campaigns look configured but never fire. Schedule each command as documented, add a messenger consumer when emails are queued, and set an alert on job failures so a stalled queue is noticed within a day rather than after a missed campaign.

Shared hosting chosen for cost

Mautic's project states that it should not be installed on shared hosting and recommends a VPS or dedicated server. Teams that pick a low-cost shared plan to save money often hit limits on cron, memory and background workers, which then surface as stuck imports and delayed sends. Choose a VPS or dedicated server during planning and budget it as a recurring cost alongside the email provider.

Sending domain reputation loss

Moving a large list to a new sending domain or IP from a cold start can push mailbox providers to filter messages. Warm the new domain gradually, start with the most engaged contacts, and keep bounce and complaint rates visible from the first send. Authentication records and the sending schedule should be checked with your email provider before the list is moved, because Mautic does not manage reputation for you.

Unsupported PHP or database versions

Mautic's requirements and support windows change by release, so a version that worked in a test install can fall outside support later. Mautic 7.0 requires PHP 8.2 to 8.5 and MySQL 5.7 or higher with InnoDB, or MariaDB 10.2 or higher. Confirm the current requirements page, choose a release whose security support runs past your go-live and planned upgrade window, and record the chosen versions in your runbook.

Who runs Mautic after the move

Before cutover, decide who owns Mautic once it is live, because the platform does not patch, monitor or back itself up. Hosted ActiveCampaign carries those duties for you. With Mautic, the work sits with your team or the partner you contract, and it recurs for as long as you run the platform. Name a responsible owner, a backup owner and the on-call route for outages before the first CSV import.

Start with the hosting. The Mautic project says it should not run on shared hosting and recommends a VPS or dedicated server instead, so the server, its operating system, the web server (Apache, Nginx or IIS), and the PHP runtime all need an owner. Mautic 7.0 requires PHP 8.2 to 8.5 and a MySQL or MariaDB database, so confirm which PHP and database versions your chosen release supports and who tests each upgrade. Also plan the cron jobs for segments, campaigns and broadcasts, along with the queue consumer for email, because a silent cron failure stops sends without an obvious error.

Release cadence sets the maintenance calendar. The project's stated pattern is monthly patch releases, minor releases every three months and major releases every two years, and each line has its own security support end date on the Mautic releases page. Agree in writing who applies patches, who tests them against your campaigns and who signs off a major upgrade. Finally, choose the email delivery provider and its owner. That provider handles bounces, complaints and sending reputation for your domain, so ask whether it is your team, your integrator or a shared role, and confirm which party receives its alerts.

Questions buyers ask before moving from ActiveCampaign to Mautic

How much effort and cost should we expect when moving from ActiveCampaign to Mautic?

The cost is driven by scope and by who does the work, not by a fixed figure. Mautic itself is free to download and self-host, so the spend falls into components: a server (Mautic is not meant for shared hosting, so a VPS or dedicated server is the expected base), a database, an email delivery provider, the one-time migration work, and the ongoing upkeep of upgrades, backups and cron jobs. Ask any implementation partner for a written quote that lists each component separately, states what is one-time and what recurs, and names the assumptions behind the effort, such as contact count, number of automations and how many forms and tracked sites need rebuilding. Also ask who pays for the email provider and whether that cost scales with volume.

How long does an ActiveCampaign to Mautic migration take?

The duration depends on scope, so confirm it in writing rather than relying on a general estimate. The main variables are the number of contacts and custom fields to map, how many automations need to be rebuilt as Mautic campaigns, how many forms, landing pages and tracked websites are involved, whether the sending domain needs warming, and how much testing the team requires before cutover. Mautic's own documentation recommends background imports for large CSV files, which adds a processing step to plan for. A fixed-scope agreement should list the deliverables and the timeline before work starts.

Can our team migrate to Mautic on its own?

Yes, a capable team can do it without outside help, provided it has the skills and time for the work. The practical checklist includes provisioning a server that meets Mautic's requirements, installing Mautic from the production package or with Composer, configuring cron jobs and the messenger consumer, exporting and mapping data, rebuilding automations, and connecting an email provider. Teams that lack in-house PHP, Linux, database and email deliverability experience often choose a fixed-scope engagement for part of the work, such as installation, data mapping or hardening, while keeping day-to-day operation in house.

What does the work require from our internal staff?

Expect to involve marketing operations, the person who owns the ActiveCampaign account, someone who can administer a Linux server and database, and whoever manages the sending domain. Marketing staff need to confirm which automations are still in use, define consent and list ownership, and approve the rebuilt campaigns. Infrastructure staff need to run the server, schedule the Mautic cron jobs, monitor the queue and handle backups. Someone must also own upgrades, since Mautic publishes monthly patch releases, minor releases every three months and major releases every two years, and each release line has its own support end date.

Do contacts, tags, custom fields and automations transfer automatically?

No. Contacts and their data have to be exported from ActiveCampaign and imported into Mautic, and Mautic imports contacts from CSV with automatic column to field mapping, so you still need to check field types and map any custom fields that do not match. Tags and segments are usually recreated and checked, and automations are not copied over: they are rebuilt as Mautic campaigns, with triggers, conditions and timing re-entered and tested. Plan for a test import on a sample file before the full load, and confirm with your vendor how historical engagement data is handled, because that data may not map one for one.

What happens to our sending reputation when we switch?

Sending reputation belongs to the sending domain and IP addresses, so a switch can affect delivery if the new setup is not prepared. Mautic does not send mail on its own reputation: you connect an email provider, authenticate your domain with the standard sender records your provider requires, and warm the new sending domain gradually. Only import contacts who have a clear opt-in, suppress bounces and unsubscribes, and keep the list clean from the start. Ask whoever runs the migration to document the authentication setup, the warm-up plan and how bounce and complaint feedback is monitored, because those controls decide inbox placement more than the platform does.

Is moving to self-hosted Mautic a compliance decision as well as a cost decision?

It can be both, because self-hosting keeps contact records and consent data inside your own database and infrastructure, which matters for data residency and for internal controls. DeployOpen prepares systems, controls and evidence for compliance assessments, but it does not issue audit reports, attestations or certifications; independent auditors and certification bodies do that. Before migrating, confirm with your compliance lead which records, consent evidence and retention rules must carry over, and document where Mautic, the database, backups and the email provider process personal data.

How DeployOpen works on this

DeployOpen plans, implements and hands over self-hosted open-source platforms inside your own infrastructure, so the move from ActiveCampaign to Mautic is scoped in writing before any work starts. The engagement covers contact export, field mapping, rebuilt automations, tracking and sending setup, with documentation your team keeps after handover.

How we scope

Inventory ActiveCampaign contacts, tags, custom fields, lists and automations to define what moves and what is retired.
Agree the hosting target, database, PHP version and sending domain in the written scope before work starts.
Set out which email delivery provider, forms and site tracking pages are in scope, and which are excluded.

How we build

Install Mautic on your own server or VPS, since the project advises against shared hosting, and configure it for your environment.
Map exported CSV columns to Mautic contact fields, run imports through the background console command, and check counts after each batch.
Rebuild automations as Mautic campaigns and segments, then test trigger logic and cron scheduling with sample contacts.

How we hand over

Document the installation, cron schedule, import steps, campaign logic and sending domain configuration for your administrators.
Walk through the import and campaign results with your marketing and IT owners and record open decisions.
Provide a runbook covering backups and the Mautic upgrade path, including which release branch you have chosen to follow.

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.
Confirm with us during scoping which support and testing items are included in the fixed scope and which are optional.

Migrate from ActiveCampaign to Mautic