If you are still on Mule 3, you are running unpatched middleware. Support ended in March 2024. That makes it a security item, not a modernisation project.

More urgent than most technical debt, because it is not technical debt. MuleSoft ended extended support for Mule 3 on 20 March 2024: no bug fixes, no security patches, no new features. That means any vulnerability discovered since then stays open in a component sitting between your core systems, usually holding credentials to all of them. We would treat that as a security item with a date rather than a modernisation project competing for next year’s budget, and we would sequence the migration by exposure rather than by which application is easiest.

It helps, and it is not a one-click upgrade. The Migration Assistant produces migration reports and a partial conversion, which is a genuine head start. What it cannot do for you is the connector changes, the error-handling model, and DataWeave 1 to 2, which is where the actual effort sits. Any plan that budgets the assistant as the migration will discover the rest late, usually during testing. We estimate the rework explicitly and tell you which applications are close to mechanical and which are effectively rebuilds.

Model Context Protocol is how an AI agent reaches a system it does not natively know about, and support for it is now generally available across Anypoint Platform. API Catalog syncs MuleSoft MCP servers into Agentforce, with admins controlling which tools agents may call. The reason it matters strategically is that it makes your integration layer the thing that determines what your agents can do. An agent is only as capable as the systems it can reach, and only as safe as the boundary you put around them, and both of those are now integration decisions.

We can measure it, which is usually the missing piece. Analyst and partner commentary consistently reports organisations committing to more capacity than production actually consumes and describes the metrics as hard to forecast; we would rather present that as the commentary it is than repeat it as fact. What we do is instrument what your estate genuinely uses, identify applications that are over-provisioned or no longer called at all, and give you that evidence before a renewal rather than after. We are a consulting partner, not a reseller, so nothing in that analysis changes what we earn.

Sometimes simpler would do, and we will say so. If you have a handful of point-to-point interfaces and no plans to grow them, a platform of this weight is hard to justify on its own. MuleSoft earns its place when you have many systems, real governance requirements, reuse worth enforcing, or an agent programme that needs a controlled way to reach everything. If you already own it, the question is different: it is whether the estate is designed or accreted, and that we can answer from your own catalogue.

Yes, and it starts with an inventory rather than a rebuild proposal. Applications and their runtime versions, what is deployed where, which APIs are actually called and by whom, what error handling exists, and which flows nobody will touch because the author left. You get that as a document whether or not you continue with us. In most estates it shows a smaller number of genuinely critical interfaces than expected, surrounded by a lot that could be retired.