Mautic Upgrade Checklist for Sales Teams

Protect the sales system before changing production

A sales team should treat a Mautic upgrade as a controlled change to every workflow that moves or records revenue. Before production, inventory plugins and integrations, confirm target PHP and database requirements, restore-test files and database backups, and rehearse one documented upgrade path in staging with live jobs disabled. Afterward, verify Mautic itself and every sales-critical form, campaign, API, webhook, integration, and plugin screen. Record owners and results so a failed check stops the production change or triggers the prepared rollback.

Inventory everything sales depends on

Start with the paths a lead or opportunity actually follows, not a generic server list. Give each item an owner and record its current version or configuration so the staging result can be compared with a known baseline.

• Plugins and themes: record the installed version, declared Mautic and PHP constraints, publisher evidence, and the screens or jobs the sales team uses.
• Lead capture: list production forms, landing-page submissions, field mappings, and any handoff that creates or updates a contact.
• Automation: identify sales-critical campaigns, segments, scheduled jobs, and the expected result of one safe test record.
• Connected systems: list APIs, webhooks, mail transport, integrations, and the credentials or endpoints each staging test will use.
• Sales workflow: capture the dashboard, editor, plugin-specific screens, and reports people must be able to open after the change.

The output is a test register: item, owner, evidence, pre-upgrade result, staging result, and production result. A plugin name without its exact version and test path is not a usable inventory entry.

Verify the target requirements and plugin evidence

Confirm the Mautic 7 server baseline

For the Mautic 7 target documented in the source guide, confirm PHP 8.2 or newer and either MySQL 8.4 or newer or MariaDB 10.11 or newer before changing application files. Check the target host itself; a control-panel label or a different command-line PHP binary can describe a different runtime than the web application uses.

Requirements verified August 23, 2026 in the source-backed Mautic 5-to-7 upgrade guide. Recheck the requirements for the exact release you plan to install.

Separate a declaration from a passed test

For every plugin, capture what the publisher declares, where it publishes that evidence, and when you retrieved it. Then track the plugin through three distinct stages:

The Mautic 7 compatible-plugins guide explains how to read vendor compatibility statements and preserve unknowns instead of turning them into assumptions.

Restore-test both files and the database

Take a complete copy of the Mautic application files and the database. Preserve the versions and configuration needed to put that pair back together, then restore both into staging. Open the restored instance and run a small set of known checks before using it as the upgrade rehearsal.

• Record where the files backup and database backup live, when each completed, and who can access them during the maintenance window.
• Restore both backups to a separate environment and confirm the restored instance starts with the expected data and configuration.
• Write the rollback trigger and the restore steps before production begins.
• Take a fresh production rollback backup immediately before the approved change.

The files-and-database backup and restore test follow the workflow documented in the upgrade guide.

Rehearse one upgrade path in staging

Use a representative clone. Turn off staging cron jobs before the copy can repeat live campaign actions or sends, and use a test mail transport when outbound behavior must be exercised. Keep production credentials and live destinations out of the rehearsal wherever the integration allows it.

1. Record the starting Mautic, PHP, database, plugin, and theme versions.
2. Run the selected upgrade procedure and save its output.
3. Complete migrations and cache work required by that procedure.
4. Run the full post-upgrade checklist below, including every plugin-specific test from the inventory.
5. Resolve failures, rebuild staging from the known backup if needed, and repeat until the process is reproducible.

Put commercial plugins at explicit checkpoints

An installed commercial plugin belongs in the inventory before the core change, in the staging test immediately after the core change, and in production verification. For a new plugin, keep adoption as a separate checkpoint: finish the core upgrade checks in staging, then install and verify the plugin there before considering production.

Deal Flow compatibility evidence

Deal Flow's product-level compatibility statement is: Built for Mautic 7.x, mostly compatible with 5.x+. Deal Flow v0.9.4 declares Mautic core ^5, ^6, or ^7 and PHP ^8.1. The published compatibility record does not include a tested-version matrix or a recorded test date, so the package constraints and your staging result should remain separate fields in the checklist.

Follow the documented installation sequence only after the core staging checkpoint is stable, then verify the plugin's documented routes and the screens your team will use.

Deal Flow product details checked September 1, 2026 against the Mautic compatibility and release notes and installation documentation.

Run the tested production sequence with a rollback point

Schedule the change after the staging procedure and test register are complete. Freeze unrelated application changes for the window, take the fresh rollback backup, and use the same upgrade path, sequence, and deployment user that passed in staging. Save command output and note any difference from rehearsal.

If a required check fails or production behavior differs from staging, stop adding changes. Use the written rollback trigger and restore path, or resolve the specific failure inside the approved window before continuing.

Verify the complete sales path after the upgrade

Run these checks first in staging and then in production. Use named test records and expected outcomes so “looks fine” is not the acceptance standard.

Record pass, fail, owner, timestamp, and evidence for each row. Production sign-off is the completed register, not the absence of a visible error.

Frequently asked questions

What should a sales team back up before upgrading Mautic?

Back up both the Mautic application files and the database, then restore both in staging before production. A backup you have not restored does not establish that the recovery path works.

Which PHP and database versions does Mautic 7 require?

The source checks used for this guide list PHP 8.2 or newer, MySQL 8.4 or newer, or MariaDB 10.11 or newer for the Mautic 7 target. Recheck the current target's requirements before scheduling production.

When should plugin compatibility be checked?

Check each plugin before selecting the target version, again after the upgrade in staging, and again during production verification. Record the declared constraints, publisher evidence, and the exact version you tested.

What should sales teams verify after the upgrade?

Verify the installed version, System Info, logs, dashboard, editor, forms, campaigns, cron jobs, mail, APIs, webhooks, integrations, plugins, themes, and every plugin-specific screen the sales team depends on.

Where does Deal Flow fit in the upgrade sequence?

If Deal Flow is already installed, include it in the pre-upgrade inventory and test its plugin-specific screens in staging after the core upgrade. If it is new, finish the core staging checks before installing and verifying it there.