Migrate from Tyk to Apache APISIX without losing keys, limits or middleware
A team running Tyk Gateway that wants to move to Apache APISIX should expect the work to be mostly mapping: API definitions become routes and services, keys and policies become consumers and limits, and the custom middleware is the largest unknown. The two products model these things differently, and no fully automatic importer from Tyk to APISIX is documented, so each definition, key population and policy has to be designed and verified by hand. Start by confirming the exact Tyk Gateway version and the APISIX version in scope, because both change which features and plugin behavior you can rely on. Tyk's open source gateway is licensed under the Mozilla Public License 2.0, and the ee folder falls under a separate commercial license, so check which edition and modules your estate actually runs before you plan the mapping.
The effort is driven by a handful of factors you can inventory early: how many APIs and versions Tyk serves, how many keys are issued and how they are tied to policies, whether rate limits and quotas are shared across gateway nodes through Redis, how many Go, Python or JavaScript middleware plugins exist and what they call, and how many clients depend on Tyk-specific behavior such as per-version or per-operation access control. Each custom middleware plugin needs an APISIX equivalent, which may be a built-in plugin, a configuration pattern, or an external plugin runner, and that choice is usually the one that moves the schedule. Ask any partner to price the mapping and the middleware separately, and to state which items they assume will be rebuilt rather than ported.
Ask for a written inventory and a parallel-running plan before any cutover date is fixed. Parallel running means both gateways serve the same APIs behind a traffic split, with keys and limits checked on each side and a rollback path that returns traffic to Tyk without client changes. Confirm early whether your limits depend on shared counters, because APISIX's limit-count plugin keeps counters in local memory by default and can share them through Redis, and that choice affects how the two gateways behave during the overlap.
Which Tyk features map to APISIX and which need redesign
This table compares Tyk Gateway features with their closest Apache APISIX equivalents and marks where a mapping is direct, partial or absent. Read each row as a starting point for your inventory: confirm the behavior in your own environment before you commit to a design, and treat rows marked as needing redesign as decisions to make before the build starts.
| Tyk feature | APISIX equivalent | Reader decision or check |
|---|---|---|
| API definitions and listen paths | Routes and services with upstreams, matched on URI, host and methods | Map each listen path and version to a route. Confirm matching order and any path rewrites you rely on. |
| Keys and access tokens | Consumers with key-auth, jwt-auth, basic-auth or hmac-auth credentials | Decide how consumer identities are named and who issues credentials. Existing key hashes may not transfer directly. |
| JWT and Basic Auth | jwt-auth and basic-auth plugins, bound to consumers | Confirm claim mapping and signing key handling. Plan how Tyk policy claims become APISIX consumer or header logic. |
| Client certificates | TLS client verification on the gateway listener, plus a consumer or plugin check if identity is needed | Confirm certificate trust chain, revocation approach and how identity is derived from the certificate. |
| Rate limits and quotas | limit-count plugin, with local memory or a shared redis, redis-cluster or redis-sentinel backend | Quotas are not a one-to-one match. Confirm period semantics, shared counter groups and the 503 rejection behavior you need. |
| Per-version and per-operation access control | Separate routes per version, with plugin or consumer rules for operations | Confirm this design against your operation list. Tyk operation-level rules may need to be rebuilt as route definitions. |
| IP allowlisting | ip-restriction plugin | Direct in most cases. Confirm how client IPs are read behind load balancers and which header is trusted. |
| Go, Python and JavaScript middleware | Plugin runners for Java, Go and Python, Lua plugins, or WebAssembly. JavaScript runner is outside the Apache organization | Middleware must be rewritten for the target runtime. Decide which language to keep and confirm runner support for your code. |
| Dashboard-managed policies | No direct equivalent in the gateway. Policies become consumer, route or plugin configuration managed as code or through the Admin API | Decide who owns policy changes, how they are reviewed and where the source of truth lives. |
| Developer Portal | Not part of APISIX. Requires a separate portal or catalog product | Decide which tool will handle sign-up, key issuance and documentation before cutover. |
| Tyk Operator resources | APISIX Ingress Controller custom resources if running on Kubernetes, or the Admin API and configuration files | Plan a translation of Operator manifests. Confirm the resource types you use before estimating the rework. |
Documented import paths, APIs and exports
No documented one-step Tyk-to-APISIX importer was confirmed for this page, so the move is usually scripted against each platform's API and file formats. The cards below cover the APISIX interfaces you will write to, the Tyk exports you will read from, and the checks to run before assuming any tool does the conversion for you.
APISIX Admin API in traditional mode
In traditional deployment mode, APISIX serves client traffic on port 9080 and exposes the Admin API on port 9180. Your conversion script will create upstreams, services, routes and consumers through this API, so the first decision is where it runs and who can reach it. Restrict port 9180 to the automation host and confirm the Admin API key handling in your environment before any bulk write. Test the write path against a non-production etcd cluster first.
Standalone configuration files
In standalone mode, APISIX reads its configuration from conf/apisix.yaml or conf/apisix.json and hot-reloads changes without a restart. A script can generate that file from your Tyk inventory and keep it in Git, which suits teams that want reviewable diffs and no etcd dependency. Confirm which format your APISIX version expects and validate the generated file in a staging instance before it becomes the source of truth.
APISIX Ingress Controller for Kubernetes
If Tyk runs on Kubernetes, the APISIX Ingress Controller is a separate project that lets APISIX handle ingress. Decide whether your migrated routes will be expressed as Kubernetes resources, which affects how the Tyk Operator's declarative objects map across. Check the controller version against your cluster and gateway plan before building manifests, since the controller follows its own release cycle.
Tyk API definitions as JSON
Tyk stores each API definition as JSON, and the open source gateway can expose its loaded definitions through the Tyk Gateway API. Your inventory script should export these definitions and record auth mode, version blocks, rate limits and middleware references for each API. Treat the export as the source of truth for the migration and keep a dated copy, because the Gateway API reflects only what the running gateway has loaded.
Confirm the importer before relying on it
A documented Tyk-to-APISIX importer was not confirmed for this page. Ask Apache APISIX maintainers, API7.ai and Tyk directly whether any official or community tool converts Tyk definitions, and inspect any candidate tool's source and license before using it on production definitions. Assume the conversion is custom work until a vendor confirms otherwise, and budget testing time accordingly.
Keys and policies outside the definitions
API definitions do not carry every credential or quota. Tyk keys, policies and their rate and quota settings may live in the gateway's Redis store or in the Dashboard, so an export of API definitions alone will miss consumers and limits. Confirm with your Tyk deployment how keys and policies are stored and exported, and plan a separate extraction step that maps them to APISIX consumers and limit-count settings.
How Tyk API definitions become APISIX routes, services and consumers
The core mapping is straightforward in principle: each Tyk API definition becomes an APISIX route that carries the listen path and matching rules, with an upstream object that holds the backend target. When several routes share the same backend settings or plugin set, group them under an APISIX service so those settings are declared once. Version settings in Tyk need a deliberate decision. Tyk can serve several versions from one definition, while APISIX usually expresses versions as separate routes, often distinguished by path or header matching. Inventory every definition with its version and listen path before writing any route, and confirm with your team how each versioned path will be matched in APISIX. Check the exact matching and upstream fields against the current Apache APISIX documentation rather than assuming a field name carries over.
Keys are the second mapping. A Tyk key tied to a policy becomes an APISIX consumer, identified by a username, with a credential attached through an authentication plugin such as key-auth or jwt-auth. Plugin precedence matters here because APISIX resolves plugin configuration in the order Consumer, then Route, then Plugin Config, then Service. If a limit is set on the consumer and another is set on the route, the consumer setting applies first, so an overlap can silently change which policy a caller meets. Map each Tyk policy to exactly one place in APISIX and write down the expected winner for every combination you intend to keep. Confirm with your security team which consumers may hold broader access than others before you cut over.
Rate limits and quotas must be rebuilt with the limit-count plugin, because Tyk policy limits do not transfer automatically. By default, counters live in local memory on each APISIX node, so a caller can get a separate allowance per node unless you configure shared storage such as Redis. Routes that set the same group share one counter, which is how you reproduce a policy that spans several APIs. Rejected requests return status 503 by default, which may differ from what your clients expect from Tyk, so set the rejection code explicitly if clients depend on a specific response. Test limits under load in the parallel environment, and confirm your sliding window needs (APISIX 3.18.0 or later for that option) before you design around it.
Run Tyk and APISIX in parallel, then cut over in stages
This sequence moves Tyk traffic to APISIX one API group at a time, with each group proven side by side before its cutover and Tyk kept ready for rollback until the last group has run cleanly. The cutover order and rollback trigger are agreed in the written scope before work starts.
Inventory every API, key, policy and middleware
Your team and ours list every API definition, version, key, quota, rate limit, access control rule, IP allowlist and custom middleware in the Tyk estate, including which Tyk Dashboard or Operator objects define them. Each item is tagged with its owner, its consumers and whether it is in production. The inventory is complete when every Tyk API has a mapping target (route, service, consumer or plugin) and the open questions are assigned to named owners.
Build a pilot APISIX environment
We stand up an APISIX environment on infrastructure you control, choosing the deployment mode and etcd layout that fit your network and operating model. The Admin API is restricted to administrators, and the environment is wired to your identity, logging and metrics systems so it can be observed from day one. The pilot is ready when a test route returns traffic through the gateway and the configuration can be reproduced from source control.
Port one low-risk API with its consumers
We choose one low-traffic API with a small set of consumers, then translate its definition into APISIX routes and services and its keys and policies into consumers and limits. Authentication is rebuilt with the matching plugin, and any Go or Python middleware is moved to an external plugin runner or rewritten as a plugin. The step closes when a consumer's real request succeeds through APISIX with the same response as Tyk, verified in a test run your team signs off.
Run both gateways side by side
Traffic is either mirrored to APISIX or split between Tyk and APISIX at a load balancer or DNS layer, as agreed in the scope. Each response is compared for status code, headers and body, and rate limit counters are checked against the Tyk quotas, including whether shared counters need Redis. The step ends when the comparison shows no unexplained differences over the agreed observation period.
Compare logs, limits and failure behavior
Access logs, error rates, latency and authentication failures are compared between the two gateways, and each limit is tested with requests above its threshold. Rejected requests are checked against the status code your consumers expect, since APISIX returns 503 by default for limit-count rejections unless configured otherwise. The step is complete when your operations team accepts the dashboards and alerts that will cover APISIX in production.
Move API groups one at a time
Each remaining API group is moved in the order agreed in the scope, starting with lower-risk groups and ending with those that carry the most consumers or the most sensitive data. For each group, traffic is shifted in stages with a defined check before every increase, and the consumers are told which hostnames or credentials change. The group is done when all of its traffic runs on APISIX for an agreed period without a rollback trigger being met.
Keep Tyk ready for rollback
Tyk configuration, keys and the Redis data it depends on are kept intact and deployable while any group still has a rollback path. Rollback steps are written down per group, including how to shift traffic back and who approves it, and the rollback trigger is the one defined in the written scope. The step produces a tested rollback runbook and a record that Tyk can serve each group again.
Decommission Tyk last
Once every API group has run on APISIX through the agreed period, Tyk is shut down last, after its logs, analytics and configuration are archived under your retention rules. Licensed Tyk components such as the Dashboard, Developer Portal or Operator are removed according to your license terms, and the final state is documented in source control. The step closes with a signed-off decommission record and a list of any residual items for your team to own.
What drives the cost and duration of a Tyk to APISIX move
This table lists the inputs that change the size of a Tyk to APISIX move, which costs are paid once and which recur, and what to request in a written quote. Use it to compare your inventory against the drivers and to see where a partner's scope and your own team's effort will differ.
| Driver | Why it changes cost or effort | What to confirm or ask for in a quote |
|---|---|---|
| Number of APIs and versions | Each API definition, and each Tyk version or path variant, needs its own mapping to routes, services and upstreams, plus tests for each. | A count of API definitions and versioned variants, with the agreed grouping for migration waves. |
| Keys, tokens and policies | Each Tyk key or access policy must map to an APISIX consumer credential and rate limit, and existing client credentials may need reissue or a transition period. | How many keys and policies exist, whether clients can keep their credentials, and who handles reissue. |
| Custom middleware by language | Go and Python middleware run through APISIX external plugin runners, and JavaScript plugins need a runner outside the Apache organization, so each language adds build, test and runtime work. | The count of custom plugins per language, their dependencies, and whether they call external systems. |
| Shared rate-limit state | The APISIX limit-count plugin counts in local memory by default, so shared limits across gateway nodes need redis, redis-cluster or redis-sentinel and extra design and testing. | Whether limits must be shared across nodes, and which Redis topology the client already runs. |
| Identity providers and client certificates | Each identity provider, JWT issuer or client certificate trust chain needs its own configuration and validation tests during parallel running. | The number of identity providers, certificate authorities and mutual TLS clients in scope. |
| Tyk deployment model | Open source Tyk, Self-Managed with Dashboard and Developer Portal, Tyk Cloud and the Tyk Operator each hold configuration in different places, so export and inventory methods differ. | Which Tyk components are running, where configuration lives, and whether the Dashboard or Portal must be replaced or kept. |
| Environments and cutover windows | Each environment needs its own APISIX deployment, data checks and parallel run, and each traffic switch needs an agreed window and rollback step. | Number of environments, number of cutover windows, and the rollback criteria agreed before go-live. |
| One-time work | Inventory, mapping, plugin rewrites, testing, parallel running and cutover are paid once per migration wave. | A fixed-scope quote listing each activity, deliverable and acceptance test separately. |
| Recurring work | Running APISIX, its etcd or standalone configuration store, upgrades, monitoring and any retained Tyk license cost continue after cutover. | Who operates APISIX after go-live, the upgrade approach, and whether any Tyk component or license stays in place. |
Porting Go and Python middleware to APISIX plugin runners
Tyk middleware written in Go or Python does not move across unchanged. APISIX offers external plugin runners for Java, Go and Python, with a JavaScript runner maintained outside the Apache organization, so the first decision is which runner matches the language your team can support after the migration. APISIX starts the runner as a subprocess and calls it over a Unix socket for the routes that reference it, so the middleware logic has to be rewritten against the APISIX plugin interface rather than lifted from Tyk's middleware hooks. Confirm the runner's current interface, supported language versions and configuration keys against the external plugin documentation before estimating the rewrite.
Each Tyk plugin should be classified before any code is written. Some logic, such as header injection, simple request validation or key checks, maps to built-in APISIX plugins and needs no runner at all. Logic that calls out to internal services or applies custom business rules is a candidate for a runner, and Lua or WebAssembly are the other extension options to weigh for lightweight logic. Tyk plugins may also depend on Tyk request and session objects, such as session state, key metadata or per-API context, that have no one-to-one equivalent in APISIX. Those dependencies must be replaced with values from consumers, plugin metadata, variables or upstream services, and the team should list them explicitly during discovery.
A runner sits in the request path, so its latency and failure behavior determine the production risk. Load test each migrated route with the runner enabled and with the equivalent Tyk middleware still running, and record the added latency at the traffic levels you expect at peak. Test what happens when the runner process crashes, hangs or is restarted, including whether affected requests fail closed or open and how quickly the gateway recovers. Ask your team to confirm the runner's restart behavior and any concurrency limits in the version you deploy, and keep those tests in the cutover plan so the parallel run covers the failure modes, not only the happy path.
Where Tyk to APISIX moves usually go wrong
Most failed gateway moves fail on details that looked equivalent during planning: counters, credentials, silent behavior changes and untested fallbacks. Each card below names one risk, the reason it matters in a Tyk to APISIX move, and the prevention step to build into the plan before traffic moves.
Rate limit counters diverge between nodes
The limit-count plugin keeps counters in local memory by default, so each APISIX node counts requests on its own. A client spread across nodes can exceed a limit that Tyk enforced globally, and counters reset when a node restarts. Before cutover, decide whether counters must be shared through Redis, Redis Cluster or Redis Sentinel, and test a limit with requests spread across every node. Routes that should share a quota need the same group name.
Keys re-issued in a different format
Tyk stores API keys and their policies in its own records, and APISIX identifies callers through consumers and credentials such as key-auth or jwt-auth. If keys are regenerated instead of mapped, existing clients fail at cutover, and any hashing or formatting change breaks them silently. Export the existing key set, map each key to a consumer with its original value, and verify that a sample of production keys authenticates on APISIX before any client is moved.
Middleware behavior changes silently
Tyk plugins written in Python, JavaScript or Go run in a middleware chain with its own ordering and request context. APISIX runs external plugin runners for Java, Go and Python as subprocesses, and plugin precedence follows Consumer, Route, Plugin Config, then Service. A header rewrite or auth check that ran in one order in Tyk can run in another in APISIX. Document each middleware step, rebuild the order explicitly and compare responses on identical test requests.
OpenAPI validation not carried over
Tyk's native OpenAPI support can reject requests that do not match a definition before they reach the upstream. That check is part of the API contract, and it does not move automatically when routes are recreated in APISIX. Identify which APIs depend on request validation, choose the APISIX plugin or upstream control that replaces it, and confirm that malformed requests are rejected in staging with the same status codes clients expect.
Admin API exposed on port 9180
In traditional mode, APISIX serves client traffic on port 9080 and its Admin API on port 9180. Teams migrating from Tyk often publish the whole host or load balancer pool, which exposes the configuration interface to clients or to networks that should only reach the Tyk equivalent of the dashboard. Bind the Admin API to a management network only, restrict access to automation and administrators, and confirm that port 9180 is unreachable from the public network before go-live.
Rollback paths never rehearsed
A parallel run only protects the business if traffic can return to Tyk within a time the owners agreed in advance. Many teams write a rollback step but never run it, then discover that DNS caches, keys created during the run or Redis counter state make the return unsafe. Rehearse a full switch back to Tyk in staging, decide which writes happen on both gateways during the parallel run, and record the rollback owner and trigger conditions in the cutover plan.
Questions teams ask before moving from Tyk to APISIX
What does moving from Tyk to APISIX cost?
The cost is the labor to inventory, translate, test and cut over your APIs, plus the infrastructure to run APISIX and its dependencies. Nothing in the supplied facts gives a price for either, so the figure depends on your scope. The main drivers are the number of APIs and versions, how many Tyk policies, keys and middleware plugins must be recreated, whether you use Go, Python or JavaScript middleware that needs a plugin runner or a Lua or Java rewrite, and whether rate limits must share counters across nodes. Ask for a quote built from a written scope that lists each of these items. Separate one-time migration work from recurring costs such as upgrades, support and hosting. Note that the Tyk Self-Managed platform and the Tyk Operator require a license, so a Tyk renewal may be part of the baseline you compare against.
How long does a Tyk to APISIX migration take?
Duration depends on how many APIs you move, how well they are documented and how much policy logic must be rebuilt. Work typically moves group by group, so the number of API groups and the test coverage for each group set the pace more than the raw count of routes. Plan time for the parallel run, where both gateways serve traffic and results are compared, and for the rollback rehearsal. Ask any partner for a timeline tied to a written scope, and confirm with your own team which API owners are available during the window. The supplied facts do not give a duration, so treat any number you see without a stated scope with caution.
What must our team provide before the migration starts?
The migration needs more from your side than from the gateway. Expect to provide:
- An inventory of API definitions, versions, upstreams and the access rules attached to each one
- A named owner for each API who can confirm expected behavior and sign off on cutover
- Representative test traffic, including error paths, so behavior can be compared during the parallel run
- Access to the identity provider, key and policy data, and the Redis instance that Tyk uses for counters
- Access to the target environments, certificates and the change windows you allow
Agree these inputs in the written scope so that gaps are visible before work begins.
Can our internal team do the migration alone?
A capable platform team can migrate a small set of APIs alone if it has time to learn APISIX's route, consumer and plugin model and can run tests against each API. The work becomes harder when you have many versioned APIs, custom Go, Python or JavaScript middleware, or rate limits that must match Tyk behavior exactly. A partner is most useful for the inventory and mapping step, for building the plugin runner or custom plugin work, for the parallel run design and for the rollback plan. DeployOpen implements, customizes, integrates and hardens self-hosted open-source platforms in your own infrastructure, and most engagements are fixed-scope with agreed deliverables. Decide the split by listing each task and who will own it.
Can APISIX and Tyk run side by side during the move?
Yes, the usual approach is to run both gateways during the move and shift traffic per API group. APISIX can serve a route while Tyk keeps serving the others, and you can compare responses from both before switching clients. Two details need planning. First, rate limits do not carry over automatically, so decide whether each gateway keeps its own counters or shares a counter store, and test the behavior. The APISIX limit-count plugin can keep counters in memory or share them through Redis, Redis Cluster or Redis Sentinel. Second, keys and tokens must be valid on both sides or clients must be re-issued credentials at a set point. Confirm the exact coexistence design with your Tyk and APISIX versions before cutover.
Is there an automatic importer from Tyk to APISIX?
The supplied sources do not describe an official Tyk to APISIX importer, so do not plan around one until you have confirmed it with the APISIX project and Tyk. Assume the mapping is manual or scripted. The main translations are API definitions to APISIX routes and services, keys and policies to consumers and limits, and Go, Python or JavaScript middleware to plugins or external plugin runners. The APISIX external plugin mechanism runs Java, Go and Python runners as subprocesses that communicate over a Unix socket. Ask any partner to show a sample of your API definitions translated, and verify the output in a test environment before relying on it.
Which Tyk features need a different home in APISIX?
Several Tyk features are handled by other components rather than by the gateway alone. Tyk Dashboard, the Developer Portal and Tyk Operator are part of the commercial Tyk platform, so you need to decide what replaces portal, analytics and declarative management functions. APISIX provides its own Admin API and Ingress Controller for configuration, and its openid-connect plugin works with providers such as Keycloak, Okta and Microsoft Entra ID for identity. Check each Tyk feature in use, including quotas, versioning, IP allowlists and hitless reloads, and confirm the APISIX equivalent or the alternative you will run before the scope is signed.
How DeployOpen scopes and delivers a Tyk to APISIX migration
DeployOpen treats a Tyk to APISIX move as a staged change to live API traffic. We map each Tyk API definition, key, policy and middleware component to its APISIX equivalent, then run both gateways in parallel until your team is satisfied with the results. Work is delivered inside infrastructure you control, under a written scope.
How we scope
- Inventory of Tyk API definitions, versions, keys, policies, quotas and middleware in your environment
- Written mapping of each API to APISIX routes, services, consumers and plugins
- Decisions on plugin runner languages for existing Go or Python middleware, agreed before build starts
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before work begins
How we build
- Deploy APISIX in the deployment mode your architecture requires, inside your cloud or data centers
- Recreate authentication, consumer and rate limit behavior, then test each route against Tyk responses
- Port custom middleware to plugins or external runners and verify behavior with replayed traffic
- Configure parallel running with traffic splitting so both gateways serve the same APIs during validation
How we hand over
- Documented route and consumer inventory, with a record of every Tyk-to-APISIX mapping decision
- Tested rollback procedure that returns each API group to Tyk within a defined change window
- Runbooks for APISIX configuration changes, plugin updates and Admin API access control
- Knowledge transfer sessions for your platform and security engineers on the delivered configuration
How we support
- Post-cutover review of logs, errors and latency against the agreed acceptance criteria
- Ongoing support, upgrades and continuous testing are available as a retainer after handover
- Retainer scope can cover APISIX version upgrades and changes to plugins and routes over time
- Ask for a quote that separates one-time migration work from recurring support effort
