Are you ready to migrate from Kong to Tyk? There are plenty of reasons to do so – as you can see with this full feature breakdown.
If you’re looking for support for all API types and hugely flexible deployment options, then migrating from Kong to Tyk makes a lot of sense. You’ll enjoy far greater flexibility in terms of pricing, deployment options, federation and more with Tyk’s composable, multi-cloud, vendor agnostic API management solution.
Choosing Tyk also means choosing robust governance, so your enterprise can enjoy the API security, reliability and performance you’ve always wanted. Add in Tyk’s stellar customer support and you’ve got a whole bunch of reasons to migrate from Kong to Tyk.
Ready? Then here’s our complete guide to how to do it…
Migrating from Kong to Tyk
We’ll provide three approaches to migration below: a GUI-based migration, a CLI-based one and an approach that uses an automation script.
Before we dive into the details of these methods, it’s important to note that migrating from Kong to Tyk involves translating and transferring API configurations. Why? Well, translation is necessary due to differences in data models and object structures. Kong doesn’t offer an out-of-the-box feature to export API configurations in a common format such as the OpenAPI Specification (OAS). That means you’ll need to either manually copy things or use scripting to bridge the data between the systems.
Key considerations
To aid a smooth migration, bear in mind the following key points:
- Data mapping: Kong uses a larger number of objects with fewer fields compared to Tyk. This makes object mapping between the two slightly complex. Key mappings include API Product to API Definition, Gateway Service fields to Target URL, and Route Paths to Listen Paths.
- Routes and paths handling: Kong Routes can bind to specific Hosts, Methods, and Headers. Tyk handles Hosts via Custom Domains. However, other bindings may not be directly compatible.
- Multi-route and multi-path handling: Routes in Kong can have multiple paths. Tyk has a singular Paths field. We can address these differences by combining paths into regular expressions.
Note that this guide focuses on migrating APIs using Kong Konnect, Kong’s SaaS control plane. You can adapt the process for on-premises Kong deployments, if required.
Flexible migration approaches
As we mentioned above, there are three options when it comes to how to migrate from Kong to Tyk, so you can choose the approach that suits you best.
A GUI-based migration involves manually copying data using the Kong Konnect user interface into the Tyk Dashboard. Steps include copying API Product Name, Gateway Service Endpoint, Route Paths, and verifying the API in Tyk.
A CLI-based migration uses CLI tools ( deck , jq , curl ) to automate the extraction and transformation of API data from Kong to Tyk. Key steps include exporting data from Kong Konnect, transforming to OAS, splitting data into individual files, importing into Tyk, and testing the APIs.
Finally, you can use an automation script for your migration. This automates the entire migration process, ensuring efficiency and reducing manual intervention. The script handles service exports, transformation to OAS, and imports into Tyk, avoiding duplicate entries.
Successfully migrating from Kong to Tyk results in your APIs being available in the Tyk Dashboard and accessible via the Tyk Gateway. This ensures a seamless transition, with minimal disruption to service operations.
Below, we explore the three approaches to migration, providing a clear, repeatable method to migrate APIs, no matter whether you prefer manual and automated migration scenarios. But first, a quick word on data mapping…
Data mapping considerations
Keep in mind that, compared to Tyk, Kong uses more objects to configure APIs. These objects are simpler, with fewer fields than Tyk equivalents. The following diagram shows how Kong objects relate to each other and their corresponding fields in Tyk:
As you can see, this diagram offers a basic overview, displaying the minimum configuration needed to migrate an API from Kong to Tyk. Clearly, a full migration could include many other objects, fields and mappings!
If you want to make the mapping simpler, one option is to use the Name from the Gateway Service instead of from the API Product. This is handy because it reduces the number of mapped entities from three to two (as the API Product is no longer needed). However, the Gateway Service name is restricted in terms of the characters it can contain, so this may not be entirely suitable.
Keep this handy summary of basic mappings to hand to aid your migration:
| Kong | Tyk | ||
| Source Object | Source Field | Target Object | Target Field |
| API Product | Product Name | API Definition | Name |
| Gateway Service | Protocol | API Definition | Target URL |
| Gateway Service | Host | ||
| Gateway Service | Port | ||
| Gateway Service | Path | ||
| Route | Paths | API Definition | Listen Path |
Kong to Tyk migration challenges
For a smoother overall experience, keep in mind that there are many differences in the Kong and Tyk data models. In particular, please note:
Path Field in Kong: The Path field in Kong’s Gateway Service object is optional and can be empty. In Tyk, the equivalent component of the Target URL can also be empty, so this doesn’t impact migration.
Paths in Routes: Kong’s Paths field in the Route object can have multiple values, while Tyk’s Listen Path has a single value. This fundamental difference can be addressed by combining paths into a single regular expression (e.g. /apple|banana|cherry/ ).
Route Bindings: Kong Routes can bind to specific Hosts, Methods, Headers and SNI. Hosts can be handled using Tyk Custom Domains, but other bindings generally don’t match in Tyk.
Right, let’s get into the detail of the three migration approaches you can take when moving from Kong to Tyk.
The GUI-based migration approach
If you want to manually transfer data from Kong Konnect into the Tyk Dashboard, here’s how to do it.
Step 1: Navigate to the API Product edit page in Kong, copy the Product Name and paste it into the Name field in Tyk’s API Definition.
Step 2: Navigate to the Gateway Service edit page linked to the API Product, copy the Protocol, Host, Path and Port and paste them into the Target URL field in Tyk’s API Definition.
Note that the endpoint parts need to be combined into a valid URL, with the necessary colons and slashes e.g. http://httpbin.org . Also, in this example, the target port ( 80 ) is not needed, as it’s the default HTTP port.
Step 3: Go to the Route edit page linked to the Gateway Service, copy the Path value and paste it into the Listen Path field in Tyk’s API Definition.
Step 4: Once you’ve copied all necessary data, save the API in Tyk and verify it through the Tyk Dashboard. The API will also be accessible via the Tyk Gateway through the listen path.
The CLI-based migration approach
If you want to use CLI-based tools to automate migration from Kong Konnect to Tyk, this is how you can do so. We’ll be using curl , xargs and find, which are typically pre-installed on most systems, along with deck (a Kong CLI tool, to export APIs from Kong Konnect) and jq (a JSON parsing tool, to prepare data for import).
You’ll need the following before starting the migration:
- Kong personal access token: Token used for Deck commands. If you’re unfamiliar with this process, refer to Kong’s documentation for assistance.
- Kong Konnect address: The region from which data will be exported. This example will use
https://us.api.konghq.com. The correct region must be used, as data is partitioned across regions. - Kong Konnect control plane name: The control plane from which data will be exported. This example will use
default. - Tyk Dashboard URL: The control plane to which data will be imported.
- Tyk Dashboard access token: Required for authentication with the Tyk Dashboard API.
Remember to use appropriate values for your environment. The example commands shown here use environment-specific values, so you’ll need to update them to match your environment before you use them. With that in mind, it’s time to get started…
Step 1: Use the deck gateway dump command to export the Kong Services and Routes to a file: kong-dump.json .
deck \ --konnect-addr "https://us.api.konghq.com" \ --konnect-control-plane-name "default" \ --konnect-token "kpat_klX1DFVtuekdOSqxGybapLacZF1Lw7F02k9ucnjaYcVlzHfjB" \ --format json \ -o kong-dump.json \ gateway dump
Step 2: Transform Kong’s exported data into OAS format using jq . This creates a kong-oas.json file containing basic OAS representations of the Kong Services and Routes in the kong-dump.json file.
Note the following caveats, both of which are for simplicity but could be addressed, if needed:
- Only one route is assigned from each service. If a service contains multiple routes then only the first will be used.
- The
.portis not used in forming the upstream URL, so port80will be used.
jq -c '[
.services[] | {
"info": {
"title": .name,
"version": "1.0.0"
},
"openapi": "3.0.3",
"paths": {},
"x-tyk-api-gateway": {
"info": {
"name": .name,
"state": {
"active": true,
"internal": false
}
},
"server": {
"listenPath": {
"strip": true,
"value": .routes[0].paths[0]
}
},
"upstream": {
"url": (.protocol + "://" + .host + .path)
}
}
}
]' kong-dump.json > kong-oas.json
Step 3: Split the OAS data into individual files for each service, enabling each to import into Tyk separately. The service name is used to generate the file name, prefixed with oas- . Kong service names are unique and file system-friendly, so are well-suited for this usage.
jq -r '.[].info.title' kong-oas.json | xargs -I {} \
sh -c 'jq -c ".[] | select(.info.title == \"{}\")" kong-oas.json > oas-{}.json'
Step 4: Import OAS documents into Tyk via curl, which will import each OAS document separately.
find . -name "oas-*.json" | xargs -I {} \
curl -X POST "http://tyk-dashboard.localhost:3000/api/apis/oas" \
-H "Authorization: a9be929ff3134924720a3553d301a657" \
-H "Content-Type: application/json" \
--data @{}
Step 5: Validate the APIs by accessing them via the Tyk Gateway. This command attempts to access the /get endpoint of the HTTPbin service listening on /httpbin :
curl http://tyk-gateway.localhost:8080/httpbin/get
A successful response returns JSON similar to this:
{
"args": {},
"headers": {
"Accept": "*/*",
"Accept-Encoding": "gzip",
"Host": "httpbin.org",
"User-Agent": "curl/8.7.1",
"X-Amzn-Trace-Id": "Root=1-67868912-68eaaae8411e71d41ea64db0"
},
"origin": "172.18.0.1, 213.55.240.253",
"url": "http://httpbin.org/get"
}
The automation script migration approach
There are plenty of benefits to automation, including speed, efficiency and reduced margin for error. If you want to automate data migration from Kong to Tyk by using a script, check out this example script on Tyk’s GitHub – be sure to read the GitHub page in full before you start.
The script automates the process of exporting APIs from Kong and importing them into Tyk. To do this, it follows a similar process to the manual steps outlined above.
The script migrates all Services from the specified Kong Konnect host and control plane. Note that API Products are not included in the migration, as they are not supported by the Deck CLI tool.
To use the script, provide connection details for the Kong source and Tyk target. These are provided as five arguments:
- Kong Konnect URL:
--konnect-addr - Kong Konnect control plane name:
--konnect-control-plane - Kong Konnect access token:
--konnect-token - Tyk Dashboard URL:
--tyk-url - Tyk Dashboard API access token:
--tyk-token
Take a look at this example command:
./migrate-kong-to-tyk.sh \ --konnect-addr https://us.api.konghq.com \ --konnect-control-plane default \ --konnect-token kpat_klX1DFVtuekdOSqxGybasLbcZF1Lw7F02k9ucnuaYcVlzHfjB \ --tyk-url http://tyk-dashboard.localhost:3000 \ --tyk-token a9be929ff3134924720a3553d301a657
Note that the script will skip any APIs that already exist in the target system, ensuring a clean migration.
As the script runs, it provides updates about the migration process. Once complete, you can review the migrated APIs via the Tyk Dashboard and validate their functionality via the Tyk Gateway.
Enjoy the full benefits of API management with Tyk
Tyk doesn’t come with a steep learning curve or lock you into only using certain vendors or tools. Our API management solution is all about flexibility and customizability, along with the security, observability and governance your enterprise deserves. Whether you’re working with REST, SOAP, GraphQL, WebSockets, TCP, gRPC or async APIs, Tyk’s powerful, lightweight solution empowers you to get the most from your ecosystem.
If you haven’t already done so, you can trial Tyk’s full features for free (no credit card required) or speak to our expert team to find out more.
