Put the published deadline in the operating plan

The official Mautic release index says Mautic 6.0 receives security support until September 30, 2026. On September 5, the difference between those dates is 25 calendar days. That is a planning interval, not a claim that an instance changes condition at a precise hour on the final day.

Source: Mautic Releases, fetched September 5, 2026.

The practical change is the maintenance assumption. Before the published end date, operators can point to Mautic’s stated security-support window. After it, a team needs another supported route or a written risk decision. The date does not prove that every Mautic 6 instance has a vulnerability, and it should not be turned into artificial scarcity. It does mean that leaving the decision unowned is no longer a neutral choice.

Our evergreen Mautic 6 end-of-life guide explains the support boundary and the planning questions in more depth. This post has a narrower purpose: turn the remaining calendar window into a short list of decisions that can be closed now.

Do not treat Mautic 6 ELTS as settled

Extended Long Term Support, or ELTS, is Mautic’s paid deferral program for back-ported security fixes. Mautic’s release schedule currently lists an ELTS date of September 30, 2027 for the 6.0 branch and labels ELTS as a paid service.

Sources: Mautic Releases, including the 6.0 schedule row and ELTS footnote, and Extended Long Term Support (ELTS); both fetched September 5, 2026 from the official release index and official ELTS page.

That is not the full official record. Mautic’s dedicated ELTS page says the bridge release will have no Mautic 6 ELTS offering and advises users to migrate to Mautic 7.3 when it is published. Elsewhere on the same page, Mautic says support for Mautic 6 can be purchased pre-emptively. Those statements conflict.

Source: Extended Long Term Support (ELTS), Mautic 6 and overview sections, fetched September 5, 2026.

Planning rule: name ELTS as a possible paid deferral route, but confirm Mautic 6 eligibility, dates, scope, and terms directly with Mautic before putting it on the critical path.

A source conflict is not a reason to hide the option, and it is not permission to present the option as settled. Record the answer you receive, who supplied it, and when. Until then, keep the upgrade route active.

Use the remaining window to build upgrade evidence

The most useful work now is not a rushed production change. It is evidence that tells the person approving the change what is ready, what is unknown, and what can be reversed. Start with the live instance and write down its Mautic release, PHP and database versions, scheduled jobs, integrations, custom code, and installed plugins.

  1. Name one owner. Give one person responsibility for the upgrade or deferral decision, with named technical and business reviewers.
  2. Make recovery real. Take a current backup, restore it in an isolated environment, and record the rollback conditions before touching production.
  3. Build a representative staging test. Exercise forms, campaigns, email editing, segments, scheduled jobs, API integrations, and the revenue handoffs the instance supports.
  4. Verify plugins one by one. Use the vendor’s current compatibility statement and a recorded staging result. Our Mautic 7 plugin compatibility guide provides a reusable evidence checklist.
  5. Separate readiness from scheduling. A team can finish inventory, restore testing, ownership, and acceptance criteria before its final production date is set.

If the estate also includes Mautic 5, the Mautic 5-to-7 upgrade guide keeps that older branch from disappearing inside the Mautic 6 decision. Treat each live branch as its own migration path, then combine shared tests where the target environment truly matches.

Close the decision before the calendar closes it

By the end of this review, the team should have one of three documented directions: a tested move to a supported Mautic release, a directly confirmed ELTS arrangement with its scope written down, or an explicit short-term risk decision with controls and an exit date. These are operating choices, not marketing labels. Each needs an owner and evidence.

Do not let the official-page conflict consume the whole window. Ask Mautic about ELTS in parallel while staging work continues. If ELTS is available on acceptable terms, that answer can change the schedule. If it is not, the testing already completed still moves the upgrade forward.

The useful urgency here comes from a published support date. On September 5, 2026, there are 25 calendar days until September 30. That is enough time to replace ambiguity with a named route, even when the production change itself needs a longer controlled process.

Deadline source: Mautic Releases, fetched September 5, 2026 from the official release index.

Sources checked today

This post uses two Mautic-controlled pages fetched September 5, 2026: the release index and support schedule, and the ELTS program page. The deadline is stated from the release index. The ELTS section preserves the disagreement between those pages rather than choosing one statement and omitting the other.

Planning how deal operations will continue through your Mautic upgrade?

See Deal Flow for Your Mautic Stack