Migration Guides
Migrate to Zuplo from Other API Gateways
Moving to Zuplo from another API gateway is straightforward. Zuplo is OpenAPI-native, so you can import your existing API definitions and start configuring policies in minutes. This section provides migration guides for the most common API gateways.
Why teams migrate to Zuplo
Teams migrate to Zuplo from legacy API gateways for several common reasons:
- Reduce operational complexity — Eliminate self-hosted infrastructure, database management, and Kubernetes overhead with a fully managed platform.
- Lower total cost of ownership — Replace expensive enterprise licensing and hidden infrastructure costs with transparent, usage-based pricing.
- Accelerate development velocity — Deploy globally in under 20 seconds with GitOps workflows, TypeScript policies, and instant preview environments.
- Modernize the developer experience — Replace XML configs, Lua plugins, or CloudFormation templates with TypeScript and OpenAPI-native configuration.
- Go multi-cloud — Deploy to 300+ edge locations worldwide without single-cloud lock-in.
Migration guides by platform
| Source platform | Common migration triggers |
|---|---|
| Kong Gateway | Community Edition stagnation, Kubernetes complexity, Lua plugin limitations |
| Google Apigee | Apigee Edge EOL, GCP lock-in, XML policy complexity, high costs |
| AWS API Gateway | AWS lock-in, limited customization, no built-in developer portal |
| Azure API Management | Slow deployments, expensive per-environment pricing, poor GitOps support |
General migration approach
Regardless of your source platform, the migration process follows a similar pattern:
- Export your API definitions — Extract OpenAPI specs from your current gateway. If you don't have OpenAPI specs, create them from your existing route configuration.
- Import into Zuplo — Import your OpenAPI spec through the Zuplo Portal or by adding the file to your project repository.
- Map policies — Translate your existing gateway policies (authentication, rate limiting, transformation) to Zuplo's built-in policy library.
- Configure backend connectivity — Set up URL forwarding or URL rewriting to route traffic to your existing backends.
- Test in a preview environment — Use Zuplo's branch-based deployments to validate your configuration before going live.
- Migrate traffic incrementally — Route a subset of traffic through Zuplo first, then gradually shift all traffic once you've validated the configuration.
Concept mapping
The following table maps common API gateway concepts to their Zuplo equivalents:
| Concept | Kong | Apigee | AWS API Gateway | Azure APIM | Zuplo |
|---|---|---|---|---|---|
| Route definition | Service + Route | API Proxy | Resource + Method | API + Operation | OpenAPI route |
| Request policy | Plugin (Lua) | Policy (XML) | Lambda authorizer | Policy (XML) | Inbound policy (TypeScript) |
| Response policy | Plugin (Lua) | PostFlow (XML) | Response mapping | Outbound policy (XML) | Outbound policy (TypeScript) |
| Authentication | Plugin | VerifyAPIKey policy | API key / Authorizer | Subscription key | API key or JWT policy |
| Rate limiting | Rate Limiting plugin | SpikeArrest / Quota | Usage plan | rate-limit policy | Rate limit policy |
| Developer portal | Kong Dev Portal | Drupal portal | N/A (self-build) | Built-in portal | Developer Portal |
| Environment | Workspace | Environment | Stage | Service | Environment |
| Deployment | Deck / Admin API | API deploy | CloudFormation / SAM | ARM / Bicep | git push with GitOps |
Get migration support
Need help planning your migration? Zuplo's team can assist with migration planning, policy translation, and architecture review.
Last modified on