Moving From a Managed WAF to One We Actually Owned

The Problem

We were running a managed WAF. Every firewall rule change went through a vendor support ticket. For a team with active internal software development, that meant every deployment had a gate we did not control.

The compounding issues made it worse: intermittent log loss, degrading support quality, and declining confidence in the platform. The license was coming up for renewal and we decided not to renew it. I was tasked with finding, validating, and migrating to a replacement we would own and operate ourselves.

Application categorization across the estate had already been completed by this point. I knew which assets were the crown jewels and which were lower risk properties. That context shaped the entire migration plan.

Phase 1: Evaluation Criteria

Industry reports reports are useful for mapping the market. They are not useful for telling you whether a product will work in your environment. Before looking at vendors, I built a checklist.

Technical support quality. Principal engineers who understand the product, not account managers reading from a runbook.

Regional support presence. No support team in our time zone means midnight troubleshooting calls with someone who has never seen your architecture. That is unacceptable.

API protection capability. We had internally developed applications with API endpoints that needed active coverage.

DDoS mitigation. Both volumetric and application layer.

One specific latency requirement. One of our internally developed applications was hosted in EU-West with a growing customer base in South East Asia. The architecture was a single-page application on a microservice backend. The requirement was that the WAF layer itself could not introduce more than 50ms of additional latency for SEA users accessing the application. Beyond that threshold, the application would not function correctly for a significant portion of its user base. This was a hard filter.

Phase 2: Shortlisting

Two products made the final shortlist. Both were strong on paper. One had no support presence in our region, with no local team or principal engineers in our time zone. Given the weight I placed on that criterion, it was disqualifying regardless of technical capability.

Imperva had the regional presence, the API protection, and the DDoS coverage. That was the product we took into PoC.

Phase 3: The PoC

I ran the PoC for three months across several QA and UAT environments. A PoC against synthetic traffic tells you almost nothing. I needed data that would hold up.

Latency validation. I ran load tests simulating SEA traffic hitting the EU-West application through Imperva's network. The goal was to measure the latency the WAF layer itself was adding, measured under peak simulated load conditions and against baseline direct-path latency through the existing WAF. It stayed within the 50ms requirement.

Bandwidth sizing. WAF licensing at this scale covers both the number of protected applications and the peak legitimate traffic throughput. Real traffic from QA and UAT environments gave me accurate sizing data. Getting this wrong in either direction has commercial consequences.

Three months of data from production like traffic gave me enough confidence to proceed.

Contract Terms

Before signing, I added two conditions to the agreement.

The first was a post migration best practices configuration review. Once migration was complete, Imperva engineers would walk through our deployment, validate the configuration against their best practices, and flag anything we should adjust. That was a hedge against configuration drift during a rapid migration and meant the platform would be sanity checked by people who knew it deeply before we considered the project closed.

The second was training and certification for two internal engineers. Self-managed only works if you have the internal capability to operate the platform. Sending two engineers through Imperva's official training and certification gave us that capability in-house rather than depending on the vendor or external consultants for day to day operations.

Both conditions cost almost nothing commercially but materially reduced operational risk.

Vendors are often willing to include training and post deployment review when asked. Most buyers do not ask.

Phase 4: The Migration

This is where most migration writeups skip the interesting part.

Our managed WAF license had a hard expiry. Everything had to be migrated before it ran out. Pace and mode varied by application.

Lower risk applications went to Imperva in blocking mode immediately. If a false positive caught some traffic, that was an acceptable tradeoff. I worked through these systematically and cleared them first.

Business critical applications, including online banking, could not go straight to blocking mode. A false positive on a financial transaction is not a minor inconvenience. It is an incident.

For these, I migrated UAT environments first, in alert only mode. Nothing blocked, everything logged. I ran each batch for a month, reviewed every alert, distinguished true positives from false positives, and created WAF exceptions for the confirmed false positives. Once I had high confidence in the rule set, I moved live environments to Imperva in blocking mode. TTLs had already been reduced in advance to make rollback practical within minutes if required.

The full estate migration completed over four months. Critical applications moved in controlled batches with the UAT validation cycle running in parallel.

Each migration batch included a rollback window. Because cutover was a DNS change, reversion was simply pointing the record back to the previous WAF. I deliberately kept all configurations on the legacy platform intact until each batch was confirmed stable, so a rollback was always available without reconfiguration work.

The SSL incident.

Mid migration, a mobile application started behaving incorrectly. It took several days to isolate the cause.

Imperva required the certificate chain to be uploaded explicitly rather than relying on automatic chain assembly. Our previous platform handled that step automatically, so it was easy to miss when diagnosing unexpected mobile app behaviour.

Troubleshooting was complicated because we could not share certificate material with support. They had no visibility into the configuration, so we had to resolve it internally.

After several days, working through it with our security architect one evening, we decided to construct the certificate chain manually, without relying on any tooling, to verify each link was correct and in the right order. That was the fix.

If you are migrating to Imperva and have mobile applications in scope, validate your certificate chains explicitly before migration.

Compensating Controls Instead of Becoming the Release Blocker

One situation during the migration reinforced why owning the WAF directly mattered operationally.

An internally developed microservice based workflow management platform was approaching beta release. The application exposed roughly 450 API endpoints. Due to delivery timelines, we did not have enough time to complete full VA/PT before launch.

Delaying the release would have made security the delivery blocker. Releasing it unprotected was equally unacceptable.

We treated it as a risk reduction exercise instead of a binary decision.

The first option was to explicitly block every non essential endpoint at the WAF layer until testing was complete. That meant individually creating rules for approximately 180 endpoints not required for the beta. The approach was difficult to maintain and introduced unnecessary WAF processing overhead from the volume of custom rules.

Instead, we onboarded the application in blocking mode and added a geographic restriction layer. The beta only needed to be accessible from a single country, so we restricted access exclusively to that region while VA/PT continued in parallel. That immediately reduced the exposed attack surface without delaying the release and bought the engineering team time to complete security validation properly.

What Self-Managed Actually Changed Operationally

Moving from managed to self-managed is an operational transformation. The procurement exercise was straightforward. Operational ownership was the difficult part.

Policy ownership shifted to the security team. Security engineers write and tune rules directly. That requires capability investment but creates direct accountability. When a rule causes a false positive in production, the team that wrote it also fixes it.

SIEM integration became possible. Log loss under the previous platform was a recurring problem. With self-managed Imperva, we integrated WAF logs directly into our SIEM. Every event was queryable, correlatable, and available for detection engineering.

Identity integrated with the existing group platform. Admin access to the WAF was federated through the group identity provider rather than relying on local accounts. SSO, group based access control, audit trails, and offboarding all flowed through the same platform we used elsewhere. That removed an entire class of access management overhead.

Alert monitoring became a first class responsibility. During UAT validation we were reviewing alerts daily. That discipline carried over into production. The security team now has a structured process for triaging WAF alerts and determining whether exceptions or rule changes are needed.

Change control was formalised. Self-managed required us to define our own change workflow for WAF rule modifications, including request, review, approval, deployment, and a monitoring window. More process than before, but process we control with SLAs we define.

DevSecOps workflows improved materially. Development teams no longer had to queue a support ticket and wait for the vendor before they could ship. The security team became the interface. Turnaround on rule changes went from unpredictable vendor SLAs to an internal process we could guarantee.

Tuning is ongoing work. WAF policies drift over time. Applications change, new endpoints are added, traffic patterns shift. We built a review cadence into the team's operational rhythm. Without it, the policy degrades quietly.

Measurable Outcomes

What I Would Do Differently

If I were running the migration again, I would validate certificate chain requirements much earlier, before any mobile applications were onboarded. The SSL incident was avoidable. A short verification step during pre migration planning would have caught it.

I would also formalise the rollback procedure and application risk tiering during planning rather than refining them as the migration progressed. Both ended up working in practice, but treating them as planning artefacts from day one would have made the early batches less stressful.

The migration succeeded operationally, but a few of these lessons only became obvious once the platform was under real production traffic.

Closing Thoughts

The migration itself was not the hardest part. The operational shift was.

Moving to a self managed WAF meant accepting that tuning, monitoring, rule ownership, and incident response were now our responsibility. It increased the workload for the security team. It also removed a major operational dependency and gave us the ability to move at the same speed as the engineering organisation.

The technology mattered. The operating model mattered more.

#waf #web-application-firewall #imperva #cloud-security #appsec #migration #devsecops