I'm building a migration off a legacy API proxy layer, what should I replace it with?

It depends on what your proxy is currently doing, but in most migrations the answer is not “replace proxy with one thing”—it’s usually replace it with a small set of explicit capabilities:

Common replacement options

1) If it mostly does routing / TLS / basic auth

Replace it with an API gateway or ingress/controller:

• Kong, Apigee, AWS API Gateway, Azure API Management, GCP API Gateway
• NGINX, Envoy, Traefik, HAProxy
• Kubernetes Ingress + Gateway API / service mesh ingress

Use this if the legacy proxy mainly handled:

• URL routing / path rewriting
• SSL termination
• rate limiting
• request/response transformation
• auth verification
• logging/metrics

2) If it contains business-specific integration logic

Move that logic into a BFF / API composition layer or backend services

• Create a dedicated Backend-for-Frontend (BFF) if the proxy is shaping APIs for specific clients
• Move orchestration into a service layer or workflow/orchestration engine if it’s coordinating multiple downstream calls

Use this if the proxy:

• aggregates responses
• translates one API schema to another
• has client-specific behavior
• makes branching decisions based on domain rules

3) If it’s acting like a legacy ESB / integration hub

Replace it with an integration platform or event-driven architecture

• MuleSoft, Boomi, Camel, NATS/Kafka + workers, Temporal, etc.
• Use events/async workflows where appropriate

Use this if the proxy:

• does message transformation
• fan-out/fan-in
• retries and compensations
• long-running orchestration

4) If it’s mainly for security and policy enforcement

Replace it with API management + zero trust controls

• Gateway for edge policies
• IdP/OIDC for authentication
• mTLS/service mesh for east-west traffic
• WAF / bot protection / DDoS protection as needed

Practical migration recommendation

A good default target architecture is:

• Edge/API Gateway for traffic control and cross-cutting concerns
• BFF or service layer for client-specific shaping and orchestration
• Backend services for business logic
• Observability stack for logs, traces, metrics
• AuthN/AuthZ service for identity and policy

Rule of thumb

• Keep cross-cutting concerns at the edge
• Move business logic out of the proxy
• Use async/event-driven patterns for orchestration when possible
• Avoid recreating the legacy proxy as a “smart gateway” unless you truly need that behavior

Quick way to decide

Ask: “What is the proxy responsible for today?”

• Routing/policy/security → API gateway / ingress
• Payload transformation → BFF or adapter layer
• Orchestration → service layer/workflow engine
• Integration between systems → integration platform/event bus
• Client-specific API tailoring → BFF

If you want, I can help you map your current proxy responsibilities into a target architecture. If you share a list of what it does today, I’ll suggest the best replacement pattern for each piece.