MuleSoft Anypoint is priced by vCore and bundles a broad platform many teams only partly use. That makes it a candidate for cost reduction, but it also makes the migration easy to get wrong. Anypoint is both an integration and ESB platform (Mule flows) and an API gateway. Kong Gateway OSS replaces the gateway, not the integration platform. Getting that boundary right is the whole game, so this guide leads with it.
Two platforms wearing one name
Before any migration planning, separate the concerns:
- API management and gateway. Publishing APIs, routing to backends, enforcing keys and OAuth, rate limiting, throttling, edge transformation, managing consumers. This is what Kong does.
- Integration and ESB. Connecting systems, transforming and enriching data across sources, orchestrating multi-step flows with connectors. This is Mule’s core, and Kong does not do it.
If you move the gateway to Kong and assume the integration logic comes along, you will be wrong and you will discover it late. The honest framing is two independent tracks that happen to share a vendor today.
What genuinely maps to Kong
The gateway layer translates cleanly. In Kong terms:
- A published API becomes a Kong service plus routes.
- API key or client enforcement becomes the key-auth or oauth2 plugin.
- Throttling and quotas become the rate-limiting plugin.
- Edge-level payload shaping becomes the request-transformer and response-transformer plugins.
- Consumer and application management becomes Kong consumers and credentials.
If a piece of your Anypoint setup is really just “front the backend, check the key, throttle, tweak headers,” it maps directly. The moment a flow is connecting and reconciling multiple systems, you have crossed out of gateway territory.
What does not map, and what to do about it
Mule flows are the part that does not become Kong plugins. Data transformation across sources, connector-based integrations, and orchestration logic live in the integration layer. You have three honest options, chosen independently of the gateway move:
- Keep Mule for integration and put Kong only in front as the gateway, shrinking but not eliminating the Anypoint footprint.
- Replatform flows onto a different integration or iPaaS tool.
- Reimplement simpler flows as services that sit behind Kong, if the logic is light enough to be a plain application.
Do not let the gateway migration set the schedule for the integration decision. They are different problems with different risk profiles.
Re-implementing the gateway in Kong
For the gateway layer specifically, the work is familiar Kong setup. Define services and routes for each API, attach auth, rate-limiting, and transformer plugins, and model consumers and their credentials. Keep the configuration declarative, in YAML applied via decK or a GitOps pipeline, or drive the Admin API, so changes are reviewed and reversible. Because Kong OSS does not bundle a developer portal or built-in analytics, plan an external or open portal generated from your OpenAPI specs and a Prometheus plus Grafana pipeline for metrics.
Watch for logic hiding at the edge
The trickiest part of scoping this move is edge logic that looks like a gateway concern but is really integration. A MuleSoft policy that only shapes headers or enforces a key is genuinely gateway work and maps to a Kong plugin. A policy that reaches into another system, enriches a payload from a second source, or branches on data pulled from elsewhere is integration wearing a gateway costume, and it does not become a Kong plugin. When you classify each API, push on anything that touches more than the single backend behind it, because that is where teams accidentally commit to reimplementing Mule flows as Kong config and then discover the gap mid-cutover.
A consumer-safe, per-API migration
The safe sequence protects client applications:
- Inventory and classify. For each API, mark which parts are gateway concerns and which are integration flows. Only the gateway concerns are in scope for Kong.
- Stand up Kong and reimplement one API’s gateway layer as a service, routes, and plugins.
- Preserve the contract. Issue or map equivalent credentials so the consumer’s auth model and endpoint behavior stay the same.
- Validate in parallel against a test hostname, comparing auth, throttling, and transforms to Anypoint.
- Shift traffic per API with DNS while the remaining APIs stay on Anypoint and Mule, then repeat.
Handle the integration flows for each API on their own track, keeping, replatforming, or reimplementing them, rather than folding them into the gateway cutover.
Confirming a clean handoff
An API is migrated when its consumers cannot tell. Check that credentials behave identically, throttling triggers at the same thresholds, edge transforms produce the expected payloads, and, crucially, that any integration logic the API depended on is still served correctly by whatever track you chose for the Mule flows. If the integration piece is not yet resolved, the API is not ready to leave Anypoint, no matter how good the Kong config looks.
Where this nets out
MuleSoft to Kong OSS is really two decisions. The gateway layer maps well to Kong services, routes, and plugins and can deliver real savings off vCore-based licensing. The integration and ESB layer is a separate concern that Kong does not replace, and pretending otherwise is the classic failure mode of this migration. Scope the gateway move confidently, scope the integration future deliberately, and model the licensing savings against both tracks in the calculator above, treating the figures as illustrative until you validate them against your own Anypoint footprint.