How to migrate from Amazon API Gateway to Kong Gateway without losing control of traffic
Moving from Amazon API Gateway to self-hosted Kong Gateway is feasible, and it is mainly a rebuild of routing and policy logic rather than a data migration. Teams usually start this work because of a renewal, per-call charges that grow with traffic, a data residency requirement, or concern about depending on one cloud provider's gateway. The work is typically led by a platform or API team, often with an implementation partner, and its size depends on how many stages, custom authorizers, usage plans and backend integrations the existing estate contains. Each API stage has to be mapped to Kong services and routes, and each authorizer and throttling rule has to be re-expressed with Kong plugins. The core deliverable is a Kong configuration that reproduces the behavior of every stage, kept in version control. The Kong Gateway open-source edition runs in DB-less mode, where declarative files replace a database and can be reviewed in Git, and decK can sync those files to a running gateway. Because only traditional mode supports database-dependent plugins such as cluster-strategy rate limiting and OAuth2, the team must confirm early which plugins its design needs and which deployment mode they require. Authorizers map to JWT, basic auth, OAuth or ACL plugins, and usage plans map to rate limiting, but the quota and key-management semantics will not match exactly, so each consumer behavior needs an explicit decision. Prove the rebuilt configuration before any DNS change. Run Kong alongside API Gateway, send mirrored or canary traffic through both, and compare status codes, latency, authorization outcomes and rate-limit responses for each route. Confirm the exact Kong version and support window with Kong before choosing a release, since the open-source edition's newest release line and Kong's enterprise support policy differ. Keep the cutover reversible by leaving API Gateway routes intact until the parallel run shows no unexplained differences.
Which Amazon API Gateway features map to Kong Gateway, and which need rework
This table maps each Amazon API Gateway capability to its closest Kong Gateway equivalent and flags whether the move is clean, needs rework or depends on a gap you must verify. Use it as a checklist during inventory, and treat every item marked for confirmation as a question to settle against current Kong documentation and a proof of concept before you commit to a cutover plan.
| Amazon API Gateway capability | Kong Gateway equivalent | Migration note |
|---|---|---|
| REST APIs (OpenAPI-defined resources and methods) | Kong services and routes, configured declaratively with decK from an exported or hand-written definition | Needs rework: export the OpenAPI file, then map each resource to a route. Integration extensions do not carry over and must be rebuilt as upstreams. |
| HTTP APIs | Kong routes with path, host and method matching on services | Needs rework: map each HTTP API stage to a Kong service and confirm header and path matching behavior in your test suite. |
| WebSocket APIs | To be confirmed against current Kong Gateway documentation for WebSocket proxying and plugin behavior | Confirm before planning: do not assume parity. Test connection upgrades, idle timeouts and authorization on the handshake. |
| Routing and load balancing across backends | Routing and load balancing listed in the Kong Gateway README, with upstreams and targets | Clean for HTTP backends: recreate each integration endpoint as a target and verify health and weighting in staging. |
| Lambda, VPC link and other AWS-native integrations | No direct equivalent in the supplied facts; Kong must reach these backends through HTTP upstreams or plugins | Gap to confirm: decide how each Lambda or VPC-private backend is exposed, and check Kong's AWS-related plugins in current documentation. |
| JWT authentication | JWT plugin listed in the Kong Gateway README | Needs rework: rebuild token issuers, keys and claim checks in the plugin configuration instead of authorizer code. |
| OAuth authentication | OAuth authentication plugin listed in the Kong Gateway README; database-dependent in traditional mode | Needs rework: in DB-less mode, confirm which OAuth2 features are available before choosing deployment topology. |
| Lambda authorizers (custom code) | No automatic conversion; reproduce logic with listed authentication plugins or a custom plugin | Needs rework: Kong's README plugins differ from Lambda authorizer code, so the logic must be rewritten and tested. |
| API keys and usage plans | Consumers, ACL and key-auth style plugins, with rate limiting plugins for quotas | Needs rework: keys and plans are not exported with the OpenAPI file. Recreate consumers and limits, then migrate key values through a controlled process. |
| Rate limiting and throttling in place of usage plans | Rate limiting plugin listed in the Kong Gateway README; cluster-strategy limits need traditional mode | Needs rework: choose the limiting strategy per topology, and confirm that counters behave correctly across replicas. |
| Request and response transformation (mapping templates) | Transformation plugins listed in the Kong Gateway README | Needs rework: rewrite mapping templates as plugin configuration, and test payload edge cases against recorded traffic. |
| Health checks for backends | Health checking listed in the Kong Gateway README, with active and passive checks on upstreams | Clean for standard HTTP probes: match thresholds to the timeouts you used in API Gateway and load test before cutover. |
| Stage variables and per-stage deployment | Declarative files per environment, kept in Git and synced with decK | Needs rework: replace stage variables with environment-specific files or variables, and version them alongside the API definitions. |
| DB-less declarative deployment (no database) | DB-less mode with declarative files and a read-only Admin API, per Kong deployment topologies documentation | Clean for stateless routing. Confirm that every plugin you need is supported in DB-less mode before choosing it. |
What to export from Amazon API Gateway and what to rebuild in Kong
Amazon API Gateway lets you export API definitions, but much of what makes a production API work stays behind in the AWS account. Treat the export as the starting point for route definitions and inventory every other part of the setup by hand before you configure Kong Gateway.
OpenAPI definitions per stage
The export gives you OpenAPI definitions for each stage, which become the source for Kong services and routes. Export every stage you run, not only production, because staging often carries different integrations. Confirm the export format and version limits in current AWS documentation before you script the process, since these have changed over time. Check each exported file for AWS-specific integration extensions, which Kong does not read, and plan to replace them with upstream definitions you write yourself.
Usage plans and API keys
Usage plans, throttling limits and API keys do not appear in the OpenAPI export. Record each plan, its quota and rate limits, and which keys are attached to which client. In Kong, these map to consumers, the rate limiting plugin and, where needed, key authentication. Ask the client teams to confirm which keys are live and which are retired, since carrying over an unused key is a common cleanup gap. Store the key values in your secrets system, not in the declarative files you keep in Git.
Authorizer code and Lambda or VPC link integrations
Lambda authorizers are code, so they do not move through the export. Review what each authorizer checks, including token validation, claims and any caching behavior, then rebuild that logic as a Kong authentication plugin such as JWT, OAuth or ACL, or as a custom plugin where no built-in fits. Map each Lambda, HTTP and VPC link integration to a Kong upstream and confirm network paths from the gateway nodes to private targets, since VPC link routing does not carry over on its own.
Stage variables, custom domains and certificates
Stage variables, custom domain mappings, base path mappings and TLS certificates are deployment settings that the API definition does not contain. List each stage variable and where your upstream URLs use it, then set those values per environment in your Kong configuration. Export the certificate chain and private keys through your own key management process, and confirm the domain names that will point to Kong before DNS cutover. Ask your security team to confirm how certificate renewal will work after the migration.
Converting the Kong side with decK
After you build the Kong services, routes and plugins, use decK to dump the gateway state into declarative files and sync them to each environment. This gives you one reviewable record for Git and a repeatable way to promote changes from staging to production. Check the decK documentation for the Kong versions it supports, and confirm that the plugin settings you rebuilt survive a dump and sync cycle before you rely on the files.
How declarative configuration in Kong replaces stages and console settings
In Kong Gateway, the declarative file replaces the stage and the console. Where API Gateway holds routes, stages, usage plans and authorizer settings in AWS, Kong expects the same design written as services, routes, consumers and plugins in a YAML or JSON file that lives in Git. DB-less mode is the simplest way to run that model: Kong needs no database, reads its configuration from the declarative files, and exposes a read-only Admin API, so changes go through review and pipeline deployment rather than through ad hoc edits on a running node. Staging and production become separate files or separate Git branches, and a stage that used to be a deployment setting becomes a directory or environment variable choice in your own pipeline.
The migration tool is decK, Kong's Apache-2.0 licensed command-line utility. Running deck gateway dump against an existing Kong control plane exports its configuration to a file you can review and commit, and deck gateway sync applies a declarative file to open-source Kong Gateway, to Enterprise, or to Konnect. Because decK works from Kong's own configuration model, it does not convert AWS exports for you. Your OpenAPI inventory still has to be translated by hand or with your own scripts into Kong services, routes and plugins, and each authorizer and usage plan needs an explicit replacement. Plan a diff step in your pipeline so every sync shows what will change before it reaches a live node.
The trade-off to settle first is the mode. In DB-less mode, plugins that depend on a database are not available, and the Kong deployment topologies documentation names cluster-strategy rate limiting and OAuth2 as examples. Usage plans in API Gateway often map to rate limiting, so a per-consumer quota that must be shared across nodes can push you toward traditional mode with a database. Make a list of every authentication and traffic control your target design needs, check each against Kong's plugin documentation for DB-less support, and then choose the mode. Changing modes after cutover means rebuilding the deployment, so confirm this before any routes are written.
Migrate from Amazon API Gateway to Kong Gateway in five steps
This sequence moves APIs from Amazon API Gateway stages to self-run Kong Gateway in controlled stages, with a documented inventory, a tested pilot, a measured parallel run, a reversible DNS cutover and a retention-gated shutdown of the AWS side.
Inventory every API, stage and dependency
Export each API's definition per stage and record what the export does not carry: usage plans, API keys, Lambda or VPC link integrations, authorizer code, custom domains, throttling settings and stage variables. Your platform or integration team owns the list, and clients and consumers are identified by owner, traffic volume and business criticality. The output is a single inventory document with one row per API and stage, the authentication method each one uses, and the named owner who signs off on it. The step is complete when every consumer of every stage is accounted for, and the team agrees on which APIs are candidates for the pilot.
Pilot one low-risk API in Kong
Choose one API with low traffic, a limited set of consumers and a clear rollback path, then rebuild it in Kong Gateway using declarative configuration. Convert the exported OpenAPI file into Kong services and routes, define the upstream, re-create the authorizer with a Kong authentication plugin such as JWT, key-auth or OAuth, and replace the usage plan with rate limiting. Keep all files in Git and sync them with decK, reviewing changes through pull requests. Run functional, authentication, error-path and load tests against the Kong instance. The output is a tested Git repository for that API and a test report listing each AWS behavior and its Kong equivalent. Proceed only when the test report shows no unexplained differences in responses, status codes or authorization outcomes.
Run both gateways in parallel
Deploy the Kong configuration alongside the existing API Gateway stage and split traffic between them, starting with a small share of requests from consumers who agree to participate. Compare latency, error rates, authentication failures, throttling responses and upstream load on both paths, and confirm that logs and metrics from Kong reach your monitoring stack. Make sure the Kong data plane can reach the same backends and that the API Gateway stage is not changed during this period. The output is a metrics comparison covering each agreed measure and a list of any defects found and fixed. Move to cutover only when the comparison shows acceptable parity against criteria the client and API owners set before the split began.
Cut over DNS with a documented rollback
Change the DNS record or custom domain mapping to point at the Kong entry point, ideally in stages that increase the share of traffic and keep the original record's time-to-live in mind before the change. Write the rollback procedure before the change, listing the exact DNS record values to restore, who approves a rollback and how consumers are notified. Confirm the procedure with a dry run in a non-production environment. The output is a cutover record with the timestamp, the change made, the monitoring checks performed afterward and the signed-off rollback plan. Keep the AWS stage active and unchanged during the observation period so rollback is a DNS change rather than a rebuild.
Decommission the AWS stage after retention
Once the Kong route has served production traffic through the agreed observation period, retire the API Gateway stage, usage plans, API keys and authorizer functions that no longer serve traffic. Before removal, archive the final exports, configuration history and test evidence, and confirm with compliance and audit owners what records must be retained and for how long. The retention period is set by your policies and client agreements, so confirm it in writing before deletion. The output is a decommissioning record listing each removed resource, the archive location and the approver. The step is complete when the AWS resources are removed and the Kong configuration in Git is the only maintained source for those APIs.
What drives the cost and duration of a Kong migration
This table lists the factors that change how much a move from Amazon API Gateway to self-hosted Kong Gateway costs and how long it takes, with a way to keep each one down. Read it as a checklist for scoping, and use it to judge whether a quote covers each item. Most of the cost sits in the one-time inventory, rebuild and testing work, but hosting, upgrades and on-call recur for as long as you run the gateway.
| Driver | Why it matters | How to keep it down |
|---|---|---|
| Number of APIs and stages | Each REST or HTTP API and each stage needs its own service, routes, upstreams and test pass, so the count sets the rebuild and testing volume. | Consolidate duplicate APIs, retire unused stages and convert the largest APIs first with decK-managed files. |
| Number and type of authorizers | Lambda authorizers, Cognito pools and IAM checks each need an equivalent Kong authentication plugin or custom plugin, and custom code is the slowest to port. | Group APIs by auth pattern, map standard JWT or OAuth flows to built-in plugins and limit custom plugins to real gaps. |
| Usage plans and API keys | Usage plans, throttling and key issuance must be re-created as rate limiting and consumer credentials, and key data does not export with the API definitions. | Export the key and plan inventory early, decide which consumers carry over and plan a credential reissue process. |
| WebSocket and AWS-native integrations | WebSocket routes and direct Lambda, DynamoDB or VPC link integrations need separate design and testing because they do not map one to one onto HTTP upstreams. | Isolate these integrations in their own change set and confirm current Kong support for each connection type before estimating. |
| Plugins that need traditional mode or Enterprise features | Database-dependent plugins such as cluster-strategy rate limiting and OAuth2 require traditional mode, and some features need Kong Gateway Enterprise, which carries a license fee. | Confirm which plugins you need, choose DB-less or traditional mode for each environment and ask the vendor which features need a paid edition. |
| Hosting and Kubernetes operations | Gateway nodes, a database for traditional mode, load balancers and cluster upgrades are paid for in cloud or staff time and recur every month. | Pick a topology that matches your skills, such as DB-less on existing clusters, and size nodes from measured traffic. |
| Observability and logging | Access logs, metrics and traces must be wired to your existing stack, and missing dashboards extend the cutover period. | Reuse existing logging and metrics pipelines and agree on the required dashboards before the rebuild starts. |
| Testing depth | Contract tests, load tests, authorization regression tests and a staged DNS cutover with rollback take the largest share of one-time effort. | Automate tests from the exported OpenAPI files and limit cutover to stage-by-stage traffic shifts with a tested rollback path. |
What usually goes wrong when moving API Gateway traffic to Kong
Most failed cutovers come from behavior that was assumed to carry over, not from Kong itself. The cards below cover the failures we see most often when API Gateway stages become Kong services and routes, each with a check to run before traffic moves.
Usage plans and API keys assumed to carry over
API Gateway usage plans, throttling limits and API key associations do not export with the OpenAPI definition. Teams often assume rate limits moved when only the routes did. Rebuild each plan as a Kong rate limiting configuration on the matching routes or consumers, then compare the quota a sample client receives on API Gateway with the same client on Kong. Keep a written list of every key, its owner and its quota, and confirm each one has a Kong consumer before cutover.
Authorizer logic recreated incorrectly
A Lambda authorizer or Cognito authorizer often encodes business rules that are not visible in the exported definition. Re-creating it with a JWT, OAuth or ACL plugin can accept tokens the old function rejected, or the reverse. Map each authorizer to a documented Kong plugin, list the claims and scopes it checked, and run a negative test matrix with expired, mis-scoped and unsigned tokens against both gateways. Sign off the matrix before any production traffic moves.
Required plugin only available in paid setups
Some designs depend on features that the open-source edition does not offer in its default mode. Database-dependent plugins such as cluster-strategy rate limiting and OAuth2 need traditional mode, while DB-less declarative deployment does not support them. Check each planned plugin against the deployment topology before choosing the architecture, and confirm with Kong which features need Kong Gateway Enterprise. A design that works in a lab with a database can fail once it is moved to DB-less files in Git.
Cached DNS delaying the cutover
Clients, resolvers and load balancers can keep resolving the old API Gateway endpoint for longer than the team expects. Some traffic then reaches the old stage after the team believes it has moved, which makes monitoring look inconsistent. Lower the record time-to-live well before the change window, run both gateways in parallel with identical routes, and watch request counts on each side for a full business cycle before decommissioning the old endpoint.
Stage variables and custom domains missed
Stage variables that drive backend URLs, custom domain mappings and base path rules are easy to overlook in an export. A route can work in a test environment and send production calls to a staging backend, or a partner's hostname can stop resolving. Build an inventory of every stage variable, custom domain and base path mapping per stage, record its Kong equivalent, and have a second engineer check each value against the target environment before sign-off.
Version chosen without a support window
Kong's version support policy covers only Kong Gateway Enterprise, so the open-source edition has no published support window in that document. A version pinned for a migration may then receive fixes later than the team needs. Pin the exact image or package version in the deployment code, record who owns patching, and ask Kong which upgrade path and security response applies to the open-source release you choose. Repeat this check at every quarterly review.
How the migration changes by size and starting point
A small team with a handful of HTTP APIs and simple JWT authorization usually has a contained migration. The main work is translating each stage into Kong services and routes, pointing each route at its upstream, and replacing the API Gateway JWT authorizer with Kong's JWT plugin validating the same issuer and keys. Most of the effort sits in verification rather than configuration, because a small estate can hide assumptions in a few custom mappings.
- Export and inventory: Export each stage's OpenAPI definition and list every integration, authorizer and custom domain by hand.
- Declarative files: Keep the Kong configuration in Git from the first commit, using decK to sync it to the gateway.
- JWT parity: Confirm the issuer, audience and claim checks match what the old authorizer enforced.
- Shadow traffic: Send a copy of production requests to Kong and compare responses before any DNS change.
- Ownership: One or two engineers can usually own the gateway, so document who holds the keys and the runbook.
Confirm first whether any API depends on a Lambda authorizer or request validation that the JWT plugin will not reproduce exactly, and whether the team has someone who will operate the gateway after cutover.",
A mid-sized estate with many stages, usage plans and API keys takes more planning, because usage plans do not export as configuration. Rate limits and quotas tied to API keys must be rebuilt with Kong's rate limiting plugin and consumer-level keys, and the mapping from plans to consumers is a business decision as well as a technical one. The work is spread across platform engineers, API owners and the teams that hold the client relationships.
- Plan inventory: Record every usage plan, its throttle and quota values and the API keys attached to it.
- Consumer model: Decide how plans map to Kong consumers and credentials, and who approves changes.
- Rate limiting policy: Check whether cluster-wide limits need traditional mode, since DB-less mode does not support database-dependent plugins.
- Stage promotion: Move development, test and production stages in sequence, with the same declarative files in each.
- Client communication: Tell API consumers early when keys, quotas or endpoints will change.
Confirm first which rate limiting semantics your consumers depend on, whether a quota must be enforced across nodes, and which of your existing alerts rely on API Gateway metrics.
A platform team already running Kubernetes can choose between Kong Gateway in its standard deployment and the Kong Ingress Controller, which is Apache-2.0 licensed and managed through Kubernetes resources. The scope shifts from building a gateway to defining routes, plugins and consumers as cluster objects reviewed in the same pipelines as other workloads. Ownership generally sits with the platform team, with application teams writing their own route definitions.
- Controller choice: Decide between the Kong Ingress Controller and a plain Kong Gateway deployment with declarative files.
- Resource model: Map each API to Ingress or Gateway API resources, plugin objects and consumer secrets.
- Release tracking: Pin controller and gateway versions and read the changelog before each upgrade.
- GitOps: Store manifests in the same repository flow as your other cluster configuration.
- Cluster isolation: Separate gateway namespaces by environment and restrict who can change plugins.
Confirm first which Kubernetes distributions and versions your clusters run, whether the Kong Ingress Controller version you plan to use supports them, and how secrets for JWT keys will be stored and rotated.
An organization with APIs across several clouds or its own data centers needs a single gateway model that runs in each location, which changes the migration from a one-time move into a standing platform decision. Kong Gateway can run as a self-hosted data plane with a control plane you operate, and the topology choice affects where configuration lives and how far each site depends on a central service. Ownership is shared between cloud teams, network teams and security, and the cutover plan usually runs site by site.
- Topology: Decide between a single control plane with remote data planes or independent gateways per site, and confirm the hybrid mode requirements for your edition.
- Connectivity: Map which upstreams are reachable from each site and how traffic reaches the gateway in each location.
- Consistent policy: Keep one declarative source of truth so the same plugins apply everywhere.
- Edition check: Confirm which features your topology needs are available in the open-source edition and which require Kong Gateway Enterprise.
- Site-by-site cutover: Move one location at a time, with rollback paths that do not depend on another site.
Confirm first whether control plane traffic may leave each site, which edition your design requires, and who in each cloud or data center is accountable for the gateway during an incident.
Questions teams ask before moving from Amazon API Gateway to Kong Gateway
How long does a migration from Amazon API Gateway to Kong Gateway take?
The duration depends on the drivers, not on a fixed number. The main ones are how many APIs and stages you run, how many of them use Lambda, HTTP or VPC link integrations, how many authorizers, usage plans and API keys must be re-created, and how many consumers must be moved without disruption. Teams with a clean OpenAPI export and few custom authorizers usually finish faster than teams with many stage-specific behaviors. Ask DeployOpen or your own engineers to inventory these items first, because that inventory is what turns a vague timeline into a written, fixed-scope plan.
Can our team migrate without an outside partner, and what skills do we need?
Yes, a capable internal team can do it, but it needs several skills at once: AWS API Gateway administration, OpenAPI authoring, Kong concepts such as services, routes and plugins, decK for syncing declarative files, and enough Kubernetes or Linux operations to run the data plane. Security engineers should own the authentication design, because authorizers must be re-created as Kong authentication plugins. If those skills are thin, DeployOpen can plan, implement, document and test the move under a written scope, and your team keeps ownership of the running platform.
What cost components should we expect, and what should we ask for in a quote?
Expect costs in four groups: the people time to inventory, convert and test APIs, the infrastructure to run Kong data plane nodes and any database, the monitoring and logging you must build yourself, and ongoing upgrades and on-call. Some costs are one-time, such as the conversion and testing work, while infrastructure and operations recur. Your Amazon API Gateway per-call charges stop only after traffic is fully moved, so model both bills during the parallel run. Ask any provider for a written scope listing the API count, stages, integration types, authentication methods, test coverage, cutover approach, handover documents and whether ongoing support is included.
Does Kong open source cover the features we use, or do we need Enterprise?
Kong Gateway OSS, licensed under Apache-2.0, covers routing, load balancing, health checking, JWT, basic auth, OAuth and ACL authentication, rate limiting and transformation plugins, plus DB-less declarative deployment. Some features are database-dependent, such as cluster-strategy rate limiting and OAuth2, which need traditional mode. Kong's pricing page states that fully self-hosted gateways with a local control plane and data plane are part of the commercial Kong Gateway Enterprise offering, so confirm your topology before assuming OSS fits. Map each Amazon API Gateway feature you use, including usage plans and per-key quotas, to a specific Kong plugin and mode, and confirm the result with Kong.
Can we keep Amazon API Gateway running during a parallel run?
Yes, the usual approach is to keep the existing API Gateway stages live while the Kong routes receive a portion of traffic, then shift consumers stage by stage. This requires that the same backends are reachable from both gateways and that DNS or load balancer weights can split traffic. Keep in mind that Amazon API Gateway is billed per call, so the parallel period adds cost, and that the two gateways may apply different defaults for timeouts, payload limits and error responses. Confirm these behaviors in your own environment with AWS documentation and your test results before setting cutover criteria.
How do we choose between DB-less and traditional mode?
Choose DB-less mode when your configuration can live in declarative files kept in Git and you do not need database-dependent plugins. In DB-less mode Kong needs no database, reads its configuration from files, and exposes a read-only Admin API, which suits GitOps workflows. Choose traditional mode when you need cluster-strategy rate limiting or OAuth2, or when runtime changes through the Admin API matter to your operations. Kong's deployment topologies documentation describes both modes and hybrid control plane and data plane separation, so review it against your plugin list. Confirm with Kong how each choice affects your upgrade and backup procedures.
How DeployOpen scopes, runs and supports a Kong Gateway migration
DeployOpen plans, implements, tests, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a move from Amazon API Gateway to Kong Gateway, we start with a written scope that inventories your stages, routes and authorizers before any Kong configuration is written.
How we scope
- Inventory every API Gateway stage, resource, integration and authorizer, including exported OpenAPI files and their gaps.
- Agree in writing which APIs move, which Kong deployment mode is used and which Kong Gateway features the design needs.
- Record the cutover approach, rollback conditions and test evidence expected before DNS changes, as part of a fixed-scope agreement.
How we build
- Convert OpenAPI exports into decK-managed declarative configuration stored in Git, with reviewed changes for each service and route.
- Re-create API keys, JWT, OAuth and ACL authentication plugins to match the authorizer behavior your clients depend on today.
- Replace usage plan quotas with rate limiting plugins, then test routing, authentication and limits in a staging environment before cutover.
How we hand over
- Deliver the declarative configuration repository, deployment scripts and runbooks for the self-hosted Kong Gateway environment.
- Document the route map, plugin settings, known differences from API Gateway and the test results gathered during the migration.
- Walk your platform and security teams through operation, configuration changes and the cutover record they will keep.
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover, scoped separately from the migration.
- Confirm the Kong Gateway version and packaging your team will run, and plan upgrades against the release notes you receive.
- Ask for a quote built from the written scope, and confirm with your own cloud team how the gateway will be hosted and monitored.
