How I Saved $1 Million by Moving Load Balancing Off F5 - One Cluster at a Time

How I Saved $1 Million by Moving Load Balancing Off F5 - One Cluster at a Time

There's a particular kind of organizational debt that nobody talks about: the infrastructure you inherit that works perfectly fine but costs a fortune, requires specialized expertise to maintain, and quietly consumes more of your team's time than anyone has stopped to calculate.

That was our F5 situation.

And fixing it became one of the most technically demanding - and most professionally defining - projects of my career.

The Inventory Nobody Wanted to Look At

As the engineer responsible for maintaining the F5 BIG-IP inventory at Hughes Network Systems, I had a front-row seat to the cost structure that most people in the organization didn't think about day-to-day.

We had multiple BIG-IP clusters deployed across our environment - each one a pair of appliances running in HA configuration, each cluster costing roughly $10,000 (about $5,000 per appliance). And that's just the production units. We also maintained lab F5s for testing and staging - nearly $1,000 per appliance - where we'd validate load balancing configurations for every application before they ever touched production.

On paper, that sounds like disciplined engineering practice. And it was. But here's what the numbers looked like when you stepped back: we had expensive, purpose-built load balancing appliances where many of them were serving only a handful of applications. A cluster of BIG-IPs - with its licensing overhead, its renewal cycle, its operational complexity - standing guard over traffic that didn't justify the footprint.

Every F5 cluster also meant a corresponding set of firewall policies on the FortiGate firewalls that sat in front of them. More devices, more policies, more surface area, more expertise required to keep it all coherent.

The operational overhead wasn't theoretical. It was real, recurring, and growing.

So, I raised my hand and took on the project.

The Strategy: Start Small, Learn Fast

I didn't pitch a big-bang migration. That's not how you survive a zero-downtime mandate.

My approach was deliberate: identify the F5 clusters carrying the fewest applications and start there. Smaller blast radius. Faster feedback loop. Real lessons from real traffic before touching anything critical.

The idea was to consolidate - move the load balancing functionality from standalone F5 appliances into the FortiGate firewalls we already had deployed. Firewalls are a fixed cost in any enterprise environment. You need them regardless. If they could absorb the load balancing workload for a meaningful portion of our application portfolio, we could decommission F5 hardware and licenses without replacing them with anything - just removing cost entirely.

In theory, this was clean. In practice, it was one of the more technically interesting problems I've worked through.

What Actually Happened When I Started Moving Traffic

I went through every piece of documentation I could find - FortiGate admin guides, Fortinet knowledge base articles, community threads, anything that could help me understand how load balancing worked within the FortiOS architecture. I wasn't following a migration runbook someone else had written. I was building the understanding from scratch.

The first few application migrations taught me things no documentation quite prepares you for.

The Inspection Mode Problem

FortiGate operates in two inspection modes: flow-based and proxy-based. For engineers coming from a pure networking background, the distinction isn't immediately obvious, but it matters enormously for load balancing behavior.

Most of our applications were listening on port 443 - HTTPS traffic. When I initially configured the virtual IPs and load balancing policies, I ran into repeated issues with SSL handling and traffic inspection. After a lot of troubleshooting, the root cause kept coming back to inspection mode: for HTTPS load balancing to work correctly, I needed proxy-based inspection. Flow-based wasn't cutting it for most of these workloads.

That was lesson one. And it only revealed itself by moving traffic and watching it fail in specific, instructive ways.

The Certificate Migration Headache

F5 BIG-IP manages SSL certificates within its own certificate store and handles SSL termination cleanly through its profiles. Moving certificates off F5 and importing them correctly into FortiGate required careful attention - the format requirements, the import process, and making sure the certificates were bound properly to the right virtual IPs and policies on the firewall side.

This wasn't catastrophically difficult, but it was the kind of work that bites you if you rush it. I went through this methodically for each application, validating SSL handshake behavior before and after the cutover.

Choosing the Right Load Balancing Method Per Application

One thing that becomes clear quickly: not all applications load balance the same way. HTTP applications, HTTPS applications, and protocol-specific workloads each have different behavioral expectations from a load balancer.

I also had applications that weren't HTTP or HTTPS at all - workloads running over UDP and TCP without a traditional HTTP structure, and without a consistent application-layer IP to route on. For those, I needed to implement IP-based load balancing - a different mechanism than the virtual server model I'd been working with.

I'll be honest: IP-based load balancing in FortiGate required me to go deep on documentation and reference material I hadn't worked with before. Understanding how it distributes sessions, how persistence works differently, and how the underlying policy structure needed to change - this was genuinely new territory. I worked through it, tested it in lab, and got it right before touching production.

Firewall Policy Tuning Across Multiple Devices

Here's the part that makes this more complex than it might appear from the outside: when an application moves from an F5 cluster to a FortiGate firewall, you're not just reconfiguring one device. You're adjusting policies across multiple firewalls - sometimes two or three - depending on how traffic flows through the environment.

For each application migration, I had to trace the full traffic path, identify every firewall policy that referenced the F5 virtual server IPs, understand what needed to change, and make coordinated updates across devices. A mistake in one policy on one firewall could break the application for its users. So, every change was carefully staged and validated.

The Progress: Fifteen-Plus Clusters Moved

I didn't do this all at once. I did it one cluster at a time, picking the smallest footprints first, learning from each migration, and building a cleaner process with each iteration.

Over the course of the project, I migrated applications from fifteen-plus F5 clusters to FortiGate firewalls. Each migration meant decommissioning the corresponding F5 hardware - production appliances at ~$5,000 each, lab appliances at ~$1,000 each - and eliminating the licensing and support costs that came with them.

The math compounds fast when you're removing whole clusters.

The lab F5s came off first. Then the smaller production clusters. Then progressively larger ones as my confidence in the process - and the documentation I'd built around it - grew stronger.

Throughout, zero service disruptions.

The Outcome: $1 Million Saved Over Four Years

When we totaled the decommissioned hardware, eliminated licensing, and removed the recurring support costs across the F5 footprint we retired, the four-year savings came to over $1 million.

That's not a projected number or a model with optimistic assumptions baked in. That's the delta between what we were paying and what we stopped paying.

Beyond the cost number, the operational picture changed meaningfully:

• Reduced device footprint - fewer devices to patch, monitor, maintain, and renew

• Simplified architecture - applications flowing directly through FortiGate, with load balancing and security policy in the same platform

• Lower expertise overhead - no longer maintaining deep F5 specialization alongside everything else the team manages

• Consolidated firewall policy management - fewer policy sets to keep coherent across the environment

The firewalls were always going to be there. We just made them do more.

What This Project Actually Taught Me

Self-directed learning is a professional skill. I didn't have a senior engineer who'd done this migration before to guide me through it. I had documentation, a test environment, and a willingness to troubleshoot until I understood what was happening. That process - reading, testing, failing, figuring out why, trying again - is how I built the understanding that made the production migrations clean.

Technical problems are usually policy problems in disguise. The inspection mode issue, the certificate handling, the IP-based load balancing configuration - none of these were fundamentally hard problems. They were problems that required understanding the platform's model well enough to configure it correctly. That's almost always what's under the surface of "it's not working."

Small wins compound. Starting with the least-complex clusters wasn't just risk management. It was a learning strategy. Each migration made the next one faster and more predictable.

Cost savings need a narrative, not just a number. A million dollars over four years is a compelling number. But the story that makes that number credible is the audit, the methodology, the incremental approach, and the zero-disruption track record.

You're Sitting on a Similar Inventory Problem

Look at what you have. Map the actual usage. Then ask honestly: is this device earning its cost, or is it a legacy assumption nobody's re-examined?

Sometimes the answer is yes, keep it - the functionality is irreplaceable for that workload. But often, especially in large enterprise environments, you'll find infrastructure that made complete sense when it was deployed and has been carried forward on momentum ever since.

The project that saves $1 million usually doesn't start with a dramatic announcement. It starts with someone quietly building an inventory and asking uncomfortable questions.

I'm glad I asked.