Teams leave Apigee for predictable reasons: premium per-call and capacity pricing, environment and add-on costs, policy and analytics lock-in, and tight coupling to Google Cloud. Apache APISIX is an open-source gateway with a route, upstream, and plugin model close enough to Apigee’s that the concepts transfer cleanly, backed by etcd for dynamic configuration. This guide walks the translation and names the parts that need genuine rework.
The route and upstream mental model
Apigee thinks in API proxies carrying an ordered chain of policies. APISIX thinks in routes that match incoming requests, upstreams that describe the backend pool, and plugins that add behavior to a route. Reframing an Apigee proxy is mostly mechanical:
- The proxy’s public face becomes an APISIX route (host, path, methods).
- The proxy’s target endpoint becomes an upstream.
- The proxy’s policy chain becomes plugins enabled on the route.
APISIX applies these through etcd, so changes propagate dynamically rather than as a redeployed bundle. That is a meaningful operational difference from Apigee: your configuration lives in a data store you can watch and version, and updates take effect without a proxy build step.
Translating Apigee policies to APISIX plugins
The everyday Apigee policies have APISIX counterparts:
- Quota → limit-count. Fixed request ceilings per consumer or route.
- Spike Arrest → limit-req. Rate smoothing to absorb bursts.
- VerifyAPIKey → key-auth, with consumers holding credentials.
- OAuthV2 → the oauth plugin or JWT validation against an external identity provider.
- AssignMessage and JSON/XML transforms → the request and response rewrite plugins.
As with any gateway move, the hard edge is Apigee’s inline code. JavaScript, Python, or XSL callouts inside a proxy do not port; you replace them with a stock plugin where one exists, a serverless-function plugin, or logic relocated to the upstream service. Enumerate these callouts before scheduling, because they dominate the effort.
Where APISIX stops and you take over
APISIX covers the gateway thoroughly, but a few Apigee bundles are not part of it:
- The APISIX Dashboard is an operator console. It manages routes, upstreams, and plugins, but it is not the public, self-service developer portal Apigee provides. A consumer portal is generated separately from your OpenAPI specs with external tooling.
- Analytics are Prometheus-based. Rather than Apigee’s built-in reports, you scrape APISIX metrics into Prometheus and build the views you need in Grafana.
- Fine-grained admin roles are not Apigee-equivalent out of the box, so treat configuration change control as part of your GitOps or etcd management discipline.
Each of these is achievable and open, but each is a workstream to plan rather than a checkbox.
Handling config through etcd
Because APISIX is etcd-backed, promoting configuration between environments is about how you manage that store, not about packaging bundles. A common pattern is to keep the desired route, upstream, and plugin definitions in version control and apply them through a pipeline, so etcd holds the running state while Git holds the reviewed source of truth. This gives you rollback and audit without an Apigee-style deployment artifact.
Naming and grouping to keep it manageable
Apigee’s proxy-and-environment structure gives you an implicit way to organize a large estate. APISIX does not impose the same shape, so decide a convention early: how routes and upstreams are named, how you separate teams or domains, and how you promote a change from a staging etcd to production. Settling this before you migrate the second or third API saves a painful reorganization later, when hundreds of routes already exist and no two teams named theirs the same way. A thin naming standard, applied from the first API, is cheaper than retrofitting one.
Cutting over per API behind DNS
Run the two gateways together and migrate incrementally:
- Inventory each proxy: policies, consumers, callouts, portal entries, and the reports you depend on.
- Model the first API as an APISIX route and upstream, and enable the matching plugins.
- Validate in parallel against a test hostname, comparing auth, quota, spike, and transform behavior to Apigee.
- Shift traffic per API via DNS or the load balancer once behavior matches, leaving Apigee to serve the rest.
- Retire each Apigee proxy only after its APISIX replacement is proven, and export analytics history first.
The parallel run is what keeps a mistake confined to one API instead of the whole estate.
Proving an API is really migrated
For each API, confirm the essentials before you trust it: valid credentials are accepted and invalid ones rejected, limit-count and limit-req trigger at the thresholds Apigee enforced, request and response rewrites yield the exact payloads consumers expect, and your Grafana dashboards show the freshly moved traffic. The bar is that consumers notice nothing and you can see the API in the new observability stack.
Reading the trade
Apigee to APISIX suits teams who want an open gateway with a familiar route and plugin model, are ready to run etcd, and accept that the developer portal and analytics become open components you assemble. The policy-to-plugin translation is direct for the common cases and hand-built for inline callouts. Weigh the per-call and capacity savings against the effort to rebuild the portal and metrics pipeline in the calculator above, and keep those numbers illustrative until you check them against your real proxy set.