Migrating from Tyk to Zuplo: Plugin Mapping, Architecture Translation, and Step-by-Step Guide

Q: 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.

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.

Why Teams Migrate from Tyk
Architecture Comparison
Middleware-to-Policy Mapping
Translating Tyk Configuration to Zuplo
Authentication Migration
Rate Limiting Migration
Custom Go Plugin Migration
Analytics and Monitoring Migration
Developer Portal Migration
CI/CD and GitOps
Step-by-Step Migration Playbook
Frequently Asked Questions
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 — 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) — 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, Okta, AWS Cognito, and Firebase.
OAuth 2.0 → JWT Auth Policy — 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 — Built-in support for HTTP Basic authentication.
mTLS → mTLS Auth Policy — Mutual TLS authentication for service-to-service communication.

Traffic Control

Rate Limiting → Rate Limiting Policy — 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 — Built-in policy to enforce a maximum request body size.
IP Access Control (allow/deny) → IP Restriction Policy — 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.
CORS → Custom CORS Policy — Configure allowed origins, methods, and headers per route.

Request/Response Transformation

Request Header Transform → Set Request Headers — Add, modify, or remove request headers declaratively.
Response Header Transform → Set Response Headers — Modify outgoing response headers.
Request Body Transform → Transform Request Body — Use a custom TypeScript policy to transform request payloads.
Response Body Transform → Transform Response Body — Modify response bodies using TypeScript before they reach the client.
URL Rewrite → URL Rewrite Handler — Rewrite upstream URLs using pattern-based template interpolation.

Validation

JSON Schema Validation → Request Validation Policy — 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 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 provides a fully managed key service where you can:

Create consumers with metadata (plan tier, organization, etc.)
Issue API keys that are automatically validated at the edge — globally
Let developers self-manage their keys through the developer portal
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.

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 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 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.

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 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):

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):

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:

Gateway records request data and writes it to Redis
Tyk Pump reads from Redis and forwards data to your chosen backend (MongoDB, ElasticSearch, Prometheus, InfluxDB, etc.)
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 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. 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:

Your gateway configuration (routes.oas.json, policies.json, and custom TypeScript modules) lives in a GitHub repository
Push to a branch, and Zuplo automatically creates a preview deployment
Merge to main, and the production gateway updates across all 300+ edge locations
Every deployment is immutable and versioned — rollback by reverting a commit
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
Connect your GitHub repository for GitOps deployments
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
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.

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. 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 and follow the Getting Started Guide to set up your first gateway in minutes.

For planning your migration:

Compare Zuplo and Tyk — See a detailed feature-by-feature comparison.
Kong Migration Guide — If you are also evaluating other gateways, see how the migration process compares.
Policy Catalog — Browse all available built-in policies.
Custom Policies Documentation — Learn how to write your own TypeScript policies.

Table of Contents

Why Teams Migrate from Tyk

Architecture Comparison

Tyk’s Architecture

Zuplo’s Architecture

Key Differences at a Glance

Middleware-to-Policy Mapping

Authentication

Traffic Control

Request/Response Transformation

Validation

Observability

Translating Tyk Configuration to Zuplo

Tyk API Definition → Zuplo Routes

Authentication Migration

API Key Authentication

JWT Authentication

OAuth 2.0

Rate Limiting Migration

Custom Go Plugin Migration

Tyk Go Plugin vs. Zuplo TypeScript Policy

Key Advantages of the TypeScript Approach

Common Go Plugin Patterns and Their Zuplo Equivalents

Analytics and Monitoring Migration

Tyk’s Analytics Architecture

Zuplo’s Built-in Analytics

Developer Portal Migration

CI/CD and GitOps

Tyk’s Workflow

Zuplo’s Workflow

Step-by-Step Migration Playbook

Phase 1: Assessment and Setup (Week 1)

Phase 2: Custom Logic and Testing (Week 2)

Phase 3: Cutover and Validation (Weeks 3–4)

Rollback Strategy

Frequently Asked Questions

Do Tyk Go plugins work on Zuplo?

How long does a Tyk-to-Zuplo migration take?

Do I need to change my backend services?

What replaces Tyk’s Redis and MongoDB requirements?

Can I run Zuplo alongside Tyk during migration?

What about Tyk’s MDCB for multi-datacenter deployments?

Next Steps