What Mautic customization involves
Mautic customization means changing or extending the platform without forking its core. The work usually takes one or more of these forms: custom plugins, themes, custom fields and objects, landing page and email templates, webhooks, and API integrations. Mautic is written in PHP on Symfony, so plugins and themes follow the framework's structure and the project's own extension points. Custom code that touches the contact model, forms, tracking or the API is the part most likely to break during an upgrade, so it should be listed as a managed asset from the start, with its owner, its dependencies and its tests recorded.
Most customization starts with a specific trigger. The common ones are a data model the standard contact fields cannot hold, such as account hierarchies, product holdings or regional consent categories; a required integration with an internal system that the existing CRM plugins do not cover; or branded templates that must still pass consent capture and tracking requirements. Each trigger should be written as a requirement before any build starts. Ask which fields must be filterable in segments, which events must reach other systems, and who signs off on template changes that affect consent language.
In-house or partner. A Mautic-skilled developer can usually handle small template and custom field changes, provided they test them on a staging copy of the database. Plugins, custom objects and integrations that must survive major version changes benefit from an outside review of their design and test coverage before they go live. The review question is simple: will this code still work after the next major release, and who will fix it if it does not? Your quote should separate the one-time build from the recurring work of re-testing custom code at each release.
Licensing. Mautic's GitHub repository is licensed under GPL-3.0. Custom plugins and themes that are distributed outside your organization may fall under the terms of that license, and this affects how code is shared with vendors and reused elsewhere. Confirm with counsel which ownership, license and source-availability terms apply to code written for your deployment before the statement of work is signed.
What the work includes
Each package below ends in a deliverable you own and can review. Scope them together so custom code, data model changes and integrations are planned against the Mautic release you intend to run.
Custom plugins
Mautic plugins add bundles, integrations, custom campaign actions and decision types, and form or contact behaviors that core does not provide. We build them on Mautic's plugin structure and Symfony services, with the logic kept inside the plugin rather than patched into core. You receive the source code in your repository, a packaged plugin, and a test record showing what was exercised.
Themes and branded templates
Themes control the look of landing pages, forms and emails sent from Mautic. The work covers template files, assets, and the email and landing page templates your teams will reuse. Check that brand assets, tracking and unsubscribe elements survive template edits, and confirm which template files are overridden so a later upgrade does not silently change them.
Custom fields and data model extensions
Custom fields on contacts and companies, and related data model changes, shape segmentation and consent records long after launch. We design field types, groups and naming with your team, and confirm how each field is populated, imported and reported. Ask for the data dictionary as a deliverable so later changes are traceable.
Webhooks and API integrations
Webhooks and API integrations move contact and campaign events between Mautic and internal systems such as CRMs, data warehouses or consent stores. The deliverable is the integration code, configuration, and integration documentation covering payloads, authentication, retries and error handling. Confirm the expected event volume and who owns each receiving system before build starts.
Upgrade-safe code isolation
Custom code is kept out of core files, and every extension point used is documented so maintainers know what a Mautic upgrade can affect. We record which events, services and hooks the code depends on, and keep overrides to a minimum. Ask for this register as a deliverable, since it is the main input to every future upgrade estimate.
Compatibility check against your target release
Before go-live, each custom plugin, theme and integration is checked against the Mautic release you plan to run, along with its PHP version and the database and web server requirements that release states. Confirm the target version and its support window with the Mautic releases page first. The output is a compatibility report and a test record you can rerun when the release changes.
What drives cost and duration
This table lists the scope choices that change the effort of a Mautic customization project, why each one matters and how to keep it contained before the written scope is signed.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Custom objects and fields | Each custom object or field adds schema changes, mapping, forms, segment filters and test cases, and each one must survive future upgrades. | Confirm which fields segments, campaigns and CRM syncs truly need, and reuse existing contact or company fields where they fit. |
| Template types and brand variants | Landing pages, email templates and themes multiply with each brand, language or region, and each variant needs rendering and consent checks. | Limit the first release to one base theme with brand settings, and add variants later as separate change requests. |
| Integrations and their direction | Inbound, outbound and two-way syncs with external systems each need field mapping, error handling, retries and duplicate-contact rules. | Start with one direction per system, document which system owns each field, and phase two-way sync. |
| Core changes versus extension points | Code that edits core files is harder to upgrade and test than plugins or themes built on documented extension points. | Build on plugins, event listeners and theme overrides, and record every core change so it can be reviewed at each upgrade. |
| Number of target Mautic versions | Supporting more than one Mautic release means separate test matrices, and the current release line changes on a published cadence. | Target one release line for go-live, then confirm support dates on the Mautic releases page before choosing it. |
| Environments | Development, staging and production each need a working install, data handling rules and deployment steps, and staging must resemble production to be useful. | Agree early which environments are required, use anonymized data outside production, and script deployments. |
| Testing depth for consent and tracking | Consent capture, preference centers, tracking scripts and data subject requests change behavior that must be verified, not assumed. | Write a short list of consent and tracking test cases tied to the scope, and test the highest-risk paths first. |
| PHP and Mautic version baseline | Mautic's PHP and database requirements set the baseline that custom code is built and tested against, and a version mismatch forces rework. | Confirm the supported PHP range and MySQL or MariaDB version for the chosen Mautic release before any code is written. |
| Scope changes after sign-off | Requests that alter the signed scope are priced as change requests, so late additions extend both timeline and cost. | Record assumptions in the written scope, and route each new request through a change request with its own estimate. |
Project phases and outputs
The sequence moves a customization from an agreed data model to a documented, tested release that your team can upgrade without rebuilding it.
Discover the data model and extension points
We review your contact model, custom fields, segments, campaigns, existing integrations and the Mautic version you will run, then identify where plugins, templates or API calls are the right extension point. You receive a discovery note listing each requested change, the Mautic hook or API it would use, and the open questions your team must answer before design starts.
Design the plugin and template structure
We design the plugin layout, configuration options, custom field and object definitions, template structure and any webhook or API flows, and agree how each piece will be named, namespaced and kept separate from core files. The output is a design note and a test plan that your team signs off before any code is written.
Build in a versioned repository
We implement the approved design in a version-controlled repository with commit history, code review and a clear split between custom code and the Mautic core, so every change can be traced and reverted. Your team receives repository access, a branch and merge convention, and a build notes file that explains how to run the code locally.
Test on a staging install that matches production
We deploy the build to a staging environment running the same Mautic version, PHP version and database engine and version as production, then run the test plan covering functional behavior, cron-driven processes, email and form paths, and consent handling. You receive a test report listing each case, its result, and any defects fixed before release.
Review upgrade readiness
Before release, we check each custom component against the Mautic release you intend to stay on, including the PHP and database requirements of that release and any core interfaces the code depends on. The output is a compatibility matrix that marks each component as compatible, needs changes, or needs a check against a later release, so the upgrade path is known before go-live.
Deploy and hand over with documentation
We deploy the approved release to production under a documented change procedure, verify the functions covered by the test plan, and hand over to your operations and marketing teams. You receive a deployment runbook, a rollback procedure, configuration and credential inventory, and a short walkthrough session recorded in the handover notes.
What goes wrong and how to prevent it
Most Mautic customization problems come from a small set of habits: editing code the upgrade path will overwrite, building against internals that change, and skipping a realistic test before production. The cards below name each failure and the step that prevents it.
Edits made directly in core files
Changes written into Mautic's core source are overwritten or conflict when the installation is upgraded to a new release. Keep custom behavior in a plugin or theme that sits beside core, and record any unavoidable core patch in a list that the upgrade test checks first. Ask the implementation partner to show where each customization lives.
Plugins built on unstable internals
A plugin that calls internal services or classes rather than documented extension points can break when a major release changes those classes. Before building, list every Mautic class and service the plugin depends on, and confirm each one against the documentation for every release in your upgrade window. Treat that list as the plugin's compatibility contract.
Templates that break tracking or consent
Custom landing page or email templates that omit the tracking script, remove the unsubscribe or preference link, or alter the consent checkbox can stop tracking or create consent records that cannot be defended. Test each template with a sample contact on the staging copy, confirm the tracking event appears in the contact timeline, and verify the preference link works before publishing.
Webhooks without retry or idempotency
An external system that receives a Mautic webhook and does not handle timeouts or repeated deliveries can create duplicate records when a request is retried. Give every receiving endpoint an idempotency key check, return success only after the record is stored, and test a forced timeout on staging to confirm that a retry does not create a second contact or deal.
Custom fields without naming or ownership
Custom fields added by different teams with inconsistent names, types and no owner make segments, reports and CRM mappings unreliable over time. Agree on a naming prefix, a field type rule and a named owner for each field before the first one is created, and keep a register that the project team reviews at every change.
Production changes without a staging test
Customizations tested only on a developer laptop often fail with the production database, PHP version, cron schedule or email volume. Build a staging copy with the same Mautic release, PHP version and database engine as production, load a sample of real-shaped contacts, and run segment, campaign and email tests there before every release. Confirm PHP and database versions per release, since Mautic's requirements differ between major versions.
What teams keep in-house and what they outsource
This table compares which Mautic customization work teams usually keep internally and which they usually hand to a partner, with the skills each area needs, so you can match the split to your PHP capacity and the custom components you will own after handover.
| Work area | Usually kept in-house | Usually outsourced | Skills required |
|---|---|---|---|
| Campaign and template content | Campaign logic, email copy, segment definitions and day-to-day edits by marketing operations | Initial builds of complex landing page and email templates tied to custom fields | HTML and email client rendering, Mautic campaign builder knowledge |
| Data model ownership | Naming rules, field purposes and who approves new custom fields and objects | Designing the custom field and object schema and its migration paths | Mautic data model knowledge, PHP and Symfony familiarity for schema changes |
| Plugin code | Ownership of the repository, review of changes and running the plugin after handover | Building custom plugins, event listeners and forms to a documented design | PHP and Symfony familiarity, Mautic plugin architecture, Composer packaging |
| Theme and frontend work | Brand assets, copy changes and small template tweaks | Custom themes, layout changes and frontend scripts for tracked pages | HTML, CSS, JavaScript and Mautic theme structure |
| API integration | Business rules for what data moves, and monitoring of sync results | Building webhooks and API clients for CRM or other systems | API and authentication knowledge, error handling and rate limit awareness |
| Testing and upgrade checks | Acceptance testing of campaigns and sign-off on each release | Regression test suites, compatibility checks of custom code against new Mautic and PHP versions | Automated testing in PHP, Linux and web server administration, release note review |
| Ongoing maintenance | Routine content work, cron health checks and reviewing reported errors | Patching custom code after Mautic major releases and fixing defects in custom components | Linux and web server administration, PHP and Symfony familiarity, Mautic upgrade experience |
How the work changes by starting point
Customization is planned before the first install, so custom fields, templates, plugins and integration points are scoped together with the base build. Testing runs against custom code from the first build, and handover includes a record of every custom component.
- Scope: Custom fields, objects, templates and plugins are listed in the design alongside the contact model, segments and campaigns.
- Testing: Automated and manual tests run in a staging install built from the same package and version as production.
- Handover: Your team receives the plugin source, configuration notes and a record confirming that no core files were modified.
- Confirm first: The target version and its PHP and database requirements, and who owns the Git repository for custom code.
Custom code added over time usually arrives undocumented, so the work starts with an inventory of what exists. Scope typically includes a code review and a cleanup pass before any new features are added.
- Scope: An inventory of plugins, themes, custom fields, templates and direct edits to core files, with a keep, fix or remove decision for each item.
- Testing: Regression checks on forms, tracking, segments and campaigns before and after each change, run against a copy of production data where your data policy allows.
- Handover: A documented list of what remains, what was removed and what still needs a planned fix.
- Confirm first: Whether core files were edited, who holds the code and deployment access, and whether a recent backup can be restored into staging.
Moving to a new major version turns much of the work into compatibility review. Mautic's stated cadence includes major releases every two years, and each major version sets its own PHP and database requirements.
- Scope: A compatibility review of each plugin and theme against the target version, plus rewrites of custom code that depends on changed interfaces.
- Testing: Upgrade rehearsals in staging, with the full campaign and CRM integration path exercised before cutover.
- Handover: A compatibility matrix, the rehearsed upgrade runbook and documented rollback steps.
- Confirm first: The target version and PHP version, whether each plugin has a release for that version, and the support window of your current version on the Mautic releases page.
The integration connects Mautic to a system your network does not expose, so the design focuses on the network path. Scope covers the firewall rules, the direction of each connection and where the integration code runs.
- Scope: A connection map showing which side initiates each call, plus outbound rules for any external services Mautic must reach.
- Testing: Tests run from inside the network with production-like credentials, including failure handling when the internal endpoint is unreachable.
- Handover: A network diagram, a record of firewall changes and the credential rotation procedure.
- Confirm first: Whether the internal system can send webhooks or must be polled, who approves firewall changes and how long those approvals take, and whether the Mautic host sits in a network segment that can reach the internal endpoint.
Installing and updating Mautic depends on packages that a restricted network may not reach, so staging moves to before the build starts. Mautic can be installed with Composer, and from version 5.0 onward it requires npm.
- Scope: Stage the Mautic package, Composer dependencies, npm packages and plugin dependencies in an internal repository before development begins.
- Testing: Rebuild from the staged artifacts on a clean host to confirm that the build and install complete without internet access.
- Handover: A bill of materials listing every package and version, a procedure for transferring updated artifacts and an offline runbook.
- Confirm first: Which artifact repositories your network can host, how approved packages move across the boundary, and whether email delivery and tracking endpoints are internal to your network.
What the client needs to provide
Before a customization quote can be fixed in scope, the client should have a running or planned Mautic environment with the PHP and database versions it intends to use. Mautic 7.0 requires PHP 8.2, 8.3, 8.4 or 8.5 and MySQL 5.7 or higher with InnoDB, or MariaDB 10.2 or higher, so the version pair decides which platform APIs and libraries custom code can rely on and how much compatibility testing the build needs. Staging access on a production-like server is also required, because plugin hooks, cron-driven campaign logic and webhooks cannot be verified on a laptop with confidence.
Source control where custom code will live, and named owners for the data model and each integration, decide how much work is needed before development starts. Custom fields, custom objects and plugin entities change the contact schema, so one person must approve field names, types and retention. Each integration, such as a CRM connector or webhook receiver, needs an owner who can confirm the expected payloads and error handling. Without these owners, change requests stall and the testing effort grows because acceptance criteria are not agreed.
Sample contact and template data should be provided with consent rules documented. Landing page and email templates are tested against realistic records, and consent status, channel preferences and opt-in sources affect how segments and campaigns behave. The client should also provide API credentials for connected systems, created under least privilege, so integration tests use the access the production integration will have. Each credential that is broader than needed adds review work and a security finding to the quote.
Frequently asked questions
How much does Mautic customization cost and what drives the price?
Cost follows from a written scope, since DeployOpen does not publish a price list. The main drivers are the number of plugins, custom fields and objects, template work, each integration (webhooks, API calls or CRM connectors), and the testing needed on a staging copy before release. Hosting, upgrades and any support retainer recur after launch, while design and build work is one-time. Ask each quote to itemize work by component, state what is tested and where, list assumptions about your environment, and name what is excluded.
How long does a Mautic customization project take to deliver?
Duration depends mostly on how many integrations and how much testing the scope includes. A template change moves quickly, while a plugin that syncs contacts to a CRM needs field mapping, error handling, duplicate checks and test runs on realistic data. Delays often come from the client side, so confirm staging access, sample data, API credentials and named reviewers before work starts. DeployOpen agrees timelines in the written scope, so ask for milestones tied to each deliverable and test gate.
Can our internal developers customize Mautic without an outside partner?
Often yes, if the team knows PHP and the Symfony framework, since Mautic is written in PHP on that framework. The harder part is ongoing ownership. Someone must read release notes, run tests after each monthly patch, minor and major release, and keep custom code on a PHP version the release supports. Mautic 7.0 requires PHP 8.2, 8.3, 8.4 or 8.5. Check that your team has capacity for that cycle as well as for the first build.
Will custom Mautic plugins break when a new major version releases?
They can, so design plugins to limit that risk. Major releases arrive every two years, and changes to the framework or internal APIs can alter the code your plugin calls. Keep custom code on documented extension points, avoid editing core files, maintain automated tests, and run them against the upcoming release in a staging copy. Mautic 7.3 is planned as the long-term support release with security support through 31 December 2027, which should inform when you schedule your upgrade.
Does Mautic's GPL-3.0 license affect ownership of our custom code?
Refer this question to your legal counsel. Mautic's GitHub repository is licensed under GPL-3.0, and whether your custom code counts as a derivative work, and what obligations apply if you distribute it, depends on how the code connects to Mautic and how you deliver it. Counsel should review the plugin architecture, whether code leaves your organization, and the terms in any contract with a partner who writes it. DeployOpen can document the technical structure of the code, but it does not provide legal advice.
Can an implementation partner maintain our custom Mautic code after launch?
Yes, through a retainer, provided the terms are written down. DeployOpen offers ongoing support, upgrades and continuous testing as retainers. Before launch, ask for the code in a repository you control, documentation for each plugin and integration, an automated test suite, a runbook for cron and queue jobs, and a written list of what the retainer covers, including testing against new monthly, minor and major releases and who approves each change.
How DeployOpen works on Mautic customization
DeployOpen scopes, builds, tests and documents Mautic customizations inside infrastructure you control, so custom plugins, themes, fields and integrations stay your code on your servers. Engagements are fixed-scope, with the written scope fixing what is delivered before work starts.
How we scope
- We list each custom plugin, theme, field, object, template and API integration the written scope covers.
- We confirm which Mautic major version and PHP version the customizations must run on before design starts.
- We map every customization to the upgrade check it needs, so the scope names what is tested at each Mautic release.
How we build
- We build plugins and themes against Mautic's extension structure and keep custom code separate from core files.
- We design custom fields and objects around the contact model and document how each one is written and read.
- We build webhook and API integrations with credentials held outside the codebase and test them against a staging install.
How we hand over
- We deliver source code in your repository with setup notes, configuration steps and the test cases used during the build.
- We document which customizations depend on which Mautic version, so your team knows what to recheck before an upgrade.
- We walk your administrators and developers through the custom components and the upgrade checklist before close.
How we support
- We can run upgrade-safe checks on custom code when your team moves to a new Mautic patch, minor or major release.
- Ongoing support, upgrades and testing are available as a retainer, with the coverage agreed in writing.
- Changes after handover are quoted from a written scope so the cost and deliverables stay visible to your team.
