Where Mule 4.6 LTS stands on 4 November 2026

Mule 4.6 LTS left standard support in August 2026 and is in extended support until February 2027, per MuleSoft's published runtime pages. The supported way forward is Mule 4.9 LTS (standard support to August 2027, extended to February 2028), and moving to it also means moving your applications to Java 17.

If you run Mule on CloudHub or on-premises and are weighing a MuleSoft consulting, support and migration plan, this is the date that sets your calendar. The table uses MuleSoft's LTS and Edge release cadence page and Java adoption page, checked 4 November 2026.

MuleSoft's cadence page gives dates for Standard and Extended support and uses "End of Life" for versions past the end of extended support, so for 4.6 that point is February 2027. On CloudHub and CloudHub 2.0, apps still on an End of Life version are upgraded in the monthly upgrade window. What the extended window includes is defined by MuleSoft's support policy and your contract, so read both before you plan around it. Whatever they say, AceMQ is independent of MuleSoft and Salesforce and has no access to MuleSoft patches or entitlements. Independent support covers running, tuning and troubleshooting your runtimes around the clock; it is not a source of vendor fixes.

Treat February 2027 as the last date by which a running 4.6 estate has a vendor-supported runtime, and work back from it. An upgrade needs regression testing in every environment, so the practical start date is earlier than the calendar suggests.

Mule 4.6 LTS runs on Java 8, 11 and 17. Mule 4.9 LTS lists Java 17 only, and MuleSoft's Java adoption page says support for Java 8 ends with the 4.9 release and that Java 11 will no longer be available. So the runtime upgrade carries a JDK change with it. Check these before you estimate effort:

• Custom Java modules and SDK connectors compiled for Java 8 or 11, and any reflection or internal-API use that Java 17 blocks.
• JDBC drivers, security providers and keystores pinned to a JDK version, and TLS cipher and protocol settings that changed between JDKs.
• Connector and plugin versions in every application, since each connector has its own supported runtime range.
• DataWeave scripts and MUnit tests, which are the regression suite you will lean on; applications without tests need them written first.
• The deployment target: CloudHub worker versions, Runtime Fabric images, or your own Java installation on servers.

Applications with no custom Java and current connectors are usually the quick wins. The ones with custom modules decide the schedule.

1. Upgrade to Mule 4.9 LTS. The default for estates that want to stay on MuleSoft. Best when most applications are standard flows with maintained connectors.
2. Move to an Edge release. Edge releases have much shorter windows (4.13 Edge ends standard support in March 2027), so they suit teams that upgrade every few months, not teams that want stability.
3. Stay on 4.6 through extended support. Reasonable for a few low-risk applications that you will retire or replace within the window; risky as a plan for the whole estate.
4. Replace part of the estate. Thin pass-through APIs and scheduled file movements cost the same capacity as complex orchestrations, so an upgrade deadline is a good moment to ask which are worth carrying forward.

MuleSoft's usage documentation measures Mule runtime usage in allocated vCores (shown as cores/vCores in the plan tables; usage types depend on your plan), so every application you retire or consolidate before the upgrade is one you do not have to test on Java 17, and its vCores can be released.

List every application with its runtime, Java version, connectors, custom code, owner and last change. Sort them into three groups: upgrade as-is, upgrade after fixes, and candidates to retire or replace. The third group is where the options beyond MuleSoft matter, and the criteria for judging them are on the comparison page; this post does not argue for leaving. For a typical engagement shape, see the integration estate assessment.

Whichever path you choose, keep operations covered during the change. MuleSoft support gives you an engineer on call for production incidents while the upgrade runs, including the worker restarts and memory problems that upgrades sometimes expose.

1. Inventory first. Pull runtime, Java version, connector versions and custom code for every application, and mark which ones have MUnit coverage.
2. Pilot two applications that represent your estate: one plain, one with custom Java. Upgrade them in a lower environment and record every change the pilot forces.
3. Fix connectors and drivers in bulk once the pilot shows which versions are needed, rather than application by application.
4. Run old and new side by side on mirrored traffic for critical flows, compare payloads and response times, and keep the old runtime deployable until the new one has carried a full business cycle.
5. Schedule by criticality, with the least critical applications first, so the plan finishes with margin before February 2027.

Checked 4 November 2026: MuleSoft runtime release cadence, MuleSoft Java adoption and MuleSoft vCore pricing, usage and rates. Dates are MuleSoft's and can change; re-check before you commit a plan.