API-management spend has a way of growing quietly: pricing tied to call volume or environments, per-feature add-ons for the developer portal and analytics, and platform breadth you pay for whether or not you use it. Apigee, MuleSoft Anypoint, and Kong Enterprise all sit in this space, and open gateways have matured to the point where the core job, routing, authentication, rate limiting, and transformation, is fully covered by free software. Whether your migration is a weekend or a quarter depends almost entirely on one distinction.
Gateway versus platform: the distinction that decides everything
An “API management platform” is really two things bolted together: a data-plane gateway that proxies and secures live API traffic, and a control plane of developer portal, analytics, and governance around it. Open gateways (Kong OSS, Apache APISIX, Tyk) replace the gateway cleanly, policy for policy, plugin for plugin. The control-plane pieces need open equivalents assembled separately: a portal, a metrics stack like Prometheus and Grafana, and GitOps for configuration. Knowing which of those you actually depend on tells you the real size of the job.
The distinction matters even more for MuleSoft, because Anypoint is not only an API gateway, it is an integration and ESB platform. Moving the gateway layer to Kong does not replace your Mule flows. Those are a separate concern that either stays put or moves on its own track. Treating the two as one migration is the most common way these projects go wrong.
The paths, from easiest to hardest
- Kong Enterprise to Kong OSS is the gentlest move, because Enterprise runs the same open-source core. You are really removing licensed features (RBAC, the Dev Portal, Vitals analytics) and substituting open equivalents: declarative or GitOps configuration, an external portal, and Prometheus and Grafana. If you do not lean on Enterprise-only features, it is close to a reconfiguration.
- Apigee to Kong OSS or Apache APISIX is a genuine re-implementation: each Apigee proxy becomes routes and services, and each policy (Quota, Spike Arrest, OAuthV2, transforms) maps to an equivalent plugin. The mechanical part is well understood; the effort is in the portal, analytics, and any bespoke JavaScript or Java callouts.
- MuleSoft to Kong OSS is the one to scope carefully, precisely because you must separate the gateway migration from the integration logic and handle them independently.
How the migration actually runs
The safe pattern is the same across all of these: stand up the open gateway alongside the incumbent, re-create services, routes, and policies for a first slice of APIs, put both gateways behind DNS, and cut over one API at a time while watching auth, rate-limit behavior, and latency. Keep the consumers’ contracts stable so nothing downstream notices the swap. Model the savings with the calculator on each path page, and treat the defaults as illustrative until you price your own infrastructure and support. Migrate by API, validate as you go, and retire the commercial platform only once every consumer has moved.