Mautic upgrades and support services

How Mautic upgrades and support keep an install on a supported release

Upgrades and support keep a Mautic install on a supported release, so it continues to receive security fixes and runs on the PHP and database versions that release requires. This matters for three kinds of reader: a team running an older Mautic release, a team planning a PHP or database change on the host, and a team that needs someone to own patching after launch. Mautic is free software licensed under GPL-3.0, so the recurring cost of staying supported is labor and hosting, and no license renewal is involved. In short, keep the work in-house if you have people who can test a staging copy, check plugins and apply releases on a schedule. Bring in a partner when that capacity does not exist, or when a one-time upgrade needs a fixed scope.

Four events usually start upgrade work. The first is the end of a release's support window. The Mautic releases page lists Mautic 5.2 with security support until 30 June 2026, Mautic 6.0 and Mautic 7.2 until 30 September 2026, and Mautic 4.4 on 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 on the releases page before you set a plan, since they can change. The second trigger is a host upgrade. 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. The third is a failed patch that leaves the install in a partial state. The fourth is a plugin you need that only runs on a newer release.

Before any upgrade, check three things in a staging copy: the target release's PHP and database requirements against the host, every custom plugin and theme against the target release, and the cron jobs and messenger consumer. Mautic relies on cron jobs for segment updates, campaign updates and campaign triggers, which the documentation says should be staggered, plus a broadcasts command for segment emails and a messenger consumer when emails are queued. A host change can stop one of these without an obvious error, and contacts then stop moving through campaigns. Also run a restore from backup in staging, because a backup that has never been restored is untested. Monthly patch releases are usually smaller changes than minor or major releases, so decide in advance which kinds of release you will apply quickly and which need a full test cycle.

Decide the ownership model in writing. An in-house team needs a named owner for patching, a staging environment that mirrors production, a rollback plan and time set aside for plugin checks. A partner support arrangement should state what is included: which patch releases are applied and how quickly, whether major upgrades are in scope or quoted separately, who tests custom code, and how a failed upgrade is rolled back. Ask for these items in the quote rather than assuming them. DeployOpen offers ongoing support, upgrades and continuous testing as retainers, and most engagements are fixed-scope, with scope and deliverables agreed in writing before work starts. Ongoing costs such as paid extended support for old releases are covered on the cost of ownership page, so use this section to confirm the scope that keeps the install current.

What a Mautic upgrade and support engagement includes

Mautic moves on a monthly patch, quarterly minor and two-year major cadence, so an upgrade touches PHP, the database, cron, the messenger consumer and every plugin at once. The work packages below separate assessment, staging proof, production cutover and ongoing patching so you can contract the parts you need and see what each one hands back.

Upgrade assessment

We review your current Mautic version, PHP and database versions, server layout, installed plugins and custom code against the target release and its PHP requirements. The output is an upgrade report listing blocking issues, plugin compatibility status, required configuration changes and an open question list for your team. Scope and deliverables are agreed in writing before this work starts.

Staging upgrade with verification

We rebuild a copy of production in a separate environment and run the upgrade there first. Verification covers the cron jobs for segments, campaigns and broadcasts, plus the messenger consumer that handles queued email, with each job run and its output recorded. The deliverable is a tested runbook and a verification log. Scope and deliverables are agreed in writing before work starts.

Production cutover with rollback

We carry the tested runbook into production during an agreed change window. The plan includes a database backup taken immediately before the change, a defined rollback path back to the prior release and checks on tracking endpoints, form submissions and email sending after cutover. The deliverable is a cutover record showing each step, its result and the rollback point. Scope and deliverables are agreed in writing before work starts.

Ongoing patch handling

Monthly patch releases and quarterly minor releases need a repeatable path, not a one-time fix. We assess each release against your plugins and custom code, apply it in staging first and keep a patch log that records version, date, changes tested and any deferred items. Ask how the retainer covers patch windows and what happens when a plugin lags behind the core release. Scope and deliverables are agreed in writing before work starts.

Post-launch support

After cutover, issues tend to surface in campaign logic, email queues and CRM sync rather than in the web interface. Post-launch support covers triage of those faults, checks on cron timing and queue backlog, and fixes to configuration within the agreed scope. Confirm response expectations and the support hours in the written scope, because these are not fixed by the software itself. Deliverable: an incident log and a monthly service summary.

What drives Mautic upgrade effort and duration

This table lists the factors that change how much work a Mautic upgrade takes and how long it runs, with the reason each one adds effort and what a buyer can do to reduce it. Use it to see which parts of your own installation will push a quote up, and which ones you can simplify before the assessment starts. Most of the largest drivers are decisions you can make early, such as how many plugins you keep and which target release you choose.

Driver	Why it adds work	How to keep it down
Number of Mautic versions to cross	Each major release can change database schema, configuration and bundled dependencies, so a jump across several majors means several tested steps instead of one.	Pick the target release with the longest support window you need, and confirm which intermediate steps the vendor documents before scoping.
PHP version gap	Mautic 7.0 requires PHP 8.2, 8.3, 8.4 or 8.5, so an older runtime often means the server, PHP extensions and Composer packages all change at once.	Upgrade PHP on the current release first where possible, and confirm which PHP versions your target Mautic release supports before the assessment.
Database engine and version	The requirements call for MySQL 5.7 or higher with InnoDB, or MariaDB 10.2 or higher. Engines or versions below that line need a database upgrade or migration before Mautic can move.	Check engine and version against the requirements page early, and move to a supported engine ahead of the Mautic change window.
Plugins and custom themes	Each third-party plugin or theme must be checked against the target release, and many need code changes or replacement. Unused components still have to be tested or removed.	Remove plugins and themes that no campaign or page depends on, and ask the plugin owner for a compatibility statement for each one you keep.
SAML or CRM integrations	SAML login depends on the identity provider attributes and certificates, and CRM plugins depend on field mappings and API versions. Both must be re-tested after the upgrade.	Document current SAML attribute mappings and CRM field maps, and keep test accounts ready so these flows can be verified in staging.
Cron and queue setup	Segment updates, campaign triggers, broadcasts and the messenger consumer each need checking after the upgrade, and a stalled job can go unnoticed for days.	Write down every scheduled command and worker, confirm which ones run in production, and check their logs before and after the change.
Number of environments	Each environment, such as development, staging and production, needs its own build, configuration, data refresh and test pass, so the work repeats for each one.	Keep the environments aligned with infrastructure as code or a documented build, and limit the number of long-lived copies.
Contact volume and size of email history	Larger databases take longer to back up, migrate and verify, and large contact or send-history tables increase the risk of timeouts during schema changes.	Archive or purge stale contacts and old send records where your retention policy allows, after confirming the consent and audit requirements.
Custom code that must be re-tested	Custom plugins, templates, webhooks and API integrations are not covered by the vendor's testing, so every custom path needs a scripted or manual check.	Keep a list of custom code with owners and test cases, and avoid core file edits so changes stay in plugins that are easier to port.

Reading Mautic's release cadence and support windows

Mautic's published release cadence has three tiers: monthly patch releases, minor releases every three months and major releases every two years. Each tier carries a different upgrade obligation, and the support windows attached to each release determine how long a given install can stay where it is. Before you commit a Mautic environment to a version, read the release history against the dates below, then confirm the current status on the Mautic releases page, because support windows change and the dates in this section will pass. The supplied dates describe the position at the time of writing. Mautic 7.2, codenamed Absolunto, supports PHP 8.2 to 8.5 and receives active and security support until 30 September 2026. Mautic 7.3 is planned as the long-term support release, with security support through 31 December 2027. For a team starting a new install, that gap matters: a 7.2 deployment will need a planned move to 7.3 or a later supported line before its window closes, while a 7.3 deployment has a longer security runway. The older lines close on a different schedule. Mautic 6.0, codenamed Tabit, received security support until 30 September 2026, and Mautic 5.2, codenamed Capella, until 30 June 2026. Mautic 4.4 has paid Extended Long Term Support through 31 December 2026, which the project offers as a commercial option rather than free community support. If your organization runs any of these versions, the question is not whether to upgrade but when, and how much time the upgrade path needs. Practical checks follow from this. Record the exact installed version, the PHP version on each web and cron node, and the date each support window ends. Add a calendar item well ahead of each end date, and plan the upgrade as a project with a test environment, a copy of the production database and a review of every plugin and custom theme. Ask any implementation partner to show how they would track these windows and who signs off on the timing. Finally, treat the release page as the source of truth. Confirm the current active, security and extended support status for each version, the PHP range for the release you intend to run, and whether any planned long-term release has been confirmed or changed. Any change to these dates should trigger a review of your upgrade plan before the next scheduled maintenance window.

How an upgrade moves from assessment to cutover

The sequence turns an unknown installation into a tested, scheduled upgrade with a documented rollback path and an owner for every later patch. Each phase ends with a written output that the client approves before the next phase begins.

Inventory the current installation
DeployOpen records the running Mautic version, the PHP version, the database engine and version, and every installed plugin and theme. It also lists each cron job, queue consumer, and integration, including CRM connectors, SAML single sign-on, and the email sending service, with its schedule and owner. The output is a written inventory that the client signs off, with plugins flagged where a compatible release has not been confirmed. The step is complete when every scheduled job and queue consumer appears on the list.
Choose the target release and PHP version
Mautic publishes monthly patch releases, minor releases every three months, and major releases every two years, and each line has its own support end date. The team compares the current version with the supported lines, including the dates for Mautic 7.2, 7.3, 6.0, 5.2, and 4.4 as listed on the Mautic releases page, and checks the PHP range each release requires. The output is a decision record naming the target release, the PHP version, the database minimums, and the plugin versions that must change. The client should confirm the decision against its own support obligations before staging starts.
Build a staging environment with governed data
DeployOpen builds a staging environment that matches production in server layout, PHP configuration, database version, and cron and queue setup. A copy of production data is loaded only under the client's data rules, which usually means agreed masking of personal data and a documented decision on whether consent records are included. The output is a staging system the client can reach, plus a record of what data was copied, when, and under which approval. The step is complete when the staging stack reproduces the production inventory.
Test segments, campaigns, broadcasts, and CRM pushes
The team runs test cases for each business-critical path: segment rebuilds, campaign triggers, broadcast sends to segments, transactional and campaign emails, and contact pushes to the CRM through the HubSpot or Salesforce integration. Cron timing and the messenger consumer are exercised under realistic queue volumes so that staggered jobs do not collide. The output is a test log with expected and actual results, and every failure has a fix or an accepted risk recorded. The client should ask for the test cases to be approved before testing begins.
Schedule the production cutover with a rollback path
DeployOpen and the client agree a change window, a go or no-go checklist, and named decision makers for the cutover. A verified backup of the database and files is taken immediately before the change, and the rollback steps are rehearsed on staging so the team knows how to restore the prior version. The output is a written change plan containing the cutover steps, the rollback trigger conditions, and the post-cutover checks on sending, tracking, and integrations. The cutover is complete when those checks pass and the client confirms in writing.
Hand over the runbook and patch calendar
After cutover, DeployOpen delivers a runbook covering the installation layout, cron and queue operations, backup and restore, integration credentials ownership, and the escalation path. A patch calendar is built around the monthly patch releases, the quarterly minor releases, and the next major release decision, so the client can plan window time in advance. The output is a signed handover pack and a calendar with named owners for each recurring task. Ask the partner to state in the written scope whether monitoring, patch application, and support are included or billed separately.

How plugin, theme and integration compatibility checks work

Compatibility checks after a Mautic upgrade cover more than the core application. Mautic relies on several background components that can break silently when the release changes, so the first job is to inventory them and re-verify each one against the target version. The Mautic cron jobs documentation describes three recurring jobs that matter here: the segment update, the campaign update and the campaign trigger. The docs say these should be staggered rather than run at the same moment. Confirm the schedule on the new server, check that each job runs to completion, and confirm that segment membership and campaign progression move as expected on a staging copy with real contact volumes.

Two other components depend on the same scheduling layer. If you send segment emails, the broadcasts command must be tested with a small test segment before go-live. If your installation queues email, the messenger consumer must be running and must pick up queued messages. Check how the consumer is supervised on the new host, because a consumer that stops quietly will hold back sends without raising an obvious error in the interface. Record the expected behavior before the upgrade so the team has a clear pass or fail standard after it.

Authentication and CRM connectors need their own checks. If Mautic is configured for SAML single sign-on, the identity provider must continue to send email, first name and last name attributes. Verify this with a test login after the upgrade, not just a successful page load. The HubSpot plugin pushes contacts based on contact actions or point triggers, and the Mautic documentation also includes a Salesforce integration page. Both plugins should be tested against the current release, including a round trip for a test contact, a point-triggered push and a check for duplicate records in the CRM. Confirm with each plugin's current documentation which Mautic versions it supports before you schedule the upgrade.

Custom plugins and themes need code review against the target version rather than a simple load test. Review each custom bundle for calls to deprecated Symfony or Mautic APIs, template overrides that depend on changed markup, and any scheduled commands it registers. Because Mautic's documented PHP requirements change between majors, confirm the PHP version each custom component needs as well. Ask the team that owns each customization to sign off on the review, and keep the results with the change record.

The Mautic documentation describes no LDAP option for directory-based sign-in. If your organization expects users to authenticate against a directory, confirm in the target release whether any supported method covers that need, and do not assume an older configuration or a third-party extension will still work. Treat any directory dependency as an open item until it is verified, and add the result to the upgrade test plan. Anything you cannot confirm from the documentation or from the release itself should be raised with the Mautic project or your implementation partner before the upgrade window is set.

What goes wrong in Mautic upgrades and how to prevent it

Many Mautic upgrade failures come from how the change is sequenced and from the environment around the software. Each card names a common failure, the prevention step and the check that shows the step worked. A staging run and a tested restore are the two gates every upgrade should pass.

Upgrading PHP and Mautic together

Changing the PHP version and the Mautic release in one window makes a failure hard to trace, because you cannot tell which change broke a campaign or form. Mautic 7.0 requires PHP 8.2, 8.3, 8.4 or 8.5, so a runtime change is often part of the plan. Prevention: upgrade PHP on a staging copy first, confirm Mautic runs on it, then move the Mautic release in a separate window. Check: a staging run on a copy of production data that sends a test campaign, submits a test form and completes a segment rebuild.

Skipping intermediate versions

Jumping several releases at once leaves database migrations and configuration changes untested along the way. Mautic ships monthly patch releases, minor releases every three months and major releases every two years, so an install that has fallen behind can sit several steps back. Prevention: map the current version to the target, list each documented step in order, and run them on staging. Check: every migration completes without errors, the dashboard, contact timeline and campaign builder load after each step, and the sequence is recorded in the change log.

Host below the requirements

The project states that Mautic should not run on shared hosting and recommends a VPS or dedicated server. Version requirements also constrain the stack: Mautic 7.0 needs a supported PHP version, MySQL 5.7 or higher with InnoDB or MariaDB 10.2 or higher, a supported web server, and npm from Mautic 5.0 onward. Prevention: check the target release's requirements against the host before scheduling the upgrade, and rebuild the server where it falls short. Check: a written comparison of the web server, PHP version, extensions, database engine and npm against the documented list, signed off before the change.

Background workers that stop silently

Segments, campaigns and triggers run from cron jobs that the docs say should be staggered, and queued email needs a running messenger consumer. Overlapping jobs can compete for the same contacts, while a stopped job or consumer freezes segments and campaigns without an obvious error in the admin screens. Prevention: stagger the schedules, stop overlapping runs with a lock or single-instance wrapper, and run the consumer under a process supervisor with alerts. Check: a test contact moves through a segment and campaign on schedule, and a queued test email still delivers after a deliberate consumer restart.

Plugins abandoned by their authors

Third-party plugins and custom code are built against specific Mautic releases, and an author may stop maintaining them before the next major version. A plugin that breaks after an upgrade can fail quietly in forms, CRM syncs or tracking. Prevention: before the upgrade, list every plugin with its author, last release date and stated compatibility, then decide for each whether to update, replace or retire it. Check: every plugin runs on staging against the target release, its integration test passes, such as a CRM sync or form submission, and the result is recorded in the upgrade sign-off.

Rollbacks that restore code only

Restoring the previous code directory after a failed upgrade leaves the database in its migrated state, so the old code runs against a new schema. Contact records, consent entries and campaign history can then diverge from what the code expects. Prevention: take a database backup and a copy of files and configuration immediately before the change, and rehearse restoring both together on staging. Check: the restore drill returns the staging instance to the pre-upgrade version with contacts, segments and recent consent records matching the backup, and the measured restore time is written into the runbook.

Which upgrade tasks teams keep in-house and which they hand to a partner

This table maps each recurring Mautic upgrade task to the skills it needs and to whether a team with those skills can keep it or is better handed to a partner under a fixed scope or retainer. Read each row against your own staff: a task marked in-house still needs a named owner, while a partner-led task still needs your marketing operations people to sign off on campaign behavior. The main takeaway is that the riskiest steps, cutover and regression testing of campaign logic, are the ones where skill gaps and unclear ownership cause the most damage.

Task	Skills needed	Keep in-house when	Hand to a partner when
Monitoring the release calendar and reading release notes	Mautic configuration, marketing operations	A named owner tracks the patch, minor and major cadence and checks support end dates for your version	Your team has no capacity to track releases, or you want a written upgrade plan tied to a fixed scope
Server and PHP administration	Linux administration, PHP	Staff can patch the OS, change PHP versions and confirm the PHP version matches the Mautic release requirements	The server is shared with other workloads, or PHP changes between major versions need hardening and rollback planning
Database backups and restore tests	MySQL or MariaDB, Linux administration	Backups run on a schedule and someone has restored a copy to a separate host and checked it opens in Mautic	Restore tests have never been run, or the database is large enough that restore timing needs formal testing
Staging builds	Linux administration, PHP, Mautic configuration	Your team can clone production, apply the same configuration and reproduce the target release in a non-production environment	Staging does not match production, or plugins and custom code need a rebuild before every upgrade
Plugin and custom code review	PHP, Mautic configuration	Developers can read plugin changelogs and test custom code against the new release	Custom plugins or themes were built years ago, or no one on staff knows the code well enough to judge compatibility
Cron and messenger verification	Linux administration, Mautic configuration	Staff confirm segment, campaign, broadcast and queue jobs run after the upgrade and that job schedules stay staggered	Queued email sends fail silently after past upgrades, or cron timing has never been documented
Campaign regression tests	Marketing operations, Mautic configuration	Marketing operations keeps a written list of critical campaigns, segments and forms with expected results to check after each change	No test cases exist, or the campaign logic is large enough that scripted or structured checks are needed
Cutover night execution	Linux administration, PHP, MySQL or MariaDB, Mautic configuration	The team has rehearsed the cutover on staging, has a rollback path and has an agreed window with marketing	The upgrade crosses a major version, changes PHP, or touches live tracking and form endpoints
Post-launch patch handling	Linux administration, PHP, Mautic configuration	Staff track patch releases, apply them on the agreed schedule and keep a record of each change	Patches arrive faster than staff can test them, or you want continuous support under a retainer

How the upgrade path changes by starting point

An install on Mautic 4.4 is furthest from the current release line. According to the Mautic releases page, 4.4 has paid Extended Long Term Support through 31 December 2026, so that date is the outer limit for keeping the install patched without a major move. The plan is usually a staged path through intermediate major releases, with each hop tested on a copy of production before it reaches live users. Because the ELTS term sets the deadline, the first task is to confirm what the agreement covers.

Confirm the ELTS agreement: who holds it, which patches it covers, and whether it ends on 31 December 2026 or renews.
Plan each major hop: check the requirements page for every target release, since PHP and database versions can change between majors.
Test custom code and plugins first: plugins and themes built for 4.x may not load on later majors, so each one needs a compatibility decision.
Budget the staging environment: a production copy for each hop is usually one of the largest effort drivers, along with testing.
Check the server runtime: the host must run a PHP version the target release supports before any upgrade begins.

Confirm with your host or provider which PHP and database versions the current server runs, and who signs and pays for the ELTS agreement.

What buyers ask before hiring help for Mautic upgrades

What drives the cost of a Mautic upgrade?

The main cost drivers are how far the installation is behind the target release, how many plugins and custom code paths need checking, and how much of the environment must be rebuilt. Labor is the largest component: someone plans the path, tests it on a staging copy, updates the PHP and database stack, verifies cron jobs and queue workers, and documents the result. Hosting and any paid support for old versions are the other recurring or one-time costs. Ask any partner for a written quote that lists each task, the environments involved, who performs each step, and what is excluded, such as plugin rewrites or new features.

Can a Mautic upgrade be quoted as a fixed-scope project?

Yes, most upgrade work can be scoped in advance if the starting point is known. Fixed-scope means the systems in scope, the deliverables, the test steps and the timeline are agreed in writing before work starts. DeployOpen works this way for most engagements. The scope is easiest to fix after an inventory: the current Mautic version, PHP version, database version, web server, installed plugins and themes, custom code, and the cron and email queue setup. Changes found during testing, such as a plugin that needs replacing, should be handled through a written change to the scope.

How long does a Mautic upgrade take, and what sets that time?

Duration depends on the distance between the current and target releases, the PHP and database changes required, and the number of plugins and custom components that must be tested. Mautic releases follow a stated cadence of monthly patches, quarterly minor releases and major releases every two years, so the gap between versions varies widely between installations. Other time drivers include the size of the database, whether a staging environment already exists, how many business owners must approve test results, and whether a maintenance window is needed. Ask for a timeline in the written quote that names each phase and its dependencies.

Can our in-house team upgrade Mautic without an outside partner?

An internal team can upgrade Mautic if it has PHP and Symfony-based application experience, Linux server administration skills, database experience, and time to test. The work is mostly methodical: back up, build a staging copy, run the upgrade, check cron jobs and queued email, then test plugins and campaigns. Teams without that mix often find the risk sits in plugin compatibility and campaign logic, which are easy to miss. Consider an outside partner for the first major upgrade, or whenever a plugin or custom code path has no clear owner.

What does a Mautic upgrade partner need from our team?

Plan for access and decisions before work starts. The partner usually needs server access to the staging and production environments, a current backup with a tested restore, a test contact set that is safe to use in non-production systems, a complete plugin and theme list with versions and sources, and named owners who can approve test results and business decisions. Confirm with your privacy or legal team how test data may be used. Also provide documentation of any custom code, the existing cron schedule, and the email sending setup, since these often break after an upgrade.

Does Mautic have a license fee, and what do we actually pay for?

Mautic is free software. Its GitHub repository is licensed under GPL-3.0, and the project offers a free self-hosted download. The costs you should budget for are labor for planning, implementation and testing, hosting on a VPS or dedicated server (the project advises against shared hosting), an email sending service if you use one, and any paid support for old versions. For example, Mautic 4.4 has a paid Extended Long Term Support option through 31 December 2026. Confirm the terms, pricing and eligibility of any paid support directly with the vendor offering it.

What does ongoing Mautic support cover after the upgrade is done?

Ongoing support covers the operational work that keeps a Mautic installation on a supported path after launch. Typical items include applying monthly patch releases, planning quarterly minor releases, tracking end-of-support dates for the versions you run, checking plugin compatibility before each change, reviewing cron and queue health, and restoring from backup when needed. DeployOpen offers ongoing support and upgrades as retainers. Ask for the written scope to name the response expectations, the systems covered, and what is excluded, such as new campaign design or new integrations.

What happens when a Mautic plugin stops being maintained?

An unmaintained plugin is a risk, because it may break after a PHP or Mautic upgrade and may contain unpatched security issues. First, check the plugin's source repository for recent commits, release notes and compatibility with your target Mautic version. If it is incompatible, the usual options are to fork and maintain it, replace it with a supported plugin or an API-based integration, or retire the feature it provided. Each option changes cost and risk, so decide before the upgrade starts. Keep a plugin register with owners so this check happens on every release, not only during a crisis.

How DeployOpen works on this

DeployOpen treats each Mautic upgrade as a scoped project against the release calendar, the PHP requirement and your installed plugins and themes. We plan, build and test the change in a copy of your environment, then hand over documented steps and support it after launch under a fixed-scope agreement or retainer.

How we scope

Inventory the current Mautic version, PHP version, database, web server and cron setup
Map the target release against the published support windows and PHP range
List every custom plugin, theme and third-party integration that must be checked for compatibility
Agree the written scope, deliverables and timeline before any upgrade work starts

How we build

Rebuild a staging copy of production in your own infrastructure for rehearsal
Run the upgrade steps in staging, including Composer updates and database migrations
Verify plugin and theme compatibility, cron jobs, the messenger consumer and email sending
Test tracking, forms, segments and campaigns against a defined checklist before cutover

How we hand over

Document the final version, PHP version, configuration changes and rollback steps
Provide a runbook for the monthly patch and quarterly minor update cycle
Record test results and any open compatibility issues with owners and next actions
Walk your administrators through the change so they can apply later patches themselves

How we support

Offer ongoing support, upgrades and continuous testing as a retainer
Track the end-of-support dates for your installed release and plan the next move early
Re-check plugins and themes against each new release before you apply it
Confirm with your team what support, backup and change-control terms apply in your environment

Mautic upgrades and support