Mautic cost of ownership and editions

Why Mautic cost of ownership starts after the free download

The Mautic licence is free, but running Mautic is not. For a three-year model, most of the cost sits in hosting, email delivery, upgrades and the people who build and run campaigns, and none of those come with the download. The project's GitHub repository is licensed under GPL-3.0, which lets your organization install, modify and run the software without paying a licence fee. Mautic has no paid edition of the software itself. The mautic.org site offers the self-hosted download alongside separately promoted managed hosting services, so any paid offer you see is a service wrapped around the software.

GPL-3.0 is a copyleft licence, so its terms matter when you distribute software, not when you only run it internally. If your custom plugins or themes will be handed to a vendor, a partner or another group that redistributes them, ask counsel to confirm which obligations apply before the build starts. Confirm the hosting model as well. Mautic's requirements page says it should not be installed on shared hosting and recommends a VPS or dedicated server, and the PHP and database versions must match the release you choose. Each of these items becomes a recurring line in your model.

Upgrades are the cost most often left out of first estimates. The project's stated cadence is monthly patch releases, minor releases every three months and major releases every two years. Support windows differ by release. Mautic 6.0 receives security support until 30 September 2026, Mautic 5.2 until 30 June 2026, and Mautic 4.4 has paid Extended Long Term Support through 31 December 2026. Before you model years two and three, check the current release table and the support end date of the version you plan to run, then budget for the testing of plugins, custom fields and integrations that each major upgrade will require.

A small install can often be costed in-house. List the server, the email sending service, the cron and queue workers, the people who run segments and campaigns, and the annual upgrade effort, then separate one-time setup from recurring spend. Teams usually bring in a partner in two situations: for a fixed-scope cost review that tests these assumptions against a written plan, or for a larger regulated install where single sign-on, consent handling and high availability add effort. Ask any provider to split the quote into one-time and recurring costs and to state the contact volume and release assumptions behind it. DeployOpen does not publish a price list, and a quote follows from the written scope.

What a Mautic cost of ownership review includes

A cost of ownership review is a fixed-scope piece of work that ends in a written model and recommendations. Each card below is one part of that deliverable, and together they show the reader which costs recur, which are one-time, and which decisions change the total.

Inventory of the install

The review starts with a record of what runs or is planned: the Mautic version, PHP version, MySQL or MariaDB version, web server, npm where it applies, hosting type, and the cron jobs, queue consumers, plugins, CRM connectors and SSO setup in use. Mautic's documentation says it should not run on shared hosting, so the inventory confirms the hosting model early. Ask the partner to list every component the platform depends on, including those that no one on your team currently owns.

Cost model with one-time and recurring lines

The written model separates one-time costs, such as implementation, migration and custom development, from recurring costs, such as servers, the email sending service, upgrades, support and staff time. For each line it names who is paid, whether that is your team, a partner or a vendor, and what drives the amount up or down. Ask for each recurring line to be stated per year so it can be compared with the cost of a hosted marketing automation product.

Release and support calendar

The review maps each Mautic version in use to its support dates. The releases page lists Mautic 5.2 with security support until 30 June 2026, Mautic 6.0 until 30 September 2026, Mautic 7.2 with active and security support until 30 September 2026, and Mautic 4.4 under paid Extended Long Term Support through 31 December 2026. Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027. Confirm these dates against the releases page at the time of the review, since they can change.

Decisions that move cost

The model lists the choices that most change the total and sets out the cost effect of each option. Typical items are the target major version, self-hosted VPS or dedicated server against a managed Mautic service from another provider, the transactional or bulk email sending service, the CRM connector and its direction of data flow, SSO through a SAML identity provider, and the amount of custom plugin or theme code. Each decision should show what it adds to one-time work and what it adds to recurring work.

Staffing and campaign operations

The model estimates who runs the platform after launch and the workload they carry. This covers cron scheduling for segments, campaigns and broadcasts, monitoring of queued email, plugin compatibility checks before each upgrade, and the people who build and approve campaigns. Ask the partner to name the roles, state the skills each role needs, and show which tasks would move to a support retainer if your team cannot cover them.

Deliverables and exclusions

The review produces a written model, an inventory, a support calendar and a list of recommendations. It does not include the implementation itself, and it does not produce an audit report, attestation or certification. Confirm the scope, deliverables and timeline in writing before work starts, and ask which of the items above depend on information only your team can provide, such as contact volumes, consent sources and existing CRM contracts.

What drives Mautic cost of ownership up or down

This table lists the factors that change what a self-hosted Mautic install costs to run, with the mechanism behind each one and the practical lever for keeping it under control. Read it as a checklist for your own environment: the drivers that matter most are the ones your contact volume, sending pattern and integrations push hardest. Most of the recurring cost comes from keeping workers, servers and the PHP runtime current, not from the software license, which is free.

Driver	Why it matters on Mautic	How to keep it down
Contact volume and database size	Segment updates, campaign evaluation and reporting all query the contact table, so the database and server need more capacity as contacts grow.	Agree the expected contact count in the scope, prune or archive inactive contacts under your retention policy, and size the database and web tier against that figure.
Number of segments	Each segment is recalculated by the segment update cron job, so many complex segments lengthen every run and can delay campaign triggers.	Consolidate overlapping segments, use campaign logic instead of duplicate lists, and review segment filters before adding new ones.
Campaigns and triggered sends	Campaign triggers run on the campaign cron job, and each active campaign adds work on every run, especially when it reacts to many contact actions.	Retire finished campaigns, stagger cron schedules as the Mautic docs recommend, and test campaign load before launching large audiences.
Sending volume and queued email	When emails are queued, the messenger consumer must run continuously, and large batches add mail server load and bounce handling work.	Confirm batch limits with the cron setup, run the messenger consumer under a process supervisor, and agree the sending service plan against your monthly volume.
Number of environments	Each environment (development, test, production) needs its own server, database, cron jobs, workers and upgrade testing, which multiplies infrastructure and effort.	Keep non-production environments small, refresh them from sanitized data only when needed, and automate the build so new environments are cheap to create.
Custom plugins and themes	Custom code must be retested on every minor and major release, and plugins written against older Symfony or Mautic internals may need rework.	Limit custom code to what the business needs, keep it in version control, and budget upgrade testing as a recurring item in the scope.
CRM and SSO integrations	The HubSpot and Salesforce plugins and SAML single sign-on each add configuration, credentials, field mapping and monitoring that must survive upgrades.	Define the sync direction and field map before build, use the vendor-supported plugin where it fits, and confirm the identity provider attribute requirements early.
Version choice and PHP upgrade path	Mautic 7.x supports PHP 8.2 to 8.5, and each major release changes the minimum requirements, so older stacks force a platform migration.	Choose a release whose support window covers your planned operating period, check the releases page before each upgrade, and plan PHP upgrades with the Mautic release cycle.
Compliance evidence needs	Auditors ask for consent records, access reviews, change logs, backup tests and patch evidence, which Mautic and the server must produce on demand.	Agree the evidence list at scope stage, enable logging and backups from day one, and ask the implementation partner which controls they will document. DeployOpen prepares evidence but does not issue audit reports.

How a Mautic cost review moves from inventory to a three-year model

The review runs as an ordered sequence, so each step produces a written artifact the next step depends on. The end result is a cost model the client can check, change and use to decide between staying on their current release, upgrading, or changing the setup.

Inventory the installed version and its dependencies
We record the installed Mautic version, the PHP and database versions the server runs, the web server, and the Node and npm setup used for assets. We also list every installed plugin, custom theme and external integration, including CRM connectors and single sign-on, with the version and owner of each. The output is a dependency inventory that shows which items will need checking against any target release. The step is done when the client has confirmed the inventory matches what runs in production.
Map cron, broadcast and queue workloads
We trace which scheduled jobs run for segment updates, campaign updates and campaign triggers, which command sends segment broadcasts, and whether a messenger consumer processes queued email. We record the schedule, the overlap between jobs and the host each one runs on. The output is a workload map that shows what runs when and what depends on what. It is complete when every scheduled job and queue has an owner and a documented run pattern.
Size hosting and sending needs
Using the inventory and workload map, we estimate the contact volume, send frequency, peak batch sizes and the hosting footprint needed for web, database, cron and queue roles. We also list the email sending service the client currently uses or plans to use, along with its pricing model as the client provides it. The output is a sizing sheet with each assumption stated and tied to a source the client can confirm. It is done when the client has signed off on the volumes used in the model.
Build a release calendar for supported versions
We map the installed version and each candidate target against the published support dates, including security support windows, paid extended support where it applies, and the release cadence of monthly patches, quarterly minors and two-year majors. We note the PHP versions each release supports, because a PHP change can force a platform change as well as a Mautic change. The output is a calendar showing when the current release stops receiving security fixes and which targets remain supported through the model period. It is done when the client has checked each date against the official release page.
Build the three-year cost model
We combine the sizing, the calendar and the implementation scope into a three-year model that separates one-time work from recurring costs. One-time items include implementation, migration, any upgrade project and integration build. Recurring items include hosting, the sending service, extended support where needed, patching, and the staff time to run campaigns. Each line shows its driver and the assumption behind it. The output is a model the client can change line by line. It is complete when every cost line names who is paid for it and what drives it.
Record decisions in a log for the client
We write a decision log that lists each choice the model depends on, such as the target release, the hosting pattern, the sending service, who runs campaigns and when the next upgrade is planned. For each entry we record the options considered, the assumption used, the person who approved it and the date it should be revisited. The output is a decision log the client keeps after the review ends. The step is done when the client has accepted the log in writing.

Which Mautic versions carry security support and when it ends

Mautic ships monthly patch releases, minor releases every three months and a major release every two years. Each card below gives a version's support end date and what that date means for upgrade or extended support spending. Check these dates against the Mautic releases page and the project before any version is written into a quote.

Mautic 7.2 (Absolunto)

Mautic 7.2 (Absolunto) has active and security support until 30 September 2026. It supports PHP 8.2 to 8.5, so confirm that your server's PHP version falls in that range before you plan an install or upgrade. After that date, the install needs a planned move to a later release, and that move should be in the budget before the date arrives. Confirm the end date on the Mautic releases page before you sign a scope.

Mautic 7.3 long-term support

Mautic 7.3 is planned as the long-term support release, with security support through 31 December 2027. A long-term release is the version to target if you want fewer forced moves over the coming years. Because 7.3 is planned and not yet shipped, confirm its release status and final support date with the Mautic project before you lock a platform version into a quote.

Mautic 6.0 (Tabit)

Mautic 6.0 (Tabit) received security support until 30 September 2026, the same end date as 7.2. An install still on 6.0 faces a decision: move to a 7.x release inside this window or plan a later jump. Check whether your custom plugins, themes and integrations have been tested on the newer major version, because that testing is often the largest share of the upgrade work.

Mautic 5.2 (Capella)

Mautic 5.2 (Capella) has security support until 30 June 2026, the earliest end date among the versions listed here. An install on 5.2 has the nearest deadline, so map the full upgrade path, including any intermediate major versions, before anything else. Ask for the upgrade plan to name each step, the test evidence for each step and the cutover window.

Mautic 4.4 paid extended support

Mautic 4.4 has paid Extended Long Term Support through 31 December 2026. Paid extended support buys time for installs that cannot move yet, but it is a recurring cost with its own end date. Confirm the price, the scope of covered fixes and the renewal terms directly with the Mautic project, and do not assume they match the terms of any other version.

Cost when a version expires

Routine upgrades are predictable while a version is in its support window. Once that window closes, the spending shifts to either a forced upgrade with testing and cutover work, or a paid extended support decision that recurs until it ends. Ask every quote to state which version it targets, when that version's support ends and what happens to the budget when it does.

Which recurring costs follow a Mautic go-live

This table lists the cost lines that continue after a Mautic go-live, who usually pays for each one, what drives it, and what to ask for in a quote. Lines marked one-time arrive once during the project, while recurring lines continue for as long as the platform runs. No figures are given here, so use the questions in the last column to request costs for your own environment.

Cost line	Who usually pays	What drives it and what to ask for	One-time or recurring
Server (VPS or dedicated)	Client, through its cloud or hosting account	Mautic's requirements page says it should not run on shared hosting. Ask the partner for the sizing assumptions behind the chosen VPS or dedicated server and the contact volume they assume.	Recurring
Database (MySQL or MariaDB)	Client, as part of server or managed database spend	Requirements list MySQL 5.7 or higher with InnoDB, or MariaDB 10.2 or higher. Ask whether the quote includes a managed database, its backup retention and who applies patches.	Recurring
Backups and restore testing	Client for storage, partner or internal team for test restores	Backups must cover the database and the file store. Ask how often restores are tested and who owns that test.	Recurring
Email sending service and bounce and complaint handling	Client, to the email provider	Sending volume, provider pricing and bounce and complaint processing drive this line. Ask the provider for its current rates and confirm how Mautic bounce and complaint feedback is wired in.	Recurring
Cron and queue worker capacity	Client for compute, partner for configuration	Mautic relies on cron jobs for segments, campaigns and triggers, plus a broadcasts command and a messenger consumer for queued email. Ask how many workers run and how they are monitored.	Recurring
Monitoring and alerting	Client, through its monitoring tools	Alerts for failed cron runs, queue backlogs, disk use and mail errors. Ask which signals are watched and who responds.	Recurring
Major release upgrade projects	Client, paying the internal team or a partner for a fixed-scope project	Major releases arrive about every two years, and each may bring a PHP change and plugin checks. Ask for the upgrade scope, test environment and rollback plan.	Recurring, in project form
PHP version changes	Client, with the partner or internal team doing the work	Mautic 7.0 requires PHP 8.2 to 8.5. Ask the partner how it will handle PHP patches and the timing of PHP end-of-life changes on your server.	Recurring
Plugin and custom code compatibility checks	Client, with the partner or plugin author	Each upgrade needs checks on custom plugins, themes and integrations such as the HubSpot or Salesforce plugins. Ask for the inventory of extensions and who tests them.	Recurring, with each upgrade
Paid extended support for an old version	Client, to the Mautic project or a support provider	Mautic 4.4 has paid Extended Long Term Support through 31 December 2026 (Mautic releases page). Staying on an older release can add this line. Ask what the support covers and its end date.	Recurring, if an old version is kept
Ongoing support retainer	Client, to the partner	Covers monitoring response, patch application and advice between upgrades. Ask for response expectations in writing and what is excluded.	Recurring
Internal staff time for campaigns	Client, through internal salaries	Segment design, campaign changes, content and reporting consume ongoing time. Ask the partner to estimate the operating time its handover assumes.	Recurring
Initial implementation and setup	Client, to the partner or internal team	Server build, installation, contact model and integrations are one-time work. Ask for a fixed-scope quote with deliverables listed.	One-time

Which Mautic cost lines your team can carry and which to outsource

Most marketing teams that run Mautic can keep the marketing work in-house, and they should. Campaign design, segment logic, email and landing page content, reporting, and the daily operation of campaigns depend on knowing the business, the offer and the audience. Nobody outside the company can decide which contacts should enter a nurture track or what a lead score should mean for sales. The skills involved are marketing strategy, copywriting, data literacy and familiarity with the Mautic interface, and those can be built by the people who already own the pipeline. Plan for this work to recur every month, because it is the part of the cost that keeps growing as campaigns multiply.

The technical lines are where the outsourcing decision usually gets made. Initial sizing of servers, database and mail volume draws on Linux operations and database administration. The cost model, which ties hosting, sending service and labor together, needs someone who can translate infrastructure into a monthly figure the finance team will accept. Neither skill set is common inside a marketing department, and the first sizing decision often shapes the hosting bill for years. Ask any partner to show the assumptions behind the sizing, including contact volume, send frequency and retention of tracking data, so you can challenge them.

Upgrades and integrations need a different profile. Mautic is written in PHP on the Symfony framework, so a PHP or major-version upgrade project requires PHP and Symfony knowledge, along with the ability to test plugins and custom code against the new version. The Mautic requirements page lists the PHP versions and database versions each release supports, and the release page sets out support end dates for each line, so confirm which version your upgrade targets before scoping the work. CRM and SSO integration work calls for CRM administration, field mapping and identity provider configuration. Security hardening requires server and PHP configuration skills plus knowledge of email deliverability, because sending configuration, sender authentication and bounce handling affect both security and inbox placement.

The practical test is whether your team has these skills available without displacing its existing work. An in-house team usually absorbs an upgrade or integration into current capacity, so the cost appears as delayed campaigns and overtime rather than as a line item. A partner gives a fixed-scope quote in writing before work starts, which makes the cost of each technical item visible and comparable. Ask for the quote to separate one-time project work from recurring operations, and to name who performs each task. Keep campaign design and reporting with your marketing team in either case, so that the outsourced scope stays limited to the platform.

Where Mautic cost estimates usually go wrong

Each card describes a common budgeting error for Mautic. Most come from treating the free software as the whole cost, so the model misses hosting, runtime changes, upgrades and staff time. Add the line item named on each card before you compare internal estimates or partner quotes.

Budgeting for software only

The Mautic code is licensed under GPL-3.0 and has no license fee, so the first estimate often covers only staff time and a server. The recurring costs that follow are hosting, a transactional email sending service, backups, monitoring and storage that grows with contacts and tracking history. Give each one its own line with a named owner, and ask any partner quote to separate one-time setup from monthly running costs.

One server for everything

Mautic runs segment updates, campaign updates, campaign triggers and broadcasts through cron jobs, which the documentation says should be staggered. Queued email also needs a messenger consumer. Running web requests, cron and queue work on one machine makes performance hard to predict. Model separate web, cron and queue components, and ask for the sizing basis in writing before you accept a hosting figure.

Deferring major upgrades

Mautic ships monthly patch releases, minor releases every three months and major releases every two years. Security support ends on fixed dates: Mautic 5.2 until 30 June 2026, Mautic 6.0 until 30 September 2026, and Mautic 4.4 has paid Extended Long Term Support through 31 December 2026. Model one upgrade project per major version with its support end date, and check the Mautic releases page before you set the year's budget.

Skipping plugin compatibility checks

Mautic 7.0 requires PHP 8.2, 8.3, 8.4 or 8.5, so a server PHP upgrade can break plugins and custom themes built for an older runtime. Estimates often leave out the time to test each installed plugin against the target PHP version. Model a staging copy, a compatibility review of every plugin and template, and a fix allowance. Confirm which PHP versions each plugin's author supports.

Underestimating campaign staff time

The software has no license fee, but building segments, campaigns, emails, landing pages and consent logic takes marketing and operations time every month. Estimates usually count the launch and miss the ongoing work: data hygiene, reviewing bounces, updating campaign logic and answering consent questions. Model hours by role for launch and for steady state, and ask any partner to list training as a separate line.

Assuming shared hosting works

The Mautic project states that Mautic should not be installed on shared hosting and recommends a VPS or dedicated server. A low-cost shared plan can look like the smallest line in the model, then force a migration once contact volume or cron reliability becomes a problem. Model a VPS or dedicated server as the baseline, and confirm the PHP, database and web server requirements before you choose a plan.

How the cost of ownership changes by starting point

A new self-hosted install has the simplest cost structure, but the free software is only one line in the budget. The server is the first recurring cost. The project states that Mautic should not run on shared hosting and recommends a VPS or dedicated server, so the organization either operates that server or pays a provider to operate it. Planning also covers the install path, since Mautic can be installed with the web or command-line installer or with Composer using the recommended project template, which has been the recommended approach since version 4.0.

Recurring: the server or VPS, the database, the email sending service, backups, and staff time for patching. Monthly patch releases and quarterly minor releases create a steady operating load.
One-time: installation, cron and queue configuration, SAML single sign-on if your identity provider requires it, CRM integration, and the contact model design.
Grows with use: contact count, email volume and the number of campaigns push up server and email sending costs over time.
Shrinks: little at small scale, but a single node with no custom code keeps the initial build short.

Confirm with the project which release line you will start on. Mautic 7.2 receives 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.

Questions buyers ask about Mautic cost and effort

Does Mautic have a licence fee for the software itself?

No. Mautic has no paid edition of the software, and its GitHub repository is licensed under GPL-3.0, so the core product carries no per-user or per-contact licence. Mautic.org offers the free self-hosted download and also promotes managed Mautic and hosting services from other providers. Those are separate purchases. The costs that remain are the ones you pay to run it: a VPS or dedicated server, an email sending service, implementation, upgrades, and the people who build and run campaigns. If a vendor quotes a "Mautic license," ask exactly what they are selling, because the software itself is free to download.

What drives the total cost of owning Mautic?

The main drivers are infrastructure, email delivery, contact volume and send volume, the number of integrations, and the labor to build and operate the system. Infrastructure must support web traffic, the database, and cron and queue processing, and the project recommends a VPS or dedicated server. Email delivery is usually a separate sending service whose cost grows with volume. Implementation covers the contact model, custom fields, segments, campaigns and CRM integration. Recurring costs include upgrades, monitoring, backups, plugin compatibility checks and staff time. Ask for a quote that separates one-time build work from recurring operations so you can compare each line with your current tool.

How often do we need to upgrade Mautic to stay supported?

Mautic publishes monthly patch releases, minor releases about every three months and major releases every two years, so staying supported means applying updates on a regular schedule. Each supported version carries end dates. Mautic 7.2 receives 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, according to the Mautic releases page. Older lines end sooner, and Mautic 4.4 has paid Extended Long Term Support through 31 December 2026. Each major upgrade can require PHP changes, plugin checks and testing of campaigns and integrations. Confirm current dates on the releases page before you budget, because they change as releases ship.

Can an internal team run Mautic without outside help?

Yes, teams with Linux, PHP and database skills can run it, but the work is broader than the marketing interface. Operators maintain the web server, MySQL or MariaDB, the PHP version each release requires, and cron jobs for segment updates, campaign updates, campaign triggers and broadcasts. A messenger consumer is also needed when email is queued. Someone must own upgrades, backups, monitoring, access control, SAML single sign-on if you use it, and CRM connectors. Marketing operations usually owns campaign logic, but it still depends on engineering for deployment and troubleshooting. Confirm you have a named owner for each area before you decide, because the answer is mostly a staffing question.

What does a Mautic engagement need from our team?

Expect to supply access, decisions and people. Access means the cloud or data center account where Mautic will run, control of the DNS and mail domains used for sending, and credentials for any CRM or identity provider. Decisions cover the contact model, consent fields, segment definitions, sending policy and who approves campaigns. People include a business owner who signs off scope, a marketing operations lead who sets campaign requirements, and an engineer for DNS, certificates and integration testing. Delays usually come from slow approvals and unclear data ownership. Agree these inputs in the written scope so the timeline reflects how quickly your team can respond.

How long does a Mautic cost review take?

The length of a cost review depends mainly on install size and the number of environments. A single production instance with a modest contact base and no custom code can be reviewed much faster than a setup with staging, development, separate sending domains, several integrations, or a migration from another tool. Reviewers need the current version, the hosting layout, expected contact and send volumes, the integrations in use, and any custom plugins or themes. DeployOpen sets the timing in the written scope, so request the review timeline in writing before work starts. Be cautious of any estimate given before someone has inspected your environment, because cost depends on what is already running.

When is paid extended support for Mautic worth considering?

Paid extended support is worth considering when a Mautic version you depend on is nearing the end of free security coverage and an upgrade cannot happen on your schedule. The project offers paid Extended Long Term Support for some older lines, such as Mautic 4.4 through 31 December 2026, so check that status before you plan. It makes sense if internal or regulatory patching rules require security fixes after standard support ends, if custom plugins block an upgrade, or if a migration project needs more time. It works best as a bridge while you plan a move to a supported release, rather than as a permanent setup.

How DeployOpen scopes, delivers and supports Mautic cost work

DeployOpen builds the cost model for a self-hosted Mautic installation from a written scope, covering infrastructure, email sending, implementation effort and the people who will run campaigns. Engagements are fixed-scope, so the costs that recur after launch are listed separately from the one-time work.

How we scope

Written scope lists the servers, database, email sending service and cron or queue workers the Mautic installation will need.
Scope names the Mautic release line to be deployed and the PHP and database versions that release requires.
Scope records which upgrade windows, extended support decisions and plugin dependencies affect the three-year running cost.

How we build

Build sizes a VPS or dedicated server instead of shared hosting, following the Mautic requirements for web server and database.
Cron jobs for segments, campaigns and broadcasts are configured and staggered, with the messenger consumer set up for queued email.
Installation runs from the Composer project template or the production package, with the chosen method documented for future upgrades.

How we hand over

Handover documents the hosting, email and cron inventory so the client can compare each recurring cost line against its quote.
Runbooks describe the monthly patch, quarterly minor and two-yearly major release steps the client's team must budget for.
Training covers the staff who run campaigns and the administrators who maintain the server, so recurring effort stays visible.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, so recurring effort can be priced separately.
Upgrade planning tracks each Mautic release against its security support end date before the old version leaves support.
Ask any provider to confirm in writing which costs are included in the retainer and which are billed on top.