A practical framework for firewall migration, governance, security, SD-WAN, logging, and business continuity.
I touched on this migration briefly in my guide to modern IT infrastructure. Here’s the full story — including the parts that had nothing to do with the firewall itself.
We Didn’t Replace Our Firewall Because We Wanted a New Firewall
We replaced it because the way we were managing the existing environment had become a business risk.
The organization had multiple locations, different firewall configurations, inconsistent security policies, and increasing difficulty managing the environment.
Some rules had accumulated over time. Others had been created to solve specific operational problems. Different sites had different requirements. And because we could not centrally manage all the firewalls in a consistent way, maintaining the environment required significant effort from the internal IT team.
At one point, we effectively needed an analyst dedicated to creating and modifying firewall rules. That was a warning sign.
The problem was no longer simply the firewall. The problem was the operating model around the firewall.
We were also dealing with intermittent authentication problems, unreliable reporting, infrastructure overhead, limited log retention capabilities, broad administrative access, support limitations, and growing concerns about performance and confidence in the existing platform.
Replacing the firewall became an opportunity to address those problems together. The solution eventually involved a new next-generation firewall platform, centralized management, cloud-based security reporting, redesigned policies, SD-WAN capabilities, a new support model, and a much stronger governance approach.
But the most important lesson was not which firewall we selected. It was this:
A firewall migration is not a hardware replacement project. It is a security, governance, and business continuity project.
When You Don’t Have a Firewall Problem — You Have a Governance Problem
A firewall is one of the most visible security controls in an organization. But the technology itself is only part of the equation.
A firewall environment becomes difficult to manage when organizations accumulate:
- Inconsistent rules
- Undocumented exceptions
- Excessive administrative privileges
- Outdated policies
- Different configurations across locations
- Weak logging
- Poor reporting
- Unclear ownership
- Inadequate review processes
This is how technical debt develops. Usually, nobody deliberately creates a chaotic firewall environment. One administrator adds a rule. Another creates an exception. A new branch needs access. An application stops working. Someone opens a port temporarily. A temporary change becomes permanent.
Years later, the firewall still works — but nobody completely understands why it works the way it does.
That was increasingly similar to the environment we inherited. The technology was operating, but the governance around it was not where it needed to be.
The Problems We Had to Solve
Before selecting a replacement, we had to understand what was actually wrong with the existing environment. Several problems stood out.
| Problem | Business impact |
|---|---|
| No centralized management | Different policies across branches |
| Inconsistent firewall rules | Higher security and operational risk |
| Dedicated analyst for rule management | High operational effort |
| Authentication instability | Users intermittently lost internet access |
| On-premises reporting infrastructure | Significant storage and infrastructure overhead |
| Unreliable reporting | Limited visibility and auditability |
| Difficult log retention | Increased compliance and investigation risk |
| Single-provider support model | Operational dependency |
| Broad administrative access | Governance and segregation-of-duties concerns |
| Performance issues | Loss of confidence in the platform |
The important thing was that these were not isolated technical problems. They were interconnected.
When Authentication Becomes the Weakest Link
We experienced intermittent problems involving certificate-based user authentication. When the authentication process failed, users could lose internet access.
The problem was particularly frustrating because it was not consistently reproducible. We investigated the environment and involved vendor specialists, but we were unable to achieve the level of stability and confidence we needed. At times, the investigation also pointed toward the Active Directory environment as a possible contributor, making troubleshooting even more complex.
This experience taught me an important lesson:
A security control that intermittently prevents legitimate users from working is an operational risk, even when its purpose is security.
Security and availability cannot be evaluated independently. A control can be technically secure and still be operationally unacceptable if it repeatedly prevents people from doing their jobs.
When Logging Exists but You Still Can’t Answer the Question
Another major problem involved reporting. The existing environment used an on-premises reporting tool tied to the legacy firewall platform.
The concept was reasonable. The operational reality was not.
The reporting infrastructure was hosted on-premises and consumed a significant amount of server storage. More importantly, when we actually needed reports, the solution frequently did not provide the visibility we expected.
That created a difficult situation. An organization may technically have logs somewhere, but if those logs cannot be reliably searched, retained, interpreted, and reported, they provide limited operational value.
We needed better visibility into user access and internet activity, as well as a more reliable way to support our governance and compliance requirements. This was particularly relevant to our requirements around data retention and traceability. The organization needed to maintain appropriate records of access and activity, but the existing reporting architecture was not giving us the confidence that we could consistently satisfy those requirements.
The lesson was simple:
Logging without usable reporting is not effective visibility.
Support Was Becoming a Risk
The support model also needed to be reconsidered. We were paying for support from a very small provider, effectively a one-person operation. As the environment became more complex, that model became increasingly difficult to sustain.
At the same time, our internal analysts had broad access to firewall configurations and policies. Because there was no sufficiently standardized policy structure, this created another governance concern.
The question was no longer just: “Can our team configure the firewall?”
It became: “Who should be allowed to change security policies, under what process, and with what level of accountability?”
That is a governance question.
Before Choosing a Firewall, Define What You Need to Fix
When the decision was made to evaluate alternatives, we compared several established next-generation firewall vendors on the market. But we did not want to choose a vendor based simply on a feature list.
We evaluated the solutions according to our environment and the problems we needed to solve. The main criteria included:
Centralized management — could we manage multiple locations consistently?
Security capabilities — could the platform provide the security controls we actually needed?
Reporting and logging — could we obtain useful reports and retain the information required by the organization?
Performance — could the platform handle our traffic and security inspection requirements?
SSL inspection — could we inspect encrypted traffic without creating unacceptable operational impact?
IPS — could we improve protection against network-level threats?
Application visibility and control — could we understand how the network was being used?
WAN and branch connectivity — could the platform help us improve resilience and management across multiple locations?
Support — could we obtain an appropriate level of technical support?
Operational model — could our internal team manage the environment safely?
Total cost — what would the solution cost over several years, including licensing, support, management, and operational effort?
This last point was particularly important. The cheapest firewall is not necessarily the lowest-cost firewall.
Why We Chose the Platform We Did
For our specific environment, one platform offered the best balance between security capabilities, centralized management, operational requirements, WAN capabilities, and total cost.
But the decision was not based only on the firewall. Our cloud partner also had strong cybersecurity expertise and presented a broader solution that included: the new firewall platform, centralized management, a cloud-based analytics and reporting layer, specialized support, an as-a-service operating model, and SD-WAN capabilities.
That changed the economics and operational model of the project. Instead of simply buying another firewall and handing administration back to the same internal team, we were able to introduce stronger controls around who could manage security policies. The internal IT team still had an important role, but administrative responsibilities became more restricted and structured.
We also negotiated a competitive cost structure for the initial three-year period.
This is an important point for SMB and mid-sized organizations:
Sometimes the right security solution is not simply the product with the best technical specification. It is the combination of technology, support, expertise, governance, and cost that your organization can actually operate successfully.
SD-WAN Was More Than a Feature — It Changed How We Thought About the Branch Network
One of the capabilities that made the new platform particularly relevant to our environment was secure SD-WAN.
For an organization with multiple branches, the firewall is not only a security boundary. It is also part of the organization’s WAN architecture. That distinction matters.
A traditional approach often treats security, routing, internet connectivity, VPNs, and branch connectivity as separate problems. SD-WAN provides an opportunity to manage these functions more intelligently around application requirements, link health, and business priorities — combining SD-WAN capabilities with routing and next-generation firewall security, including application-aware traffic steering and centralized management.
For our environment, this created several practical benefits.
Better Use of Available WAN Links
Instead of thinking about WAN connections simply as “primary” and “backup,” we could think about connectivity in terms of application requirements and link quality.
A link can technically be up and still provide a poor user experience. Latency, packet loss, jitter, congestion, and application requirements can all affect performance. Modern SD-WAN-capable platforms allow policies to consider the health and quality of available paths when deciding how traffic should be handled.
That changes the question from “is the internet link up?” to “is this link good enough for this application right now?” That is a much more useful question for a distributed business.
Better Resilience for Branch Offices
For organizations with multiple locations, connectivity failures can quickly become business problems.
SD-WAN gave us a better framework for using redundant WAN connectivity and defining how traffic should behave when a link becomes degraded or unavailable. This was particularly valuable because branch connectivity could be treated as part of the overall security and network architecture rather than as an isolated networking problem.
The result was a more integrated approach to connectivity, routing, security, VPN, and application performance.
Application-Aware Traffic Management
Another important benefit was the ability to think about traffic according to the applications and services that actually mattered to the business.
Business-critical applications can have very different requirements from general internet traffic. Application-aware policies combined with link-performance information can influence traffic paths and improve application experience — creating opportunities to prioritize traffic, select appropriate paths, and improve user experience without simply increasing bandwidth everywhere. For an organization with multiple branches, that can have a meaningful operational impact.
Connectivity Became Part of the Security Architecture
One of the things I liked about this approach was that we were no longer thinking about the WAN and firewall as completely independent projects. The same architecture could bring together firewall security, routing, VPN, WAN management, application visibility, traffic policies, and security inspection.
For a small or mid-sized IT team, reducing the number of independent platforms can itself become an operational advantage. Every additional platform means another console, another configuration model, another contract, another skill set, another monitoring process, and another potential point of failure.
But there is an important caveat.
SD-WAN Is Not a Replacement for Good Network Design
SD-WAN can simplify WAN operations and improve how traffic is managed. It does not eliminate the need for good network architecture.
You still need to understand IP addressing, routing, network segmentation, VPN topology, internet circuits, application dependencies, security zones, business-critical services, latency requirements, redundancy, and monitoring.
In other words: SD-WAN can automate decisions, but it cannot compensate for an architecture nobody understands. Technology should simplify a well-designed environment — not hide a poorly designed one.
We Didn’t Just Replace the Firewall. We Redesigned the Security Model.
The migration gave us an opportunity to rebuild the firewall policies. Instead of carrying the old configuration into the new platform, we reviewed the environment and redesigned policies around the organization’s actual requirements.
We considered different access levels and scenarios, including headquarters, branch offices, standard users, management, technical teams, and different operational requirements.
This was important because simply importing old firewall rules would have transferred years of accumulated technical debt into a new platform. A migration should not become a technical copy-and-paste exercise.
A new firewall with old policies is often just an old architecture wearing a new brand.
The Real Risk Was Turning Security Features On
The migration also introduced stronger security capabilities. We enabled controls such as intrusion prevention, SSL traffic inspection, and application monitoring and control.
Those capabilities improve security visibility, but they also introduce operational risks. SSL inspection can affect applications. IPS can block legitimate traffic. Application controls can identify traffic differently from what users expect. Security policies can interfere with business processes.
That meant we had to balance security improvement against availability and user experience. The objective was not to turn every security control to maximum. The objective was to understand the environment well enough to apply the controls appropriately.
Security Is Not the Same as Blocking Everything
This became one of the most important lessons of the project.
As reporting capabilities improved, management wanted increasingly restrictive policies. The intention was understandable: if something is risky, block it. But real organizations are more complicated than that.
Some teams legitimately need access to YouTube. Social networks can sometimes be useful for research, marketing, recruiting, communication, or innovation. Users may need access to resources that security teams initially classify as unnecessary.
And there is another reality: if you block something on the corporate network but the user can simply use a personal phone, you may have reduced visibility rather than reduced risk.
This is where cybersecurity maturity becomes important. We initially experienced overly restrictive policies that created friction between IT and business departments. The result was user frustration, exceptions, support requests, and unnecessary conflict.
Over time, we found a better balance. Instead of trying to block everything, we increasingly focused on visibility, reporting, education, appropriate controls, risk-based restrictions, and management accountability.
We created customized reports that allowed managers to understand how their teams were using internet resources. This changed the conversation. Instead of IT saying “you cannot access this,” we could increasingly say “here is how this resource is being used — is this appropriate for your team?”
That is a very different governance model.
Security Controls Should Reduce Risk — Not Create Unnecessary Friction
One principle from this project has stayed with me: a security policy can be technically correct and still be operationally wrong.
If a policy is so restrictive that users constantly try to bypass it, the organization may end up with more support requests, more exceptions, more shadow IT, frustrated users, reduced productivity, and less visibility.
Security should protect the business. It should not become an obstacle that the business is forced to work around. The goal is not maximum restriction. The goal is appropriate risk management.
Reporting Changed the Governance Conversation
One of the biggest improvements was not simply having more logs. It was being able to turn security telemetry into information that managers could understand.
Our new architecture allowed us to create reports for different management audiences. That meant security was no longer only an IT discussion. Managers could see patterns of internet usage within their teams and make decisions based on actual information.
This is an important distinction. A security team can block a category. But a manager can also ask: why is my team using this application? Is this legitimate? Is it helping productivity? Is there a security concern? Should we educate the team? Should we restrict specific users? Is this actually a business problem?
The technology provides visibility. Governance determines what the organization does with that visibility.
What Improved After the Migration?
Centralized management — we moved toward a much more consistent model for managing firewalls across locations.
Standardized security policies — policies were redesigned around defined requirements rather than accumulated exceptions.
Better administrative governance — access to firewall management became more controlled.
Better reporting — the new reporting architecture gave us significantly better visibility than the previous environment.
Improved compliance support — we gained better capabilities for maintaining access information and supporting our retention and audit requirements.
Better security visibility — IPS, SSL inspection, and application visibility gave us additional insight into the environment.
SD-WAN capabilities — branch connectivity became more integrated with routing, security, and application-aware traffic management.
Improved operational confidence — perhaps the most important result was that we had greater confidence in the security platform and its ability to support the organization.
A Practical Firewall Migration Framework
If you are considering replacing your firewall, I would recommend going through these steps before selecting a vendor.
Step 1 — Inventory the Current Environment
Document firewalls, locations, internet connections, VPNs, critical services, published applications, security zones, existing rules, administrators, and dependencies. You cannot migrate what you do not understand.
Step 2 — Review Existing Rules
Ask: why does this rule exist? Who owns it? Is it still required? When was it last reviewed? What systems depend on it? Can it be removed? Does it violate the new security model? This can uncover years of accumulated technical debt.
Step 3 — Define the Security Model
Before configuring the new firewall, establish network zones, user groups, access levels, branch requirements, administrative roles, internet policies, application controls, and logging requirements.
Step 4 — Define WAN and SD-WAN Requirements
If you have multiple branches, evaluate the number of WAN links, internet providers, MPLS or private connectivity, link redundancy, critical applications, cloud applications, VPN requirements, latency-sensitive workloads, failover requirements, application prioritization, and centralized management.
Do not adopt SD-WAN simply because it is fashionable. First determine whether your WAN architecture has a problem that SD-WAN can actually solve.
Step 5 — Define Logging and Reporting Requirements
Ask: what needs to be logged? How long should it be retained? Who needs access? What reports are required? Can you search historical events? Can managers receive meaningful reports? How will the information support audits or investigations? Do not treat logging as an afterthought.
Step 6 — Evaluate Vendors
Compare platforms based on your requirements rather than marketing features. Evaluate security, performance, management, reporting, SD-WAN, support, licensing, cloud capabilities, total cost, internal skills, and managed-service options.
Step 7 — Plan the Migration
A firewall migration should include a migration window, dependencies, testing, communication, configuration backup, a rollback plan, vendor support, monitoring, and post-migration validation. The firewall may be security infrastructure, but it is also business infrastructure.
Step 8 — Monitor After Go-Live
The migration does not end when traffic starts flowing. Monitor authentication, applications, VPNs, internet performance, WAN links, IPS events, SSL inspection, blocked traffic, user complaints, and security alerts. The first version of the policy is rarely the final version.
Questions to Ask Before Buying a Next-Generation Firewall
Before looking at vendors, answer these questions.
About Your Environment
How many locations do you have? How many users? How much internet traffic? How many critical applications? Do you have cloud workloads? Do you need site-to-site VPN?
About Security
Do you need IPS? Do you need SSL inspection? Do you need application control? Do you need identity-based policies? Do you need advanced threat protection?
About WAN and SD-WAN
Do you have multiple internet connections? Do you have branches with unreliable connectivity? Do you need automatic path selection? Do critical applications require different network priorities? Do you need centralized WAN management? Do you need direct internet access for cloud applications?
About Governance
Who can change firewall rules? Are changes documented? Are rules reviewed periodically? Can you centrally manage all locations? Can you audit administrative activity?
About Logging
How long must logs be retained? Can you search them efficiently? Can managers receive reports? Can security teams investigate historical events?
About Operations
Does your internal team have the skills? Do you need a managed service? What happens when the firewall fails at 2 AM?
About Cost
What is the three-to-five-year total cost? What are the licensing requirements? What support is included? What additional services are required?
These questions can be more valuable than comparing a list of product features.
The Most Important Lesson
Looking back, I would not describe the project simply as a firewall brand swap. That would miss the most important part.
We migrated from decentralized management to centralized governance. From inconsistent rules to standardized policies. From broad administrative access to controlled responsibilities. From limited reporting to stronger visibility. From infrastructure-based reporting to cloud-based reporting. From reactive administration to structured security management. From traditional branch connectivity to a more integrated WAN and security architecture.
And we learned that security is not about blocking as much as possible. It is about understanding risk and applying controls that the business can actually operate.
That is what makes a firewall environment mature.
What I Would Do Differently Today
Technology changes. Organizations change. The threat landscape changes. And the lessons from one migration should not become a rigid recipe for another.
If I were approaching the same type of project today, I would still start with the fundamentals: understand the business, understand the network, understand the applications, understand the users, understand the risks. Then select the technology.
I would also pay even more attention to the operating model. A technically excellent firewall can become a problem if nobody owns the policies, rules are not reviewed, administrators have excessive privileges, logs are ignored, exceptions accumulate, and users constantly work around controls.
Technology does not create governance. People, processes, and accountability do. The technology should make good governance easier.
Final Takeaways
- Do not start with the vendor. Start with the problem.
- A firewall migration is also a governance project.
- Do not migrate years of technical debt into your new firewall.
- Centralized management becomes increasingly important as organizations grow.
- Logging is only useful when you can retain, search, analyze, and report it.
- SD-WAN can add significant value when branch connectivity, application performance, and WAN resilience are real business requirements.
- SD-WAN does not replace sound network architecture.
- Security controls must be balanced against business availability and productivity.
- A managed security model can make sense when internal resources are limited.
- The cheapest firewall is not necessarily the lowest-cost solution.
- Security policies should be risk-based rather than simply restrictive.
- The goal is not to block everything. The goal is to reduce business risk while maintaining visibility and productivity.
What Should You Do Next?
If your current firewall environment is becoming difficult to manage, don’t start by asking “which firewall should we buy?”
Start with: “what problems are we trying to solve?”
Review your architecture. Audit your rules. Understand your users. Map your dependencies. Evaluate your WAN. Define your security and logging requirements. Determine whether SD-WAN addresses a real business need. Then compare technologies and operating models based on those requirements.
In my experience, the right firewall is not necessarily the one with the longest feature list. It is the one that provides the security, visibility, governance, performance, connectivity, support, and operational model that your organization can realistically sustain.
And sometimes, the biggest improvement does not come from the firewall itself. It comes from finally putting the governance around it.
What’s Next at DangeloSec?
This article is part of a practical series about modern IT infrastructure, cybersecurity, and technology decision-making for small and mid-sized organizations.
If you are starting from the broader infrastructure perspective, read: The Complete Guide to Modern IT Infrastructure.
Next, we will go deeper into how to evaluate next-generation firewall solutions for small and mid-sized organizations, including the capabilities, operational considerations, and total cost of ownership that actually matter when comparing vendors.