Apigee is a mature, full-featured API platform, and priced like one: per-call and capacity charges, add-ons for environments and analytics, and a developer portal you pay to keep. When that bill outgrows the value, the good news is that the part of Apigee most teams actually live in, the gateway that proxies and secures API traffic, is fully covered by free, production-grade software. The work is understanding what else Apigee does for you and replacing those pieces deliberately.
What you are really replacing
Apigee is a gateway plus a control plane. The gateway runs your API proxies and applies policies (Quota, Spike Arrest, OAuthV2, key verification, transformations). The control plane gives you a developer portal, analytics, and governance. An open gateway replaces the first part cleanly. The second part, portal and analytics, you assemble from open components. Inventory which of those you depend on before you start; it is the difference between a focused gateway migration and a broader platform project.
Kong OSS vs Apache APISIX
Both are open source, both use the same mental model as Apigee (a request hits a route, gets matched to a backend, and passes through a chain of policies), and both have a plugin for essentially every Apigee policy you rely on.
Kong Gateway OSS has the largest ecosystem and the most published migration guidance, and its declarative configuration (managed with decK and GitOps) fits teams that want infrastructure-as-code for their APIs. Apache APISIX is a strong alternative with a similar plugin model, an included dashboard, and an etcd-backed control plane. For most Apigee estates either is a capable landing spot; the choice usually comes down to which ecosystem and configuration style your team prefers.
Beyond the gateway
The pieces that need explicit planning are the developer portal, the analytics you got for free from Apigee, and any custom logic in JavaScript or Java callouts. Replace analytics with a Prometheus and Grafana stack, stand up an open or external portal, and re-implement callouts as plugins or upstream services. The migration itself is low-drama when done incrementally: run the open gateway alongside Apigee, move APIs one at a time behind DNS, and keep each consumer’s contract identical so nothing downstream has to change.
Consumer migration is the long pole
The gateway swap is a matter of weeks. Getting every API consumer onto it can take considerably longer, and that is the part of the schedule that slips.
The reason is API keys and credentials. Every consumer holds a key issued by Apigee, and those keys do not transfer. Either you migrate the credential store so existing keys keep working, which is possible but requires care around how secrets are hashed and stored, or every consumer has to take a new key. If your consumers are internal teams, that is a coordination problem measured in weeks. If they are external customers or partners, it is a communications programme with notice periods, documentation updates, and a support burden, and it will not be measured in weeks.
Plan it as its own workstream. Decide early whether you are migrating credentials or reissuing them, because the answer changes the timeline substantially and it is very hard to change your mind halfway. If you reissue, run both gateways accepting traffic simultaneously for a defined overlap window, publish the deadline early, and instrument which consumers are still using the old path so the final chase is targeted rather than a broadcast.
Two smaller items reliably cause trouble. Rate limits and quotas need to be reproduced exactly, because a consumer who was silently within an Apigee quota and is now being throttled will treat it as an outage. And any consumer pinning certificates or relying on specific TLS behaviour at the edge needs advance warning, since the new gateway will present a different termination point.
When Apigee is worth keeping
Apigee is expensive because it does a lot, and there are estates where the alternative genuinely costs more.
If you monetise APIs, Apigee’s billing, rate plans, and revenue reporting are substantial functionality that an open gateway does not replace. Rebuilding a metering and billing pipeline is a real product engineering effort, and it is rarely cheaper than the licence unless your volumes are large.
If your API programme is externally facing with a significant partner ecosystem, the developer portal, onboarding workflows, and self-service key management are doing organisational work as much as technical work. An open gateway plus an assembled portal can match it, and the assembly is a project with an owner rather than a configuration change.
And if the team that would operate the open gateway does not exist, the saving is theoretical. A gateway is on the critical path for every API call you serve; it needs someone who understands it well enough to debug it under pressure.
The strongest case for migrating is the common one: a large internal API estate where Apigee is functioning as a well-priced reverse proxy and little else. That is where the licence is furthest from the value delivered. Each path below opens to a full cost model, a plan, and an in-depth guide.