There is a proven, phased path off Apigee. You can move from Apigee to Tyk, with both gateways running side by side and cutover only after parity is proven against your real traffic. Your consumers keep the credentials they use today and nothing is one-way.
In addition to the information below, see our step-by-step guide on how to migrate from Apigee to Tyk.
Migrating from Apigee to Tyk
Migrating to Tyk API Gateway from Apigee involves a small set of joint working sessions. Your Apigee estate keeps serving traffic the entire time, for a smooth, seamless process. The heavy lifting is tooling-assisted with automated importers moving your consumers and credentials, and validators proving behavior before anything changes for your end users. You stay in control of the cutover date.
How to prep for moving from Apigee to Tyk Gateway
You’ll need a short prep list to ensure you scope accurately. Use a structured discovery questionnaire to create this, ensuring you cover:
- Proxies and apps: An inventory of your Apigee proxies, products, and developer apps.
- Policies: Auth, quotas/spike arrest, transformations, validations, and caching.
- Custom logic: JavaScript policies, Java callouts, and service callouts.
- Traffic profile: Your current traffic, plus a few sample requests for edge-case validation.
The migration journey to Tyk from Apigee
| Phase | What happens | What you get |
| 1. Discovery and scope | We inventory your proxies, policies, and consumers and score complexity. | A scoped, phased plan for your estate. |
| 2. Policy translation | Each Apigee policy is mapped to its Tyk equivalent. Where consumers depend on Apigee’s exact error responses, a compatibility shim keeps the same status codes and error payloads so clients keep working unchanged. | Your APIs running on Tyk with the same contract. |
| 3. Consumer and key migration | We bulk-import your existing credentials into Tyk using their original key values, mapping Apigee products to Tyk policies. | Every consumer provisioned; no re-issue, no rotation. |
| 4. Parallel validation | Tyk runs alongside Apigee. We replay and compare traffic and prove rate-limiting and policy behavior before any consumer is moved. | Proven parity, with no surprises. |
| 5. Cutover | Traffic shifts on your schedule, with request tracing on and a tested rollback ready. | Apigee retired once you’re satisfied. |
The low-risk way to move from Apigee to Tyk
Moving from Apigee to Tyk doesn’t have to be stressful or disruptive. In fact, our low-risk approach means the whole process can be simple and seamless.
- Your consumers won’t break: We import your existing Apigee consumer keys into Tyk using their original values, so applications keep authenticating with the credentials they use today. Both gateways can run in parallel throughout the migration process.
- Full feature parity: Every common Apigee policy maps to a nativeTyk capability or a lightweight plugin (see the parity table below for further details).
- Predictable effort: Discovery runs off a structured questionnaire, and most of the build sits with us. You keep Apigee serving traffic until you choose to cut over.
- Always reversible: Nothing is one-way. We validate in parallel before cutover, and credential imports can be rolled back with a tested revert tool.
Feature parity at a glance
| In Apigee | In Tyk |
| API key/OAuth2/JWT (JWKS) authentication | Native API key, OAuth2, and JWT/JWKS auth |
| Spike arrest/quota | Rate limiting plus quotas |
| Request/response transformation | Built-in middleware |
| Custom logic (JavaScript/Java callouts) | Go/Javascript/gRPC plugins |
| CORS | Native CORS |
| XML/SOAP threat and schema validation | XSD validation |
| Response caching | Response caching |
| IP allowlisting | IP access control |
| Developer portal · products · apps | Tyk Developer Portal (products → policies) |
What you walk away with
By moving from Apigee to Tyk in this way, you gain:
- Your APIs on Tyk with the same contracts your consumers already rely on.
- All consumers migrated, keeping their existing credentials.
- Parity validated against real traffic before cutover.
- Request tracing via OpenTelemetry into your existing tooling (Jaeger, Grafana Tempo, Datadog…).
- Apigee decommissioned on your timeline.
What’s out of scope?
- Backend and application business logic.
- Tyk-managed migration.
- Custom feature development.
Why teams move off Apigee
Teams move away from Apigee for a variety of technical, financial, and organizational reasons – usually because Apigee doesn’t match their current needs. Apigee can feel expensive and operationally complex, prompting teams to seek out better value for money and greater simplicity. Cloud strategy changes and a push for Kubernetes and cloud native adoption can also trigger teams to search for Apigee alternatives, as can concerns around vendor lock-in. Performance and latency requirements and a push for a superior developer experience may also prompt teams to move off Apigee onto alternatives such as Tyk.
If you’re being pushed to Apigee X
For some teams, being pushed to Apigee X may be what triggers a search for an alternative API management solution. They may feel that they’re being pushed to absorb a migration cost that doesn’t deliver obvious business value, with the move to Apigee X feeling more like a migration than a lift-and-shift upgrade. In such situations, redirecting the migration budget to an alternative solution that does deliver clear value can be preferable. The fact that Apigee X results in a tighter coupling with Google Cloud may also be a trigger for some businesses.
What migration costs and how long it takes
The cost and timescale for your migration from Apigee to Tyk depends heavily on how much Apigee functionality you’re using. For example, if you’re using Apigee primarily for OAuth, JWT validation, routing, rate limiting, and header manipulation then the migration will be simpler than if it involves shared flows, custom JavaScript policies, complex traffic management, and Key Value Maps (KVMs).
You can speak to the Tyk team to find out more about the cost of moving from Apigee to Tyk and the timescale for your particular use case.
FAQs
Can I keep my existing API keys when moving off Apigee?
Usually, yes. When you move off Apigee and onto Tyk, we bulk-import your existing credentials using their original key values. This means you shouldn’t need to re-issue or rotate due to the migration.
Can I run Apigee and Tyk at the same time during migration?
Absolutely. This is the recommended and lowest risk approach. You run Apigee and Tyk at the same time for parallel validation. The cutover only takes place once parity is proven.
Does Tyk support OAuth2, JWT and JWKS like Apigee?
Yes, Tyk supports OAuth2, JWT and JWKS. Tyk can validate JWTs issued by external identity providers and can retrieve signing keys from a JWKS endpoint. For OAuth2.0, the most common approach is for Tyk to act as the API gateway and trust tokens issued by an external IdP. Tyk can also issue OAuth tokens itself, meaning you have the option to use Tyk as the OAuth provider if you prefer.
Can the migration be rolled back?
Yes, the migration can roll back. When moving from Apigee to Tyk, traffic shifts on your schedule, with a tested rollback ready should you need it.
Book a scoping session
Considering moving off Apigee to Tyk? Then it’s time to book a scoping session. We’ll run the discovery questionnaire then provide you with a scoped, phased plan for your estate. Just drop us a line at [email protected] and we’ll get started.