--- title: "Migrating from Tyk to Zuplo: Plugin Mapping, Architecture Translation, and Step-by-Step Guide" description: "A practical guide for teams migrating from Tyk API Gateway to Zuplo, covering Go plugin-to-policy mapping, architecture translation, and a phased migration plan." canonicalUrl: "https://zuplo.com/learning-center/migrating-from-tyk-to-zuplo" pageType: "learning-center" authors: "nate" tags: "API Gateway, Tutorial" image: "https://zuplo.com/og?text=Migrating%20from%20Tyk%20to%20Zuplo" --- Tyk is a popular open-source API gateway, but as your API program grows, the operational overhead of managing its self-hosted stack — Gateway, Dashboard, Pump, Redis, and MongoDB — becomes a significant burden. If your team is evaluating whether to renew Tyk licenses, upgrade a self-hosted deployment, or move to a fully managed platform, this guide walks you through every step of migrating from Tyk to Zuplo. ## Table of Contents 1. [Why Teams Migrate from Tyk](#why-teams-migrate-from-tyk) 2. [Architecture Comparison](#architecture-comparison) 3. [Middleware-to-Policy Mapping](#middleware-to-policy-mapping) 4. [Translating Tyk Configuration to Zuplo](#translating-tyk-configuration-to-zuplo) 5. [Authentication Migration](#authentication-migration) 6. [Rate Limiting Migration](#rate-limiting-migration) 7. [Custom Go Plugin Migration](#custom-go-plugin-migration) 8. [Analytics and Monitoring Migration](#analytics-and-monitoring-migration) 9. [Developer Portal Migration](#developer-portal-migration) 10. [CI/CD and GitOps](#cicd-and-gitops) 11. [Step-by-Step Migration Playbook](#step-by-step-migration-playbook) 12. [Frequently Asked Questions](#frequently-asked-questions) 13. [Next Steps](#next-steps) ## Why Teams Migrate from Tyk Tyk is a capable gateway, but several pain points drive teams to look for alternatives: - **Infrastructure complexity** — A production Tyk Self-Managed deployment runs at least five containers: Tyk Gateway, Tyk Dashboard, Tyk Pump, Redis, and MongoDB (or PostgreSQL). Each component needs monitoring, patching, and scaling independently. Redis alone requires careful tuning for rate limiting and token caching across gateway nodes. - **Go plugin compilation overhead** — Tyk's custom middleware is written in Go and compiled into shared object (`.so`) files. Plugins must be compiled with the exact same Go version, build flags, and Tyk Gateway version. Upgrading the gateway means recompiling every custom plugin to match. - **MDCB complexity for multi-region** — Deploying Tyk across multiple datacenters requires the Multi Data Center Bridge (MDCB), a separate component that brokers configuration and token data between a control plane and worker gateways. Each datacenter needs its own Redis instance, and the MDCB component itself needs to connect to both Redis and MongoDB in the control plane. - **Upgrade risk** — Tyk Gateway major version upgrades require coordinating database migrations, plugin recompilation, Dashboard updates, Pump updates, and MDCB updates across all datacenters. Teams frequently defer upgrades because the blast radius is too high. - **Cost at scale** — Tyk's cloud plans are priced per gateway and can escalate quickly, with enterprise tiers requiring custom pricing. Multi-region deployments with MDCB increase both licensing and infrastructure costs significantly. ## Architecture Comparison Understanding the architectural differences helps you plan a clean migration. ### Tyk's Architecture Tyk Gateway is written in Go and uses Redis as a shared cluster cache for tokens, rate limiting state, and configuration. A typical self-hosted deployment involves: - **Tyk Gateway** — one or more Gateway instances that proxy API traffic and execute middleware - **Redis** — required for all installations; stores API keys, rate limit counters, and acts as a shared cache across gateway nodes - **MongoDB or PostgreSQL** — persistent storage for API definitions, policies, users, and portal content (required by Tyk Dashboard) - **Tyk Dashboard** — the UI for managing APIs, policies, and users - **Tyk Pump** — a background process that reads analytics data from Redis and writes it to your chosen backend (MongoDB, ElasticSearch, Prometheus, etc.) - **MDCB** (optional) — the Multi Data Center Bridge for multi-region deployments, brokering configuration between a control plane and remote worker gateways Custom middleware is written in Go (or Lua, Python, or gRPC), compiled separately, and loaded into the gateway process. Go plugins must match the exact gateway version and build environment. ### Zuplo's Architecture Zuplo takes a fundamentally different approach: - **Edge-native deployment** — Your gateway runs across 300+ data centers worldwide automatically. There is no single-region deployment to manage or scale. - **OpenAPI-native routing** — Routes are defined in a standard `routes.oas.json` file using the OpenAPI specification format, extended with `x-zuplo-route` for gateway behavior. - **TypeScript policies** — Instead of Go plugins, you write policies in TypeScript with full IDE support, type safety, and access to npm packages. No compilation step, no version-matching, no shared object files. - **Git-native CI/CD** — Every configuration change is version-controlled. Push to GitHub, and your gateway deploys to the edge automatically. - **Fully managed** — No Redis, no MongoDB, no Pump, no MDCB. Zuplo handles all infrastructure, scaling, and updates. - **Built-in developer portal** — Auto-generated from your OpenAPI spec, with API key management and API explorer included. ### Key Differences at a Glance - **Database dependencies**: Tyk requires Redis + MongoDB/PostgreSQL. Zuplo requires nothing — it is fully serverless. - **Multi-region**: Tyk uses MDCB with per-datacenter Redis. Zuplo deploys globally to 300+ locations by default. - **Custom logic**: Tyk uses compiled Go plugins (`.so` files). Zuplo uses TypeScript with instant hot-reload. - **Deployment model**: Tyk uses Dashboard UI or Tyk Operator for Kubernetes. Zuplo is Git-native — push and it deploys. - **Analytics pipeline**: Tyk uses Pump → Redis → backend. Zuplo includes built-in analytics with optional integrations. ## Middleware-to-Policy Mapping One of the biggest questions during migration is: "What replaces my Tyk middleware?" Below is a mapping of Tyk's most common middleware to their Zuplo equivalents. ### Authentication - **Auth Token (api_id/api_key)** → [API Key Authentication](https://zuplo.com/docs/policies/api-key-inbound) — Zuplo's built-in API key policy includes a managed key service with self-service key management through the developer portal. No Redis required for key storage or validation. - **JWT (JSON Web Token)** → [JWT Auth Policy (OpenID)](https://zuplo.com/docs/policies/open-id-jwt-auth-inbound) — Validates JWT tokens from any OpenID-compliant provider. Works with Auth0, Okta, Azure AD, and others out of the box. Zuplo also has provider-specific policies for [Auth0](https://zuplo.com/docs/policies/auth0-jwt-auth-inbound), [Okta](https://zuplo.com/docs/policies/okta-jwt-auth-inbound), [AWS Cognito](https://zuplo.com/docs/policies/cognito-jwt-auth-inbound), and [Firebase](https://zuplo.com/docs/policies/firebase-jwt-inbound). - **OAuth 2.0** → [JWT Auth Policy](https://zuplo.com/docs/policies/open-id-jwt-auth-inbound) — Zuplo validates OAuth2 bearer tokens as JWTs. Your identity provider (Auth0, Okta, etc.) continues to issue tokens; Zuplo validates them at the edge. - **Basic Auth** → [Basic Auth Policy](https://zuplo.com/docs/policies/basic-auth-inbound) — Built-in support for HTTP Basic authentication. - **mTLS** → [mTLS Auth Policy](https://zuplo.com/docs/policies/mtls-auth-inbound) — Mutual TLS authentication for service-to-service communication. ### Traffic Control - **Rate Limiting** → [Rate Limiting Policy](https://zuplo.com/docs/policies/rate-limit-inbound) — Supports per-user, per-IP, per-API-key, or custom attribute-based rate limits. No Redis needed — Zuplo handles rate limit state internally. - **Request Size Limit** → [Request Size Limit Policy](https://zuplo.com/docs/policies/request-size-limit-inbound) — Built-in policy to enforce a maximum request body size. - **IP Access Control (allow/deny)** → [IP Restriction Policy](https://zuplo.com/docs/policies/ip-restriction-inbound) — A custom policy template with allow/deny lists and CIDR range support. You can also write your own IP filtering logic using the [Custom Code Inbound Policy](https://zuplo.com/docs/policies/custom-code-inbound). - **CORS** → [Custom CORS Policy](https://zuplo.com/docs/programmable-api/custom-cors-policy) — Configure allowed origins, methods, and headers per route. ### Request/Response Transformation - **Request Header Transform** → [Set Request Headers](https://zuplo.com/docs/policies/set-headers-inbound) — Add, modify, or remove request headers declaratively. - **Response Header Transform** → [Set Response Headers](https://zuplo.com/docs/policies/set-headers-outbound) — Modify outgoing response headers. - **Request Body Transform** → [Transform Request Body](https://zuplo.com/docs/policies/transform-body-inbound) — Use a custom TypeScript policy to transform request payloads. - **Response Body Transform** → [Transform Response Body](https://zuplo.com/docs/policies/transform-body-outbound) — Modify response bodies using TypeScript before they reach the client. - **URL Rewrite** → [URL Rewrite Handler](https://zuplo.com/docs/handlers/url-rewrite) — Rewrite upstream URLs using pattern-based template interpolation. ### Validation - **JSON Schema Validation** → [Request Validation Policy](https://zuplo.com/docs/policies/request-validation-inbound) — Validates request bodies, query parameters, path parameters, and headers against your OpenAPI schema definitions automatically. ### Observability - **Tyk Pump (analytics pipeline)** → Zuplo includes built-in analytics dashboards for request volumes, error rates, and latency. For external integrations, Zuplo supports [OpenTelemetry](https://zuplo.com/docs/articles/opentelemetry) tracing and logging, plus direct integrations with Datadog, New Relic, Splunk, Dynatrace, and more. ## Translating Tyk Configuration to Zuplo ### Tyk API Definition → Zuplo Routes In Tyk, API definitions are JSON objects managed through the Dashboard or stored as files. Here is a typical Tyk API definition: ```json { "name": "User Service", "api_id": "user-service", "proxy": { "listen_path": "/api/users/", "target_url": "http://internal-api.example.com:8080/", "strip_listen_path": true }, "use_keyless": false, "auth_configs": { "authToken": { "auth_header_name": "Authorization" } }, "global_rate_limit": { "rate": 100, "per": 60 } } ``` In Zuplo, the equivalent lives in `routes.oas.json` — a standard OpenAPI file extended with Zuplo-specific configuration: ```json { "paths": { "/api/users": { "get": { "summary": "Get Users", "x-zuplo-route": { "corsPolicy": "none", "handler": { "export": "urlRewriteHandler", "module": "$import(@zuplo/runtime)", "options": { "rewritePattern": "http://internal-api.example.com:8080/api/users" } }, "policies": { "inbound": ["api-key-auth", "rate-limit"] } } } } } } ``` The corresponding policies are defined in `policies.json`: ```json { "policies": [ { "name": "api-key-auth", "policyType": "api-key-inbound", "handler": { "export": "ApiKeyInboundPolicy", "module": "$import(@zuplo/runtime)" } }, { "name": "rate-limit", "policyType": "rate-limit-inbound", "handler": { "export": "RateLimitInboundPolicy", "module": "$import(@zuplo/runtime)", "options": { "rateLimitBy": "ip", "requestsAllowed": 100, "timeWindowMinutes": 1 } } } ] } ``` Key differences to note: - **OpenAPI-native** — Zuplo routes are standard OpenAPI paths. You can import an existing OpenAPI spec and add `x-zuplo-route` extensions. - **Policies replace middleware** — Instead of attaching middleware to APIs via the Dashboard or JSON definition, you reference named policies in your route config. - **Everything in Git** — Both `routes.oas.json` and `policies.json` are files in your repository. There is no separate database or Dashboard to manage. ## Authentication Migration Authentication is typically the most critical part of any gateway migration. Here is how to approach each Tyk auth method. ### API Key Authentication Tyk's Auth Token middleware stores API keys in Redis and validates them on each request. The first time a key is seen at a gateway node, it checks the local cache, then Redis, and then queries MDCB if running in multi-datacenter mode. Zuplo's [API Key Authentication policy](https://zuplo.com/docs/policies/api-key-inbound) provides a fully managed key service where you can: 1. Create consumers with metadata (plan tier, organization, etc.) 2. Issue API keys that are automatically validated at the edge — globally 3. Let developers self-manage their keys through the developer portal 4. Access consumer metadata in your policies via `request.user` To migrate, export your Tyk consumers and their API keys using the Tyk Dashboard API, then create corresponding consumers in Zuplo's API key service using the [API Key Management API](https://zuplo.com/docs/articles/api-key-api). ### JWT Authentication Tyk's JWT middleware validates tokens against a stored secret or JWKS URL. The configuration lives in the API definition's `jwt_signing_method`, `jwt_source`, and `jwt_identity_base_field` properties. Zuplo's [JWT Auth Policy](https://zuplo.com/docs/policies/open-id-jwt-auth-inbound) validates tokens against any OpenID-compliant identity provider using JWKS. Configure it with the same issuer, audience, and JWKS URL values your Tyk gateway uses: ```json { "name": "jwt-auth", "policyType": "open-id-jwt-auth-inbound", "handler": { "export": "OpenIdJwtInboundPolicy", "module": "$import(@zuplo/runtime)", "options": { "issuer": "https://your-tenant.auth0.com/", "audience": "https://api.example.com/", "jwkUrl": "https://your-tenant.auth0.com/.well-known/jwks.json" } } } ``` ### OAuth 2.0 If you are using Tyk as an OAuth 2.0 provider (issuing tokens through Tyk's built-in OAuth server), you will need to move token issuance to a dedicated identity provider like Auth0, Okta, or AWS Cognito. Zuplo validates OAuth bearer tokens as JWTs but does not act as a token issuer — this is by design, as dedicated identity providers handle this much better. If your Tyk setup already delegates token issuance to an external IdP and Tyk only validates tokens, migration is straightforward — configure Zuplo's JWT policy with the same provider settings. ## Rate Limiting Migration Tyk's rate limiter uses Redis to maintain counters across gateway nodes. It supports both per-API rate limiting (configured in the API definition) and per-key rate limiting (configured through access policies or keys). Zuplo's [Rate Limiting policy](https://zuplo.com/docs/policies/rate-limit-inbound) provides: - **Per-user, per-IP, or per-key limiting** — Choose what attribute to rate limit by. - **Custom bucket functions** — Write a TypeScript function to define custom rate limit grouping logic (e.g., rate limit by customer tier, organization, or any combination of request attributes). - **No external dependencies** — Unlike Tyk's Redis-backed rate limiter, Zuplo's rate limiter works out of the box without managing additional infrastructure. - **Standard 429 responses** — Automatically returns `429 Too Many Requests` with appropriate `Retry-After` headers. A typical rate limit configuration in Zuplo: ```json { "name": "rate-limit", "policyType": "rate-limit-inbound", "handler": { "export": "RateLimitInboundPolicy", "module": "$import(@zuplo/runtime)", "options": { "rateLimitBy": "user", "requestsAllowed": 100, "timeWindowMinutes": 1 } } } ``` The biggest advantage here is eliminating Redis entirely. Redis cluster tuning, failover configuration, and memory management for rate limit counters are all things you no longer need to think about. For more on the tradeoffs between self-hosted and managed gateways, see our [managed vs. self-hosted API gateway comparison](/learning-center/managed-vs-self-hosted-api-gateway). ## Custom Go Plugin Migration If your team has built custom Tyk plugins in Go, migrating them to Zuplo TypeScript policies is usually simpler than you might expect. Zuplo's [Custom Code Inbound Policy](https://zuplo.com/docs/policies/custom-code-inbound) lets you write arbitrary request processing logic in TypeScript. ### Tyk Go Plugin vs. Zuplo TypeScript Policy Here is a side-by-side comparison of a simple header-injection middleware: **Tyk (Go):** ```go package main import ( "net/http" ) // AddCustomHeader adds a custom header to the upstream request func AddCustomHeader(rw http.ResponseWriter, r *http.Request) { r.Header.Set("X-Custom-Header", "my-value") } ``` This Go file must be compiled into a `.so` file using the Tyk plugin compiler (matching the exact gateway version), then uploaded as a plugin bundle or placed on the filesystem. **Zuplo (TypeScript):** ```typescript import { ZuploContext, ZuploRequest } from "@zuplo/runtime"; export default async function ( request: ZuploRequest, context: ZuploContext, options: { headerValue: string }, policyName: string, ) { const newRequest = new ZuploRequest(request); newRequest.headers.set("X-Custom-Header", options.headerValue); return newRequest; } ``` This TypeScript file goes in your `modules/` directory, references it in `policies.json`, and deploys instantly when you push to Git. No compilation, no version matching, no plugin bundles. ### Key Advantages of the TypeScript Approach - **Full IDE support** — Autocomplete, type checking, and inline documentation in VS Code or any TypeScript-capable editor. - **npm ecosystem** — Import any npm package for tasks like data validation, cryptography, or API calls. - **Standard Web APIs** — Zuplo uses standard `Request`, `Response`, and `Headers` objects. If you know the Fetch API, you know how to write Zuplo policies. - **Easier testing** — Unit test your policies like any TypeScript function. No need for a running gateway instance. - **No version coupling** — Tyk Go plugins must match the exact gateway version. Zuplo TypeScript policies are decoupled from platform versions. ### Common Go Plugin Patterns and Their Zuplo Equivalents **External service callout (Go):** ```go func ValidateWithExternalService(rw http.ResponseWriter, r *http.Request) { resp, err := http.Get("https://auth.example.com/validate?token=" + r.Header.Get("Authorization")) if err != nil || resp.StatusCode != 200 { rw.WriteHeader(http.StatusUnauthorized) return } } ``` **External service callout (Zuplo TypeScript):** ```typescript import { ZuploContext, ZuploRequest } from "@zuplo/runtime"; export default async function (request: ZuploRequest, context: ZuploContext) { const token = request.headers.get("authorization"); const resp = await fetch(`https://auth.example.com/validate?token=${token}`); if (!resp.ok) { return new Response("Unauthorized", { status: 401 }); } return request; } ``` **Response body transformation (Go):** In Tyk, response plugins use the `"response"` hook and require special handling of the response body through Tyk's plugin API. **Response body transformation (Zuplo TypeScript):** ```typescript import { ZuploContext, ZuploRequest } from "@zuplo/runtime"; export default async function ( response: Response, request: ZuploRequest, context: ZuploContext, ) { const data = await response.json(); // Remove sensitive fields before returning to client delete data.internalId; delete data.auditLog; return new Response(JSON.stringify(data), { status: response.status, headers: response.headers, }); } ``` ## Analytics and Monitoring Migration ### Tyk's Analytics Architecture Tyk uses a three-component analytics pipeline: 1. Gateway records request data and writes it to Redis 2. Tyk Pump reads from Redis and forwards data to your chosen backend (MongoDB, ElasticSearch, Prometheus, InfluxDB, etc.) 3. Tyk Dashboard reads from the backend to display analytics This pipeline requires managing Pump configuration, ensuring Redis has enough memory for analytics buffering, and maintaining the backend data store. ### Zuplo's Built-in Analytics Zuplo includes built-in analytics dashboards covering request volumes, error rates, latency percentiles, and per-API-key usage — without any additional components to deploy. For teams that need to integrate with their existing monitoring stack, Zuplo supports: - **OpenTelemetry** — Export traces and logs to any OTLP-compatible backend (Honeycomb, Jaeger, Dynatrace, and more). See the [OpenTelemetry documentation](https://zuplo.com/docs/articles/opentelemetry) for setup details. - **Datadog** — Direct log and metrics integration - **New Relic** — Real-time log and metrics forwarding - **Splunk** — Log streaming for enterprise SIEM workflows - **Google Cloud Logging** — Direct GCP integration These integrations are configured in your `zuplo.runtime.ts` file: ```typescript import { RuntimeExtensions, environment } from "@zuplo/runtime"; import { DataDogLoggingPlugin } from "@zuplo/runtime"; export function runtimeInit(runtime: RuntimeExtensions) { runtime.addPlugin( new DataDogLoggingPlugin({ apiKey: environment.DATADOG_API_KEY, url: "https://http-intake.logs.datadoghq.com/api/v2/logs", }), ); } ``` The biggest win is eliminating Tyk Pump entirely. No more Pump configuration, Redis memory sizing for analytics, or backend data store management for analytics data. ## Developer Portal Migration Tyk's developer portal is a separate component that requires MongoDB (or PostgreSQL for the newer Enterprise Developer Portal) and manual customization. Portal content, developer applications, and API catalog configuration live in the Dashboard database. Zuplo's developer portal is built into the platform and [auto-generated from your OpenAPI spec](https://zuplo.com/docs/dev-portal/introduction). When you update your routes in `routes.oas.json`, the portal updates automatically. Features include: - **Automatic API documentation** — Generated directly from your OpenAPI specification, always in sync with your gateway. - **API Explorer** — Developers can test your API directly from the docs. - **Self-service API key management** — Consumers sign up, get keys, and manage them without your intervention. - **Custom branding and pages** — Add custom Markdown, MDX, or React pages to your portal. - **Custom domains** — Host your portal on `docs.yourcompany.com`. There is no separate CMS to deploy, no database to manage, and no manual synchronization between your API definitions and your documentation. ## CI/CD and GitOps ### Tyk's Workflow Tyk offers several deployment approaches, each with trade-offs: - **Dashboard UI** — Point-and-click configuration through the web interface. Changes go directly to the database, making version control difficult. - **Tyk Operator** — Kubernetes-native management using Custom Resource Definitions (CRDs). Requires a Kubernetes cluster and operator expertise. - **Tyk Sync** — CLI tool for importing/exporting API definitions. Provides some Git-based workflow, but requires a manual sync step between your Git repository and the Tyk Dashboard. None of these approaches make Git the source of truth. Even with Tyk Operator or Tyk Sync, there is always a synchronization step between your repository and the running gateway state. ### Zuplo's Workflow Zuplo's deployment model is Git-native: 1. Your gateway configuration (`routes.oas.json`, `policies.json`, and custom TypeScript modules) lives in a GitHub repository 2. Push to a branch, and Zuplo automatically creates a preview deployment 3. Merge to main, and the production gateway updates across all 300+ edge locations 4. Every deployment is immutable and versioned — rollback by reverting a commit 5. Environment variables handle per-environment differences (staging vs. production) There is no sync tool to install, no operator to deploy, no Dashboard database to keep in sync. The Git repo _is_ the production state. ## Step-by-Step Migration Playbook A typical Tyk-to-Zuplo migration follows three phases: ### Phase 1: Assessment and Setup (Week 1) **Inventory your Tyk deployment:** - List every API definition and its middleware chain - Document custom Go plugins and their functionality - Export API key consumers and their metadata - Note rate limit configurations per API and per key - Identify MDCB usage and multi-datacenter topology **Set up Zuplo:** - Create a Zuplo account at [portal.zuplo.com](https://portal.zuplo.com) - Connect your GitHub repository for [GitOps deployments](https://zuplo.com/docs/articles/source-control) - Translate your Tyk API definitions to `routes.oas.json` format - Configure authentication policies to match your Tyk auth middleware - Set up rate limiting policies - Add environment variables for backend URLs and secrets ### Phase 2: Custom Logic and Testing (Week 2) - Migrate custom Go plugins to TypeScript policies - Set up request/response transformation policies - Configure the developer portal - Migrate API key consumers using the [API Key Management API](https://zuplo.com/docs/articles/api-key-api) - Test all routes against your backend services - Validate authentication flows end-to-end - Run load tests to verify rate limiting behavior - Configure logging and analytics integrations ### Phase 3: Cutover and Validation (Weeks 3–4) - Run Zuplo in parallel alongside Tyk (both receiving traffic) - Compare response behavior between Tyk and Zuplo - Gradually shift traffic from Tyk to Zuplo using DNS or a load balancer - Monitor error rates, latency, and throughput - Complete DNS cutover to Zuplo - Decommission Tyk infrastructure (Gateway, Dashboard, Pump, Redis, MongoDB) - Update developer portal URLs and API documentation For more detail on zero-downtime strategies, see our guide to [migrating from self-hosted to managed API gateways](/learning-center/migrate-self-hosted-to-managed-api-gateway). ### Rollback Strategy Because Zuplo deployments are Git-based, rollback is straightforward: - **Configuration rollback** — Revert the Git commit and push. The previous gateway configuration deploys automatically. - **DNS rollback** — If you kept Tyk running during the parallel phase, switch DNS back to Tyk's endpoints. ## Frequently Asked Questions ### Do Tyk Go plugins work on Zuplo? No. Tyk's Go plugins are compiled shared objects (`.so` files) that run inside the Tyk Gateway process. Zuplo uses a completely different extensibility model based on TypeScript policies. However, most Go plugin functionality has a direct Zuplo equivalent — either a built-in policy or a short TypeScript custom code policy. The middleware-to-policy mapping above covers the most common cases. ### How long does a Tyk-to-Zuplo migration take? For most teams, a complete migration takes two to four weeks depending on the number of custom Go plugins and routes. Teams using mostly built-in Tyk middleware (auth tokens, rate limiting, standard transforms) can often complete the migration in under a week because these map directly to Zuplo built-in policies. ### Do I need to change my backend services? No. Zuplo proxies requests to your existing backends using the [URL Rewrite handler](https://zuplo.com/docs/handlers/url-rewrite). Your backend services do not need any changes — Zuplo forwards requests just like Tyk does. ### What replaces Tyk's Redis and MongoDB requirements? Nothing — that is the point. Zuplo is fully managed and serverless. Rate limiting, API key storage, session management, and analytics are all handled by the platform without any external database dependencies. ### Can I run Zuplo alongside Tyk during migration? Yes. The recommended approach is to run both gateways in parallel during the cutover phase, using DNS or a load balancer to gradually shift traffic from Tyk to Zuplo. ### What about Tyk's MDCB for multi-datacenter deployments? Zuplo replaces MDCB entirely. Instead of configuring a control plane, worker gateways, and Redis instances per datacenter, Zuplo deploys your gateway to 300+ edge locations automatically. Global distribution is built in — no bridge components or per-datacenter infrastructure needed. ## Next Steps **Ready to migrate?** [Sign up for a free Zuplo account](https://portal.zuplo.com) and follow the [Getting Started Guide](https://zuplo.com/docs/articles/step-1-setup-basic-gateway) to set up your first gateway in minutes. For planning your migration: - [Compare Zuplo and Tyk](https://zuplo.com/api-gateways/tyk-api-management-alternative-zuplo) — See a detailed feature-by-feature comparison. - [Kong Migration Guide](/learning-center/migrate-from-kong-to-zuplo) — If you are also evaluating other gateways, see how the migration process compares. - [Policy Catalog](https://zuplo.com/docs/policies/overview) — Browse all available built-in policies. - [Custom Policies Documentation](https://zuplo.com/docs/policies/custom-code-inbound) — Learn how to write your own TypeScript policies.