We move MuleSoft apps from Mule 4.6 to 4.9 and test each app before the runtime upgrade ships.
We build and run MuleSoft integrations on Anypoint Platform, move apps off unsupported Mule runtimes, choose between the Edge and LTS channels, and clean up API estates that grew one project at a time.
Cohash builds, upgrades and supports MuleSoft on Anypoint Platform.
We move apps from Mule 4.6 LTS to 4.9 LTS or to current Edge releases, reorganize APIs into reusable system, process and experience layers, and set up API policies, monitoring and CI/CD. Certified MuleSoft developers and architects work onsite in the US, nearshore or offshore, on contract, contract-to-hire or permanent terms.
you probably need this if
Production apps still run on Mule 4.6 and February 2027 is on nobody's plan.
An automatic Edge upgrade on CloudHub broke a flow and nobody saw it coming.
Each project built its own SAP connection instead of reusing a system API. Now there are several to maintain.
terms on this pageLTSdefinitionLong-term support. Databricks fixes stability and security problems in an LTS runtime for three years after release. Other runtimes get six months, which is why an LTS is the one to build on.explained in a field note →Extended SupportdefinitionIBM's paid support once a release's normal support has ended. Security Verify Access 10.0.x moved onto it in April 2026, except on hardware appliances, so check your contract still covers you.explained in a field note →
Feb 2025Mule 4.9 LTS Out since February 2025 and runs on Java 17 only. Standard support lasts until August 2027 and extended support until February 2028, so apps that move here now will have to move again.
Oct 2026Mule 4.13 Edge Mule 4.13 is the October 2026 Edge release, on Java 17. Standard support ends in March 2027 and extended support in June 2027, so an app put on it now will need another upgrade next year.
today · Nov 09, 2026
Feb 2027aheadMule 4.6 LTS reaches end of extended support Standard support ended in August 2026. Extended support stops in February 2027, so this is the last window to move. MuleSoft kept it around longer because it still runs on Java 8 and 11 as well as 17.
no date yetMule 4.6 vs 4.9: what's differentJava is the big change. Mule 4.6 runs on Java 8, 11 or 17, and 4.9 only runs on Java 17. MuleSoft won't auto-upgrade a Java 8 or 11 app to 4.9, so someone has to move it. Support dates differ too. 4.6 LTS loses extended support in February 2027, and 4.9 LTS keeps standard support until August 2027.
no date yetRelease channelsMuleSoft ships patches every month. Edge gets up to three new releases a year. LTS releases come out in February with at least 18 months of standard support, and MuleSoft recommends LTS if you want to avoid upgrading often.
the story · mulesoft estate
From the first call to a setup your own team can run.
Here's what usually prompts a call about your MuleSoft estate, what we do about it and in which order, and where you end up.
01 · where it hurts02 · what we change03 · how it runs04 · where you end up
incident board · mulesoft estate3 open
openProduction apps still run on Mule 4.6 and February 2027 is on nobody's plan.
recurringAn automatic Edge upgrade on CloudHub broke a flow and nobody saw it coming.
blockedEach project built its own SAP connection instead of reusing a system API. Now there are several to maintain.
exposure
Mule runtime upgradesEdge or LTS channel decisionsAPI-led integration buildsAPI governance and securityCI/CD and operationsMuleSoft staffing
S/4
startrehearsehandover
Estate scan
Upgrade and channel plan
Batch upgrades
Governance and handover
we are here
ready to hand over
All the apps are on 4.9 LTS before 4.6 support ends.
SAP changes happen once, in a system API, and the credentials live in one place.
An inventory of every app with its runtime, channel and connectors. Apps that aren't…
An upgrade plan that puts each app on LTS or Edge. Risk sets the order the apps move in.
chapter 01 · where it hurts
Why teams reach out
Production apps still run on Mule 4.6 and February 2027 is on nobody's plan.
An automatic Edge upgrade on CloudHub broke a flow and nobody saw it coming.
Each project built its own SAP connection instead of reusing a system API. Now there are several to maintain.
chapter 02 · what we change
How we solve it
Mule runtime upgrades
Edge or LTS channel decisions
API-led integration builds
API governance and security
CI/CD and operations
MuleSoft staffing
chapter 03 · how it runs
Our approach
Estate scan
Upgrade and channel plan
Batch upgrades
Governance and handover
chapter 04 · where you end up
What changes
All the apps are on 4.9 LTS before 4.6 support ends.
SAP changes happen once, in a system API, and the credentials live in one place.
An inventory of every app with its runtime, channel and connectors. Apps that aren't ready for Java 17 get flagged.
An upgrade plan that puts each app on LTS or Edge. Risk sets the order the apps move in.
what we do
Our MuleSoft work
6 kinds of MuleSoft work, each run by engineers who have done it on live tenants.
Apps moved off Mule 4.6 LTS before its extended support ends, to 4.9 LTS or the current Edge release. Includes Java 17 compatibility checks for connectors and custom Java code.
A per-app choice between Edge releases, which CloudHub upgrades automatically after standard support ends, and LTS releases, which carry longer support but aren't auto-upgraded.
System, process and experience APIs for SAP, Salesforce, Workday and databases, with RAML or OAS specs published to Exchange and reused instead of copied.
Client ID enforcement, OAuth 2.0 policies, rate limits and API Governance rulesets applied consistently across business groups.
Maven-based pipelines, MUnit test coverage, environment promotion and alerting on Anypoint Monitoring so failures reach someone before users do.
MuleSoft developers, integration architects and platform administrators, onsite, nearshore or offshore, on contract, contract-to-hire or permanent terms.
capability 01 / 06in production
S/4
Mule runtime upgrades
Apps moved off Mule 4.6 LTS before its extended support ends, to 4.9 LTS or the current Edge release. Includes Java 17 compatibility checks for connectors and custom Java code.
A per-app choice between Edge releases, which CloudHub upgrades automatically after standard support ends, and LTS releases, which carry longer support but aren't auto-upgraded.
System, process and experience APIs for SAP, Salesforce, Workday and databases, with RAML or OAS specs published to Exchange and reused instead of copied.
MuleSoft developers, integration architects and platform administrators, onsite, nearshore or offshore, on contract, contract-to-hire or permanent terms.
We pieced these together from MuleSoft situations that come up a lot. They're patterns. You won't find a specific client in them.
case file 01
Ninety apps still on Mule 4.6. Extended support runs out in February 2027.
composite · not a client story
Beforethe situation
A distributor runs about ninety Mule apps on 4.6 LTS across CloudHub 2.0 and Runtime Fabric. Several use custom Java components written for Java 8, and MUnit coverage is patchy.
What we dothe work
We scan every app for Java 17 and connector issues and group them by risk, then upgrade the low-risk batch first to set the pattern. Custom Java gets rewritten or replaced with standard connectors. MUnit tests go in before each batch moves.
Afterwhere you end up
All the apps are on 4.9 LTS before 4.6 support ends. When the next upgrade comes, the tests are already there.
case file 02
Fourteen ways to call SAP
composite · not a client story
Beforethe situation
A manufacturer's MuleSoft estate grew one project at a time. Fourteen apps now call SAP directly, each with its own mapping, its own credentials and its own idea of error handling.
What we dothe work
We design a small set of SAP system APIs covering the shared objects, publish them to Exchange and move the fourteen apps onto them one at a time, retiring direct connections as we go.
Afterwhere you end up
SAP changes happen once, in a system API, and the credentials live in one place. New projects reuse what exists.
We don't start a step until the last one has produced something you can check.
step 01
Estate scan
We list each app with its runtime and channel, its connectors, any custom Java and its test coverage. Apps that won't run on Java 17 get a flag.
step 02
Upgrade and channel plan
We put each app on 4.9 LTS or on the current Edge release. Risk and support dates set the order.
step 03
Batch upgrades
Apps go through CI/CD in batches. Where MUnit coverage is thin we add tests first, and regression runs hit real endpoints.
step 04
Governance and handover
We standardize the API policies and governance rulesets and set up monitoring alerts. Your support team gets the runbooks.
ai on mulesoft
Where AI fits on MuleSoft, and where it needs guardrails.
MuleSoft's AI story is mostly MCP. The DX MCP Server gives coding assistants permission-scoped access to Anypoint Platform, and the Platform MCP Server gives governed access to APIs, agents, MCP servers and LLMs. The bigger job for integration teams is making the APIs they already have safe for agents to call.
AI agentasks for data or an action
Scoped identityonly the access it needs
MCP serverthe one door into the platform
Logged, approveda person signs off on writes
MuleSoftdoes the work
MuleSoft has two official MCP servers, the DX MCP Server for development and the Platform MCP Server for governance. An agent calling business APIs should go through API Manager with its own client credentials. Rate-limit it and log it in Anypoint Monitoring. Writes into core systems still need approval.
MuleSoft DX MCP Server
An AI assistant in the IDE uses it to write API specs, build and configure Mule apps, publish to Exchange, and deploy to CloudHub 2.0 or Runtime Fabric. We keep it to non-production. Anything going to production goes through the CI/CD pipeline.
MuleSoft Platform MCP Server
This server scans for and discovers APIs, agents, MCP servers and LLMs. It applies policies like PII detection, semantic routing and token controls, and monitors traffic, cost and performance. We use it to keep an inventory of which agents call which APIs.
Experience APIs as agent tools
Point agents at experience or process APIs, never at system APIs that go straight into SAP or Workday. We apply API Manager policies like client ID enforcement and rate limiting to any API an agent touches, plus MUnit tests for agent-style inputs.
Runtime upgrades with AI help
Mule 4.6 LTS reaches the end of extended support in February 2027. We use AI to explain old DataWeave and flows and draft missing MUnit tests, then upgrade apps in batches through CI/CD.
architecture
Apps, partners and agents call MuleSoft APIs. Only system APIs talk to the backends.
Apps, partners and AI agents call experience APIs. Process APIs orchestrate the business logic and call system APIs, which are the only layer that talks to SAP, Salesforce, Workday and databases.
use cases
Typical MuleSoft projects
The work teams usually bring us, and the platforms MuleSoft has to talk to while we do it.
MUL-01Apps still run on Mule 4.6. Extended support ends in February 2027 and the move isn't planned yet.
common request
MUL-02CloudHub upgraded Edge apps automatically and something broke. Nobody knew the upgrade was coming.
common request
MUL-03Point-to-point flows were built per project and nothing is reused
common request
MUL-04Every team set its own API policies, and security can't audit them as one set
common request
MUL-05Deployments are manual and MUnit coverage is thin
common request
MUL-06You can't hire certified MuleSoft developers quickly enough
common request
These are working documents, written against your configuration, so your team can run them without us.
inventory01
An inventory of every app with its runtime, channel and connectors. Apps that aren't ready for Java 17 get flagged.
yours to keep
plan02
An upgrade plan that puts each app on LTS or Edge. Risk sets the order the apps move in.
yours to keep
tests03
MUnit coverage numbers for each upgraded app. We write the missing tests before the app moves.
yours to keep
code04
A baseline of API policies and governance rulesets. Every business group works from the same one.
yours to keep
tests05
Shared CI/CD templates, so every app builds, tests and gets promoted the same way
yours to keep
runbook06
A runbook for run support. Every monitoring alert in it names an owner.
yours to keep
talent and delivery · mulesoft
Certified engineers, wherever you need them.
Some clients want a project team, some want a couple of engineers on theirs. Either works. Onsite, nearshore or offshore, with handovers across time zones that keep things moving.
Put these to anyone bidding on your MuleSoft work. The ones who've done it answer differently from the ones who've read about it.
Q1
Which of our apps won't run on Java 17, and why?
Mule 4.9 and later run on Java 17. The things that break are old custom Java and stale connector versions, and a scan will find them before the upgrade does.
Q2
Which apps should sit on LTS, and which on Edge?
CloudHub upgrades Edge apps automatically after standard support ends. Stable, high-impact integrations usually belong on LTS instead.
Q3
How do you test each app before the runtime upgrade, and how will we know it still works afterwards?
With good MUnit coverage and regression against real endpoints, an upgrade is routine. Without them it's risky.
Q4
Which backends get a reusable system API, and which don't? Ask how they'll decide.
API-led design earns its keep where several consumers share a backend. Three layers for every flow just adds cost.
Q5
How will you keep API policies consistent from team to team? Security will want to audit them.
Inconsistent client ID, OAuth and rate-limit policies are a common audit finding. Governance rulesets make them checkable.
01Do we have to leave Mule 4.6?
You do, and soon. 4.6 LTS is already past standard support and extended support stops in February 2027. The usual target is Mule 4.9 LTS. Most of the work is checking that custom Java and connectors still run on Java 17.
02What's the difference between Mule 4.6 and 4.9?
Mostly Java and support dates. Mule 4.6 runs on Java 8, 11 and 17. Mule 4.9 runs on Java 17 only, and Java 8 or 11 apps won't be moved to it automatically. Both are LTS releases. Extended support for 4.6 ends in February 2027, and 4.9 LTS has extended support until February 2028. Check custom Java and connector versions before you switch.
03Should our apps use the Edge or LTS channel?
It depends how often you can retest. Edge releases come up to three times a year, and on CloudHub apps get upgraded automatically six weeks after their version leaves standard support. LTS releases come each February with at least 18 months of standard support. Most enterprises put stable integrations on LTS.
04How long does a Mule runtime upgrade take?
It depends on the number of apps, custom Java components, connector versions and test coverage. Apps with good MUnit coverage move quickly. We scan every app for Java and connector issues first, then upgrade in batches by risk.
05Do we need API-led layers for every integration?
No. System APIs pay off when several consumers need the same system. A one-off file transfer doesn't need three layers. We design layers where reuse is likely and keep the rest simple.
06Our current partner runs MuleSoft support. Can you take it over from them?
Yes. First we inventory apps, runtimes, policies and pipelines, then hand you a list of fixes ranked by risk. Run support starts once we both know what we're actually supporting.
07Do you provide MuleSoft developers on contract?
We do. You can bring in certified MuleSoft developers, integration architects or platform administrators, onsite in the US or working nearshore and offshore to cover any time zone. Pick contract, contract-to-hire or permanent terms.
services
Related services
Projects on MuleSoft usually end up touching one of these, so they're worth a look.
