MuleSoft integrations that survive the next runtime upgrade.
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.
Feb 2025Mule 4.9 LTS Released February 2025 on Java 17. Standard support to August 2027, extended support to February 2028. source ↗
Oct 2026Mule 4.13 Edge Came out in October 2026 on Java 17. Standard support runs to March 2027 and extended support to June 2027. source ↗
today · Oct 22, 2026
Feb 2027aheadMule 4.6 LTS reaches end of extended support Standard support ended in August 2026. Extended support ends in February 2027. Supports Java 8, 11 and 17. source ↗
no date yetRelease channelsPatches roll out every month. Edge releases ship up to three times a year, and LTS releases land in February with at least 18 months of standard support.source ↗
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.
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.
App inventory with runtime, channel, connectors and Java 17 readiness
Upgrade plan assigning each app to LTS or Edge, ordered by risk
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.
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.
App inventory with runtime, channel, connectors and Java 17 readiness
Upgrade plan assigning each app to LTS or Edge, ordered by risk
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 on Mule 4.6 and a February 2027 deadline
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.
How MuleSoft APIs connect channels, partners and agents to core systems
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.
01 · Consumers
Web and mobile appsportals · field apps → Experience APIs · REST
These are working documents, written against your configuration, so your team can run them without us.
inventory01
App inventory with runtime, channel, connectors and Java 17 readiness
yours to keep
plan02
Upgrade plan assigning each app to LTS or Edge, ordered by risk
yours to keep
report03
MUnit coverage report with gaps closed for upgraded apps
yours to keep
code04
API policy and governance ruleset baseline across business groups
yours to keep
tests05
CI/CD pipeline templates for build, test and promotion
yours to keep
runbook06
Run support runbook with monitoring alerts and owners
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 will you test each app before and after the runtime upgrade?
With good MUnit coverage and regression against real endpoints, an upgrade is routine. Without them it's risky.
Q4
How will you decide where reusable system APIs are worth building?
API-led design earns its keep where several consumers share a backend. Three layers for every flow just adds cost.
Q5
How will API policies be kept consistent across teams?
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?
Yes, and soon. Mule 4.6 LTS lost standard support in August 2026, per MuleSoft's release table, and extended support ends in February 2027. The usual target is Mule 4.9 LTS, which has standard support to August 2027. The work is mostly Java 17 compatibility plus connector version checks.
02Should 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.
03How 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.
04Do 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.
05Can you take over MuleSoft support from another partner?
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.
06Do you provide MuleSoft developers on contract?
We do. Certified MuleSoft developers, integration architects and platform administrators can work onsite in the US or nearshore and offshore, across all time zones. Terms are contract, contract-to-hire or permanent.
services
Related services
Projects on MuleSoft usually end up touching one of these, so they're worth a look.
