Critical - Ingress NGINX Retirement: What IBM Sterling Teams Need to Know

Dear IBM B2B Integrator Community,

I know I typically publish these monthly, but this news is important enough that it couldn’t wait. This week I need to talk about something that’s going to affect a lot of IBM Sterling SSP, B2B/SFG Kubernetes deployments: the retirement of ingress-nginx. If you’re running IBM Sterling SSP, B2Bi or SFG on Kubernetes and using ingress-nginx as your entry point, you’ve got several months to plan your migration.

On November 11, 2025, Kubernetes SIG Network announced they’re retiring the ingress-nginx controller project. Maintenance continues until March 2026, then it stops best effort only—no releases, no bug fixes, no security patches. Your deployments will keep running, but you’ll be operating unmaintained software in production. For enterprise B2B platforms handling sensitive trading partner data, that’s a serious problem.

Why This Actually Matters for IBM Sterling Deployments

Here’s the reality: ingress-nginx isn’t just handling your web consoles and APIs. If you’re like many teams, you’re maybe using TCP/UDP passthrough for SFTP and FTPS adapters too. That means ingress-nginx is routing:

IBM Sterling SSP, B2Bi and SFG:

• HTTP/HTTPS Server Adapters
• SFTP adapters (via TCP passthrough)
• FTPS adapters (via TCP passthrough)
• Web consoles: Dashboard, B2Bi Console, MyFileGateway portal
• REST APIs

Check your ConfigMaps for tcp-services or udp-services—if they’re there, you’re affected beyond just HTTP traffic.

The compliance piece is what really matters here. Post-March 2026, running unmaintained software with potential vulnerabilities creates material compliance risk. PCI-DSS Requirement 6.2 explicitly mandates vulnerability management and timely patching. FedRAMP requires documented remediation timelines for security flaws. Get it right with a planned migration, and you maintain compliance and security posture. Get it wrong, and you’re explaining to auditors why you’re running unpatched software handling financial transactions.

What You Need to Do Right Now

Immediate Actions (Next 30 Days):

Start by actually understanding what you have deployed. Audit your clusters to identify where ingress-nginx is running and what traffic it’s handling—both HTTP/HTTPS ingress resources and any TCP/UDP passthrough configurations. Here’s what actually matters: record which namespaces, Services, and ConfigMaps rely on tcp-services or udp-services, and document any custom NGINX annotations you’re using. This isn’t busywork—without this inventory, you can’t scope your migration properly. Know what you’re on the hook for before March 2026.

Short-term Planning

You need to evaluate alternatives and pick your path. Here are the options that actually work in production:

Gateway API (Official Successor for HTTP/HTTPS)

The Good: This is the Kubernetes-native replacement with proper community backing. Multiple implementations available—Kong, Contour/Envoy, Traefik, HAProxy, plus commercial offerings. Better security models and role-oriented design that aligns with enterprise separation of duties.

The Reality Check: Gateway API solves HTTP/HTTPS routing beautifully but doesn’t handle TCP/UDP protocols. If you’re using ingress-nginx for SFTP/FTPS passthrough, Gateway API alone won’t cut it—you’ll need a separate solution for non-HTTP traffic.

When it makes sense: My default recommendation for HTTP workloads (web consoles, APIs, HTTP adapters). Combine it with LoadBalancer Services for SFTP/FTPS.

F5 NGINX Ingress Controller (Smoothest Migration Path)

The Good: This is a different, vendor-maintained product (not the retiring ingress-nginx project). Supports both HTTP and TCP/UDP passthrough with enterprise support. Closest to your current architecture, minimal configuration changes needed.

The Reality Check: Commercial product with licensing costs. You’re trading open-source for vendor dependency, but you get support and guaranteed updates.

When it makes sense: You need TCP/UDP passthrough support and want the path of least disruption. Enterprise environments where vendor support matters.

LoadBalancer Services (Direct TCP Routing)

The Good: Bypasses the ingress layer entirely—direct external load balancer to your IBM Sterling pods. Simple, efficient, and removes the middleman for protocols like SFTP/FTPS.

The Reality Check: Each service needs its own external IP and potentially separate cloud load balancer costs. You’ll have different TLS termination points to manage versus centralizing everything in ingress.

When it makes sense: For non-HTTP protocols (SFTP, FTPS) when combined with Gateway API for HTTP. This hybrid approach is what I’m recommending to most teams.

Cloud-Native Options

The Good: Azure Application Gateway Ingress Controller or AWS Load Balancer Controller integrate natively with cloud security services and simplify certificate management.

The Reality Check: Azure’s TCP/TLS Layer 4 proxying is currently in preview with limited availability—test carefully before committing. These typically only support HTTP/HTTPS well, so you’ll need separate solutions for SFTP/FTPS.

When it makes sense: If you’re already deep in Azure or AWS and can accept the TCP limitations.

What Actually Works: My Recommendation

Hybrid approach: Gateway API for HTTP/HTTPS traffic (web consoles, APIs, HTTP adapters) and LoadBalancer Services for file transfer protocols (SFTP, FTPS, FTP). You get modern HTTP routing with proper community backing, plus simple direct routing for TCP protocols.

Trade-offs you need to know: This requires additional external IPs and potentially higher cloud load balancer costs. You’ll manage TLS termination in multiple places instead of one central ingress point. But you get better separation of concerns, improved observability, and you’re not trying to replicate complex TCP passthrough on Gateway API implementations that don’t fully support it.

If you want minimal disruption: F5’s NGINX Ingress Controller gives you the closest migration path. You keep your current architecture pattern, get vendor support, and meet compliance requirements for maintained software.

The Testing You Can’t Skip

Run a proof-of-concept for Gateway API with your HTTP workloads. Separately, test your chosen TCP approach (F5 NGINX Controller or LoadBalancer Services).

Critical: explicitly test protocols with actual trading partners before you migrate production. Some partners use non-standard ports or behavior that require specific configuration. Finding this out during your production cutover is not fun.

Migration Resources That Actually Help

• Gateway API Migration Guide
• ingress-nginx TCP/UDP Documentation
• Vendor-specific migration guides (Kong, Traefik, F5 NGINX, cloud providers)

Looking Ahead

March 2026 sounds far away, but enterprise change management takes time. Between testing, client approvals, change windows, and inevitable issues, months pass quickly—especially when you’re managing multiple IBM Sterling environments across different clients.

The silver lining here: this forces the IBM Sterling community toward more modern, better-maintained solutions. Gateway API represents genuine improvements over the original Ingress specification. Use this migration as a catalyst for broader platform improvements—review your load balancing strategies, TLS termination, observability, and security policies.

Start planning now. Your security team will thank you.

As always, if you have questions about your specific IBM Sterling environment or need guidance on which migration path makes sense for your deployment, feel free to reach out directly.