What a Mautic migration involves
This page covers two kinds of move. The first is bringing contacts, consent records, segments, emails and campaign logic from another marketing automation tool into Mautic. The second is moving an older self-hosted Mautic install across one or more major versions. Both are usually triggered by a vendor contract that is ending, a licensing change, an end of support date for the current platform, or a tool that no longer fits how the marketing team works. Each trigger should set the deadline for the project, so confirm the date that actually constrains you before anything else is scheduled.
Mautic itself is free software, licensed under GPL-3.0, so the cost of a migration is not a license fee. The work sits in four places: the data (contacts, custom fields, consent and history), the logic (segments, campaigns, emails and their triggers), the infrastructure (servers, PHP, database, cron and email sending) and verification that the results match the source. Ask whether the source tool can export tracking history and consent timestamps in usable form, because those are the fields most often lost or flattened during a move.
Teams usually handle a move in-house when contact volume is modest, the number of campaigns is small, and they already have people comfortable with Linux administration, PHP and database work. Teams more often bring in a partner when volume is large, campaign logic is intricate, consent history must be proven, or nobody internal can own the server stack after go-live. Use those factors to decide, and ask any partner to state in writing which of the four areas above is in their scope and which remains yours.
What the work includes
A Mautic migration runs as eight workstreams that each end in a named deliverable. For version migrations, three additional workstreams cover the upgrade path, prerequisites and rollback.
Source tool inventory and audit
We catalog every contact list, segment, campaign, email, form, landing page, integration and scheduled export in the source tool, and note which ones are still in use. The output is an inventory and audit report that lets you decide what to rebuild, what to retire and what to archive before any data moves.
Contact and consent data mapping
We map source contact fields, custom attributes, tags and consent or opt-in records to Mautic contact fields and the consent handling you intend to run. The field mapping document records each transformation and the consent evidence that must travel with each contact, so the reviewer can trace it later.
Segment and campaign logic translation
Source segment rules and campaign flows often use logic that does not map one to one onto Mautic's segment filters, campaign decisions and actions. We rebuild each one in Mautic and document where behavior differs, so the rebuilt campaign inventory shows which flows match the original and which were redesigned.
Email template conversion
We convert source email templates, dynamic content and personalization tokens into Mautic email templates and check how each one renders across major mail clients. Tokens that the source tool resolved differently are listed in a conversion log, with the test sends used to confirm each template.
Tracking and attribution continuity
We plan how open, click and conversion tracking will continue after cutover, including tracking domains, form and landing page scripts, and UTM capture on contacts. The reconciliation report compares event counts and attribution fields between the old and new systems over the parallel period.
CRM and integration reconnection
We reconnect Mautic to the CRM, webhooks and internal systems the source tool used, such as HubSpot or Salesforce through their plugins or the API. For each connection we document which data moves in which direction, how duplicates are prevented, and which credentials are held and by whom.
Cutover and parallel running
We schedule the final data load, switch sending and tracking to Mautic, and run both systems in parallel for an agreed period while campaigns are checked. The cutover runbook names the go or no-go checks, the freeze window for contact changes and the owner of each step.
Documentation and handover
We hand over the runbook, field mapping document, campaign inventory, integration map and operating notes so your team can run Mautic without us. Each document is written for the people who will maintain campaigns, cron jobs and integrations after launch.
What drives cost and duration
This table lists the factors that change the effort of a Mautic migration, why each one matters, and how to keep it manageable before the quote is written.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Contact volume and history depth | Every contact, its activity history and its custom field values must be mapped, validated and imported, so the record count and years of history set the size of the data work. | Agree in writing which history is migrated (for example, the last set of years of activity) and archive the rest outside Mautic. |
| Consent channels and legal basis records | Each consent status, channel and recorded legal basis must map to Mautic's consent and DNC fields without losing its origin, which is often the slowest part to verify. | Inventory consent sources early, retire channels no longer in use and agree which legal basis fields are the system of record. |
| Segments and campaigns | Segment filters and campaign flows are rebuilt or translated by hand, and each branch, wait step and decision point adds testing time. | Migrate only live segments and active campaigns, and rebuild complex flows as simpler versions after sign-off. |
| Email templates and custom code in the source tool | Templates need conversion to Mautic's builder or theme format, and any custom scripts or code in the source tool must be rewritten rather than copied. | Count templates in use, drop unused ones and move logic into standard Mautic features before writing custom plugins. |
| Integrations (CRM, webhooks, ad platforms) | Each connected system needs its own field mapping, credentials, test data and a cutover plan so duplicate or missing contacts do not appear. | List every integration with its direction of data flow and decide which ones are rebuilt, paused or retired at cutover. |
| Source tool export limitations | Some tools cap export size, omit activity history, or export without relationships between contacts, segments and campaigns, which forces extra extraction work. | Test a full export from the source tool in the first phase and confirm exactly what it omits before scoping the import. |
| Tracking history requirements | Keeping page visit and email open history means mapping identifiers across tools, which is a separate task from importing contacts. | Decide whether tracking history is kept, reduced to a summary or started fresh, and state the choice in the scope. |
| Number of environments | Each environment (development, staging, production) needs its own install, cron jobs, mail settings and data refresh, multiplying setup and test work. | Limit environments to what the test plan needs and automate build steps so each extra environment is a repeat, not a rebuild. |
| Starting Mautic version and distance to a supported release | Migrating an older install across major versions means PHP and database changes, plugin compatibility checks and several upgrade steps. The Mautic releases page lists support end dates, so check the installed version against them first. | Confirm the installed version and PHP version early, and choose the target release from the supported list on the Mautic releases page. |
Project phases and outputs
The sequence moves a Mautic migration from source inventory to a verified, monitored production system with a handover your team can run.
Audit the source and inventory what moves
The team inventories the source tool's contacts, consent records, segments, emails, campaigns, integrations and reporting history, and identifies what is active, duplicated or obsolete. The output is a signed-off migration inventory that lists each object, its owner and whether it migrates, is rebuilt or is retired.
Design the target model
DeployOpen designs the Mautic contact model, custom fields, consent model, and the redesigned segments and campaigns, mapping each source object to its Mautic equivalent. The output is an approved design document that your data protection and marketing owners sign off before any data is loaded.
Build the environment on supported versions
The team builds the Mautic environment on a server you control, using a PHP version and a MySQL or MariaDB version that the target Mautic release supports, with web, cron and email processing configured. The output is a documented, reproducible environment that passes a smoke test and has been checked against the current requirements page for the chosen release.
Run test imports and reconcile
Test imports load contacts, consent records, custom fields and segment membership into staging, and reconciliation compares record counts, consent status and segment membership against the source inventory. The output is a reconciliation report listing every discrepancy and its resolution, repeated until the remaining differences are explained and accepted in writing.
Rebuild email and integrations
The team rebuilds sending domains, email templates, tracking, CRM connectors and any webhooks or API integrations, and verifies each one against test contacts. The output is a tested list of working flows with owners, so no integration depends on a manual step that exists only in the old tool.
Run in parallel and cut over
Both systems run for an agreed period while the team checks sends, segment updates, campaign triggers and consent suppression against each other, then production traffic and sending switch to Mautic at a planned cutover. The output is a cutover record covering the final delta load, rollback criteria and the confirmed owner for each switched flow.
Monitor after cutover and hand over
After cutover the team watches queues, cron runs, bounce and complaint rates, and integration errors, then hands over runbooks, configuration records and admin access to your operators. The output is a signed handover pack and a support boundary agreed in writing. The exact schedule for all phases is set in the written scope and depends on the drivers described in the previous section.
What stays in-house and what goes to a partner
This table shows who typically owns each part of a Mautic migration, what skills that owner needs, and where your own staff must keep control even when a partner does the technical work.
| Work area | Typical owner | Skills required |
|---|---|---|
| Legal and consent decisions | Your legal and privacy owners decide, partner documents the evidence | Privacy and consent law knowledge, ability to define lawful basis per contact source |
| Campaign strategy and content | Your marketing team | Campaign design, messaging, audience knowledge, email content production |
| Source data export and business rule interpretation | Your marketing operations staff with partner support | Knowledge of the old tool's data model, segment logic and suppression rules |
| Server build, PHP and database configuration | Your infrastructure team or a partner | Linux administration, PHP and Symfony hosting, MySQL or MariaDB tuning |
| Import scripting and reconciliation | Partner or an engineer with SQL and PHP knowledge | Relational data modeling, scripted imports, record counts and checksum comparison |
| CRM and integration rewiring | Partner with your CRM administrator | CRM admin skills, API credentials, field mapping, duplicate rule design |
| Cron and queue configuration | Infrastructure team or partner | Cron scheduling, staggered job timing, message queue worker supervision |
| Cutover and rollback | Partner leads the runbook, your operations owner approves each step | Change control, DNS and mail sending switch planning, tested rollback steps |
| Post-launch operations | Your marketing operations team, with a partner on retainer if agreed | Campaign monitoring, bounce and complaint review, release tracking for upgrades |
What usually goes wrong
Most failed Mautic migrations trace back to a small set of predictable risks. Each card names the risk and the check that prevents it, using reconciliation counts, consent sign-off, a staged import and a tested rollback.
Opted-out contacts emailed
Consent and suppression records can be lost or flattened during import, so people who opted out receive campaign email. Get consent sign-off on how each source status maps to Mautic before the first load. Reconcile opted-out and do-not-contact totals between source and target, and confirm suppression holds on a test send.
Duplicates and detached tracking history
Re-running an import without a stable unique key creates duplicate contacts, which splits history and doubles sends. Page visits and form submissions loaded separately may also fail to attach to the right contact, which breaks attribution. Choose a stable external ID before loading, run staged imports into a copy, and reconcile matched and created counts after each run.
Segments that do not rebuild
Segments stop updating when the cron jobs for segment updates and campaign triggers were never configured, or when they all start at the same time and overlap. Stagger each job as the Mautic cron documentation advises, then confirm a test contact moves into and out of a segment after a change. Include job schedules in the rehearsal.
Campaigns firing on wrong dates
A time zone or date format change during import can shift the dates used by timed campaign steps, so messages fire early, late or repeatedly. Record the source time zone and date format, then check a sample of dated records by hand. Test each timed step against a dummy contact with a known date before the campaign is enabled.
Deliverability drop after domain change
Moving to a new sending domain without verified authentication records can lower inbox placement from the first send. Confirm SPF, DKIM and DMARC are published and passing for the sending domain before any migrated list is mailed. Increase volume in stages, and reconcile bounce and complaint counts after each stage.
Version jumps and unsupported PHP
Skipping intermediate major releases or running on an unsupported PHP version can leave a migrated install broken or outside support. Mautic 7.0 requires PHP 8.2, 8.3, 8.4 or 8.5, and each release has its own support window. Follow the upgrade path in the release notes on a staging copy, and rehearse a full rollback of files and database before cutover.
How the work differs by starting point
Moving from a commercial marketing automation product is mostly an export and mapping exercise. The effort depends on how much consent history, custom field structure and campaign logic the source can export cleanly.
- Export formats: Confirm with the vendor which formats contacts, activity, emails and campaign definitions can be exported in, and whether exports are capped by volume or by API rate limits.
- Consent records: Map opt-in source, timestamp and wording for each channel before import. Consent that cannot be proven at the source should not be imported as consented.
- Template conversion: Email and landing page templates usually need rebuilding in Mautic's template structure rather than copying HTML directly, which adds design and testing time.
- Campaign logic: Expect to redesign branching and wait steps by hand, because campaign definitions rarely transfer as working logic.
- Confirm with the source vendor and client: export limits, data retention terms for old tracking history, and who owns the decision on which history to keep.
Moving from an older self-hosted Mautic release across one or more major versions is a sequenced upgrade. The work is driven by the number of major steps, the PHP and database versions each step needs, and the custom code in place.
- Ordered upgrade path: Plan each major step in sequence and test every stop on a copy of the production database, not only the final target.
- Prerequisites: Mautic 7.0 requires PHP 8.2 to 8.5 and MySQL 5.7 or higher with InnoDB, or MariaDB 10.2 or higher, so older PHP and database versions often need upgrading first.
- Plugin compatibility: Check each plugin and custom theme against every intermediate release, since a plugin that works on the current version may not work on the target.
- Tracking history: Confirm how contact, tracking and campaign data from the older install maps to the new schema before cutover.
- Confirm with the client environment: the current Mautic version, PHP and database versions, the plugin inventory, and whether the old install is still under a paid extended support arrangement.
When Mautic has been running as a front end to a CRM, the migration centers on reconnecting Mautic to the CRM after the move. Records must not be duplicated or overwritten during the reconnection.
- Plugin versions: Confirm the Salesforce or HubSpot plugin version against the target Mautic release before planning the work, since the integration layer is tied to specific versions.
- Sync direction: Decide which system owns each field and whether data flows one way or both ways during and after the cutover.
- Field mapping: Rebuild the contact and company field mapping, and test it with a small set of records before enabling the full sync.
- Duplicate control: Set matching rules on email or CRM identifiers so that re-established syncs do not create duplicate contacts.
- Confirm with the CRM administrator: API user permissions, rate limits, and any custom objects that the integration must read or write.
In an air-gapped or restricted network, the migration depends on how software packages, plugin code and dependencies reach the servers without outbound internet access. The schedule is driven by package delivery and by the mail path rather than by data volume alone.
- Package delivery: Plan how the Mautic production package, Composer dependencies, PHP extensions and any npm assets are built on an approved side and carried across for installation.
- No external connections: Plugins that call external services, such as CRM connectors, must be checked for their network needs before they are accepted into the environment.
- Mail services: Confirm how outbound email will reach recipients through an internal relay, since most external sending services will be unavailable.
- Cron and queue: Cron jobs and the messenger consumer must run inside the restricted network, with their own monitoring.
- Confirm with the client security team: the approved transfer process, the allowed package sources, and which external endpoints, if any, are permitted by policy.
What you need to provide
Before a fixed-scope quote can be written, the partner needs a full export from the source tool or API access to it, plus a test export that the team can inspect. The test export shows how contacts, custom fields, tags, segments and campaign steps are structured in practice, which is usually different from what the admin console suggests. Also provide a data dictionary for every custom field, including field type, allowed values and which system is the authoritative source. Without it, mapping decisions in the Mautic contact model are guesses.
Consent needs its own package. Provide the current consent records, the evidence behind each one (form, timestamp, wording shown, opt-in method) and any suppression or unsubscribe lists. Records without evidence cannot be imported as marketable consent without a legal decision, so your legal sign-off owner should confirm early which categories of consent will be carried over. Also provide segment and campaign definitions, email templates and assets, and the list of integrations with a named owner for each.
Infrastructure inputs are equally concrete: the sending domain and DNS access for SPF, DKIM and DMARC records, the target server or cloud account, and the mail sending service you intend to use. Mautic is not run on shared hosting, so confirm the hosting target early. Name one owner each for legal sign-off, marketing operations and infrastructure, with authority to make decisions during the project.
If the source export is incomplete, the gap surfaces during import as missing contacts, lost consent history or broken campaign logic, and it is much harder to explain after launch. Agree a reconciliation target before import starts: record counts per object type, consent counts per category, and a sample of contacts checked field by field against the source. The partner should then confirm in writing which differences are accepted and who signs them off.
Frequently asked questions
How much does a Mautic migration cost?
Mautic itself is free, so the cost is the work of moving your data and logic, plus the servers and any paid tools around it. The main drivers are the number of contacts and custom fields, how clean the source export is, how many segments, campaigns and email templates must be rebuilt, how many consent records need checking, and how far the source tool and Mautic versions are apart. Ask for a fixed-scope quote that lists each of these items, the deliverables and the exclusions. DeployOpen does not publish prices.
How long does a Mautic migration take to complete?
The schedule follows from the effort drivers and the written scope, so there is no fixed duration that applies to every migration. A single-source move with clean exports and few campaigns is planned very differently from a move with years of history, several source tools and many campaign branches. Before work starts, the scope should set out milestones, test cycles, the cutover window and who signs off each stage. Ask for the timeline as part of the written scope, with each milestone tied to a deliverable.
Can our own team migrate to Mautic without an outside partner?
Yes. An in-house team can run the migration if it has the skills listed in the in-house skills table on this page. These include data mapping, database work, server administration, cron and queue operation, email delivery setup and consent handling. The most common risks are underestimating export clean-up and testing campaign logic too late, before cutover. A partner is most useful where a skill is missing or where your team cannot free up time for testing and the cutover window.
What do we need to provide for a Mautic migration project?
You provide access and data: exports from the source marketing tool, a named business owner who approves mapping decisions, administrator access to the target servers or cloud accounts, and a sending domain that can be configured for email. You also provide the consent records with their original source and date, and a person who can confirm which segments and campaigns are still live. Ask the partner to list every input and its owner in the written scope, so that gaps appear early.
Can Mautic migrations keep contact tracking history?
Partly, and the answer depends on the source export. Contact fields, tags, segment membership and some activity records can be carried over when the source exports them in a usable format. Page visit and email open history depends on whether the source keeps event-level data and whether that data can be exported. Consent records must be migrated with their original basis, date and source, and only where your evidence supports them. Where evidence is missing, those contacts may need to be asked again for permission. Confirm each data type with the source vendor before the scope is agreed.
How do I upgrade an older Mautic install across major versions?
Move through major versions one step at a time, following the ordered path published for your starting version, with a verified backup and a staging copy at each stage. Each step has its own prerequisites, such as the supported PHP range, database engine, web server and npm requirements, so check them before you begin. Check support dates on the Mautic releases page before choosing a target. For example, Mautic 4.4 has paid Extended Long Term Support through 31 December 2026. Confirm the current path against that page at the time of planning, and test plugins and custom code at every step.
How DeployOpen delivers Mautic migrations
DeployOpen plans and runs Mautic migrations inside infrastructure you control, whether you are moving contacts and campaigns in from another marketing automation tool or moving an older Mautic install onto a supported release. Engagements are fixed-scope, with the work agreed in writing before it starts.
How we scope
- Inventory the source tool's contacts, consent records, segments, emails and campaign logic before any mapping begins
- Map each source field and consent status to a Mautic contact field, with the records that must be kept and those that will be retired named
- Agree the target Mautic version and PHP version against the current release support dates before the written scope is signed
How we build
- Stand up the target Mautic environment on a VPS or dedicated server, since the project advises against shared hosting
- Configure cron jobs for segments, campaigns and broadcasts with staggered schedules, plus the messenger consumer for queued email
- Run trial imports and test campaign logic on sample data, checking that tracking history and consent flags carry across intact
How we hand over
- Deliver a migration runbook covering the import order, field mapping, cutover steps and rollback path
- Document the cron schedule, queue worker setup and server configuration so your team can operate the platform after handover
- Provide a reconciliation report comparing record counts, consent states and segment membership between source and target
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after cutover, if you want it
- Plan follow-on upgrades against Mautic's monthly, quarterly and two-year release cadence, to be confirmed in your scope
- Confirm with your own compliance team which consent and retention evidence your assessors will need from the migration
