Mautic implementation plan and cost

What a Mautic implementation involves

The Mautic software has no paid edition. The project offers a free self-hosted download, so the budget for a Mautic project is spent on the work around the software: planning the contact model, hosting, configuration, integrations, email sending and training. Confirm this with your own licensing review, but expect the largest line items to be people and time rather than a license fee.

Most projects start from one of three triggers. The first is replacing an existing marketing tool, where the question is what must move across and what can be retired. The second is moving off a spreadsheet-driven process, where contact lists, segments and follow-up emails live in files that no one can audit. The third is launching a regulated consent model, where every contact needs a recorded basis for marketing and a way to withdraw it. Identify which trigger applies before you request a quote, because it determines how much design work comes before any configuration.

In-house or partner. A team with PHP, Symfony and Linux operations experience, a marketing operations owner and time to test campaigns can build in-house, especially for a single brand with a small contact base. A partner is usually worth considering when the project spans several CRM systems, requires a documented consent model, has a fixed launch date, or when the internal team will not be able to take on upgrades and cron and email queue operations after go-live. Ask any partner for a written scope that names the components, deliverables and acceptance tests before you compare prices.

What the implementation includes

A fixed-scope Mautic project usually moves through the same work packages. Each one should end with a named deliverable that your team can inspect, operate and hand to campaign owners.

Environment and server build

The partner builds the Mautic environment on infrastructure you control, following the project's requirements for PHP, the database and the web server, and avoiding shared hosting. Check that the scope names the PHP and database versions, the install method, and how web, cron and queue processes are separated. The deliverable is a configured, documented instance with a build record.

Contact model and custom fields

This package defines which contact attributes, custom fields and company records your marketing team needs, and how each one is named, typed and populated. Fields chosen early are costly to rename later, so decisions here drive the size of the later segment and campaign work. The deliverable is a documented data model with field definitions, owners and sources.

Segments and campaigns

Segments and campaign flows are built from the agreed audience and journey designs, including the triggers, decision points and wait steps each flow needs. Segment and campaign updates run through scheduled cron jobs, so the scope should state how many flows are in build and how they are tested before launch. The deliverable is a set of configured segments and campaigns with a flow diagram for each.

Email sending setup

This work covers the sending domain, authentication records, the outbound mail service, and the queue and broadcast processing that large sends depend on. Ask whether the quote includes the sending service account and who owns bounce and complaint handling after launch. The deliverable is a verified sending configuration with a test report and a sending runbook.

CRM integration

If Mautic must exchange data with a CRM, the scope should state which system, which direction data moves, which fields map, and what triggers a push. Duplicate contact handling is a common failure point and needs an explicit matching rule. The deliverable is a configured integration with a field mapping specification and a test log.

Consent configuration

Consent capture, preference handling and the record of when and how consent was given are configured against the processing basis your legal team has approved. Confirm with counsel which consent language and suppression rules apply in each market you email. The deliverable is a configured consent model with the forms, preference settings and suppression logic documented.

Testing and handover

Testing covers segment membership, campaign paths, email rendering, integration sync and consent suppression before launch. Training and handover give campaign owners and administrators the knowledge to run the system without the partner. The deliverables are a test record, a runbook for operations, and trained campaign and administration staff.

What drives cost and duration

Each row names one driver of Mautic implementation effort, explains why it changes the work, and gives one way to keep it under control in scope.

Driver	Why it changes effort	How to keep it under control
Contact volume and data quality	Larger, duplicated or inconsistent contact lists lengthen imports, cron processing and deduplication rules. Database sizing also grows with volume.	Clean and deduplicate the source list before import, and scope a data quality pass as a separate line item.
Custom fields, segments and campaigns	Each field, segment and campaign needs mapping, testing and documentation. Branching campaign logic takes the longest to verify.	Agree a field dictionary and a short list of launch campaigns in the written scope, and defer the rest to a later phase.
Email send volume and sending domain setup	Domain authentication, bounce handling and volume ramp-up depend on your mail service and often need DNS and mail administrator time.	Confirm the sending service and domain ownership early, and name who makes DNS changes and manages bounces.
CRM integrations (number and direction)	A one-way push to HubSpot or Salesforce is simpler than two-way sync, which needs field mapping and conflict rules in both systems.	Limit the first release to one direction and a short field list, and document which system owns each field.
SSO requirement	SAML setup needs identity provider configuration, certificates and attribute mapping, and it adds testing before go-live.	Decide at scoping whether SSO is needed at launch, and reserve identity provider time in the plan.
Consent and privacy obligations	Consent capture, preference options, retention rules and data subject requests must be designed and tested before any send.	Settle the lawful basis and consent wording with your legal team first, then build and test the capture flows once.
Migration from another tool	Moving contacts, consent records, segments and campaign logic requires mapping and reconciliation, and some history may not transfer cleanly.	Inventory source exports and consent evidence during discovery, and reconcile a sample before cutover.
Training audience size	More marketers, admins and approvers mean more role setup, sessions and documentation, and more questions after launch.	Train a core group who coach others, and keep role guides short and tied to the agreed campaigns.
Environments and release chosen	Each environment needs its own install, cron jobs and data handling. The release sets PHP, database and support requirements.	Keep one non-production copy for testing. Pick a release whose security support covers your run period, confirmed on Mautic's releases page.

Project phases and outputs

The sequence moves from agreed scope to a tested, trained and supported Mautic install, with each phase closing on a defined output.

Run discovery and confirm scope
The partner and your team map the marketing use cases, contact sources, existing tools, consent rules, email domains and integration targets. The phase closes with a written scope, a list of open questions and a named owner for each decision, which becomes the basis of the fixed-scope quote.
Design the architecture and hosting
The team selects the target environment, server layout, database, web and cron roles, and the Mautic release line to deploy. It also confirms the PHP and database versions required by that release and whether a VPS or dedicated server is used, since shared hosting is not supported. The output is an approved architecture document and a bill of materials to confirm with your infrastructure team.
Build and harden the server
Engineers provision the servers in your cloud account or data center, install the web server, PHP, the database and Mautic using the installation method chosen in design, and configure TLS and backups. The phase ends when a clean install runs, backups restore in a test, and the cron and queue services are scheduled, with proof recorded for your change records.
Model contacts, fields and consent
The team defines the contact model, custom fields, tags, owners and consent data, and maps each source field to its Mautic destination. The output is a signed data dictionary that your legal and privacy owners approve before any import, so that consent records and personal data handling are settled before contacts move.
Build segments, campaigns and email sending
Engineers build the segments, campaign flows, point and trigger rules, email templates and sending configuration, including sending domain authentication and the broadcast and queue processes. Each campaign is tested with seed addresses and reviewed against the scope. The phase closes when test sends pass, the queue drains as expected and the sending settings are documented.
Connect the CRM and run integrated testing
The team configures the agreed CRM connection, whether the Salesforce or HubSpot plugin or an API integration, sets field mappings and sync direction, and tests duplicate handling. Functional, load and consent tests run against staging data. The output is a test report with each failure resolved or accepted in writing by the business owner.
Train users and hand over to hypercare
Your campaign and admin staff are trained on the configured model, runbooks cover cron, queue, backup and upgrade tasks, and the go-live date is set. Hypercare then covers the agreed period of post-launch support and issue triage. The phase closes with a handover pack and a signed acceptance of the hypercare exit criteria. Length of hypercare follows the agreed scope.

What teams keep in-house and what they outsource

This table sets the work a marketing operations team usually owns against the infrastructure and integration work a partner often takes on, with the skills each needs and the typical failure when the wrong team owns it.

Work area	Usually owned by	Skills required	Typical failure if the wrong team owns it
Campaign logic and automation flows	Marketing operations	Campaign design, segment logic, understanding of contact lifecycle stages and goals	Campaigns built by engineers often mirror system fields rather than buyer journeys, so emails fire on the wrong triggers
Content, email templates and landing pages	Marketing team	Copywriting, brand standards, template editing, accessibility basics	Templates built without marketing review ship with broken merge tags or unapproved claims
Contact list hygiene and custom field use	Marketing operations, with data owner sign-off	Data modeling judgment, deduplication rules, knowledge of consent fields	Field sprawl and duplicate contacts when no one owns the naming and cleanup rules
Reporting and campaign analytics	Marketing operations	Attribution basics, dashboard building, interpreting open and click data	Reports built on raw tracking data overcount opens and mislead budget decisions
Server build, PHP and database setup	Partner or platform engineering	Linux administration, PHP and Symfony runtime tuning, MySQL or MariaDB administration, web server configuration	Installs on shared hosting or undersized servers that fail under send volume or miss supported PHP versions
Cron, queue and messenger configuration	Partner or platform engineering	Scheduler setup, staggering jobs, queue consumer supervision, log monitoring	Segments and campaigns stop updating silently, or queued email stalls with no alert
CRM integration (Salesforce or HubSpot)	Partner, with marketing operations defining field mapping	API authentication, field mapping, sync direction design, duplicate prevention	Two-way sync overwrites CRM records or creates duplicate contacts because direction and matching rules were never agreed
Email deliverability setup	Partner or platform engineering, with the sending domain owner	DNS administration, sender authentication, bounce handling, reputation monitoring	Mail lands in spam or is rejected because authentication records were configured by marketing without IT review

What usually goes wrong

Most Mautic projects that run into trouble fail on setup decisions made early, not on the software itself. Each risk below has a prevention step to write into the scope and a sibling topic that covers the detail.

Unsupported host or runtime

The Mautic project advises against shared hosting and recommends a VPS or dedicated server. Mautic 7.0 also requires PHP 8.2 to 8.5 and MySQL 5.7 with InnoDB or MariaDB 10.2 or higher. Confirm the target release's requirements and the host's PHP and database versions before sizing the server. See Mautic high availability and Mautic upgrades and support.

Cron jobs and email queue not running

Segments, campaigns, campaign triggers and segment broadcasts depend on cron jobs, and the docs say these should be staggered. Queued email also needs the messenger consumer running. If any job is missing or overlaps, contacts stop moving through campaigns. Include a schedule and a monitoring check for each job in the plan. See Mautic cron jobs and email queue setup.

Email sent without a checked setup

Sending to contacts before the sending domain, authentication records, bounce handling and sending limits are verified can damage deliverability for the whole organization. Confirm which sending service will be used, who owns its account, and what it costs per month at your planned volume. Test a send to seed addresses before any campaign goes live. See Mautic cost of ownership and editions.

Imported contacts without consent records

Contacts loaded from spreadsheets or another tool often arrive without evidence of how they opted in or when. Without that record, the organization cannot show lawful basis or honor withdrawals reliably. Add consent source, date and wording fields to the contact model before import, and map existing records to them. See Mautic migration and Mautic security hardening.

SAML attributes missing at sign-in

Mautic's SAML single sign-on needs the identity provider to send email, first name and last name attributes. If any is missing or mapped to a different claim name, users may fail to sign in or be created with incomplete profiles. Test with a pilot group and confirm attribute names with the identity team before cutover. See Mautic SSO and identity integration.

Duplicate contacts from CRM sync

When Mautic is connected to Salesforce or HubSpot, contacts can be created in both systems with different identifiers, producing duplicates that split activity history. Decide which system owns each contact, define the matching key, and agree the field mapping and push triggers before go-live. Run a dry-run import on a copy of the data. See Mautic CRM integration with Salesforce and HubSpot.

How the work changes by starting point

Moving from a commercial marketing automation tool changes the estimate mainly through data mapping and contact history. Your current tool's export options set the first limit on what can move, and the consent evidence behind each contact often sets the second.

Questions to answer first:

Export scope: Which contacts, consent records, segments, emails and campaign logic can the current tool export, and in what format?
Consent evidence: Does each contact carry an opt-in date and source? Missing evidence is hard to reconstruct after cutover.
Campaign rebuild: Campaigns are rebuilt in Mautic's model, so each one needs design time, not only a copy step.
Sending domain: Will the sending domain and its reputation move with you, or start fresh? Confirm this with your email provider.
Parallel running: How long will the old tool stay live, and who checks that both systems agree?

What the client needs to provide

Most delays on a Mautic project start before any installation begins. Before work starts, the client supplies a short list of inputs, and each one has a named owner who signs it off in writing. The list covers server or cloud account access, DNS control for the sending domain, a sending service decision, a contact data extract with consent evidence, CRM and administrator accounts, an identity provider if single sign-on is in scope, named business owners for segments and campaigns, and a decision on which Mautic release line to deploy. The written scope should list each item, its owner, and the date it is needed.

Infrastructure access and DNS are usually owned by the IT or platform team. The team must provide a Linux host or cloud account that meets the platform requirements in the Mautic requirements page, which excludes shared hosting, plus network rules for the web and cron servers. For email, the marketing or deliverability owner should confirm the sending domain and whether the client will use an external transactional or bulk sending service. DNS changes for SPF, DKIM and DMARC must be made by someone with registrar and DNS control, and those records may need several days to propagate, so the owner should confirm the change window early.

The contact data extract and consent evidence carry the most legal and data protection risk. The data protection or legal owner should approve what is exported, how consent records are represented, and which contacts may be imported at all. Business owners should name the segments and campaigns they expect on day one, since the contact model and custom fields depend on them. The release line decision belongs to the platform owner, who should confirm support dates on the Mautic releases page before choosing a version. If an input arrives late, the implementation team should pause the affected workstream, record the impact in the change log, and agree a revised date before resuming. Ask the partner to state in the quote which inputs gate which milestones.

Frequently asked questions

How much does a Mautic implementation cost?

The software itself is free, so the cost is the work to design, build and hand over your Mautic environment. The main drivers are the number of contacts and data sources to migrate or map, how many custom fields and segments the contact model needs, the number of campaigns and email templates, the CRM integration, the hosting and email sending setup, and how much training your team needs. Each of these is paid as implementation labor, while servers and email sending are recurring costs you pay to providers. DeployOpen does not publish a price list. Ask for a fixed-scope quote that lists each deliverable, the assumptions behind it, and what your team must provide.

How long does a Mautic implementation take?

Duration depends mainly on scope and on how quickly your team makes decisions. The schedule is set by the contact model and consent design, the number of integrations, the state of your existing data, and the time needed to test cron jobs, email sending and campaign logic with real volumes. Projects that move contacts and history from another tool usually take longer than a clean install. No fixed duration is stated here, so ask for a timeline in the written scope that shows dependencies, review cycles and the decisions needed from your side.

What does DeployOpen need from our team?

Expect to provide named owners for marketing operations, data protection and IT, along with access to your CRM, existing marketing tools, DNS, email domains and the hosting environment you control. Marketing needs to supply campaign requirements and approve templates, while legal or privacy staff should confirm consent rules and retention. Your IT team should confirm where Mautic runs, how it is backed up and who receives alerts. The scope should name these inputs and the dates they are needed, so delays in your team do not become unpriced change work.

Can our own staff implement Mautic without a partner?

Yes, if you have people who can administer a PHP and Symfony application on a Linux server, configure cron jobs and a messenger consumer, manage a database and handle email authentication. Mautic installs from a production package or Composer, so the technical barrier is manageable, but design choices such as the contact model, consent handling, segment logic and CRM field mapping are harder to reverse later. Many teams hire a partner for the design and handover, then run the platform themselves. Compare your internal capacity against the written scope before deciding.

Which Mautic release should we choose for a new install?

Choose a release that is still under support for the whole period you plan to run it, and check the current support dates on the Mautic releases page before you commit. Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027, while Mautic 7.2 receives active and security support until 30 September 2026. Your PHP version must match the release requirements, and the server must not be shared hosting. Confirm the final choice with the project and your security team during scoping.

How DeployOpen scopes, delivers and hands over Mautic work

DeployOpen plans, implements, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so the Mautic cost conversation starts from a written scope in your environment. Engagements are fixed-scope, with the scope, deliverables and timeline agreed in writing before work begins.

How we scope

Review your contact volumes, email sending plan and CRM landscape before estimating any build work.
Document the server layout, PHP and database versions and the cron and queue design the quote assumes.
Agree in writing which contact fields, segments, campaigns and integrations are in and out of the fixed scope.

How we build

Install Mautic from a supported release line in your cloud account, data center or air-gapped network.
Model contact fields, segments and campaign logic against the scope before building the automation.
Configure cron jobs, the broadcasts command and the messenger consumer, then test sends with seed contacts.

How we hand over

Deliver configuration notes, a field and segment inventory, and a runbook covering cron and queue operation.
Walk your administrators through campaign building, consent handling and the upgrade path for their version.
Confirm acceptance criteria against the written scope so both sides agree when the project is complete.

How we support

Offer ongoing support, upgrades and testing as a retainer once the fixed-scope project closes.
Plan release upgrades around the patch, minor and major cadence and the support dates for your version.
Ask us to quote upgrade and support work separately so the recurring cost is visible from the start.