How do you migrate from SonicWall to SASE?
A typical mid-market organisation (50 to 400 users) completes the migration in four to six weeks. The process follows five phases: audit your current SonicWall configuration, map firewall policies to SASE equivalents, pilot with remote users, roll out in phases across sites, and sunset the SonicWall hardware. Cloud-native SASE platforms like Jimber replace the entire SonicWall stack, from firewall rules and VPN tunnels to content filtering, with a single cloud-managed console. No new hardware, no truck rolls.
SonicWall firewalls have served mid-market IT teams well. They are familiar, well-documented, and deeply embedded in network architectures across Belgium, the Netherlands, and the wider Benelux. But the calculus is shifting. Generation 6 hardware hits end of support on 16 April 2026. VPN-related CVEs are being exploited within hours of disclosure. NIS2 enforcement expects controls that a standalone firewall cannot deliver alone. The migration does not need to be painful. This guide walks through the full process, from policy mapping to parallel running, so your team can plan with confidence.
Why SonicWall customers are evaluating alternatives in 2026
Three converging pressures are pushing SonicWall customers toward architectural change. Each one is manageable in isolation. Together, they make a compelling case for rethinking the firewall-centric model entirely.
End-of-support timelines are closing in. SonicWall Generation 6 firewalls, including the widely deployed TZ300, TZ400, TZ500, TZ600, and NSa 2650 through 6650 series, entered Limited Retirement Mode in April 2024. After 16 April 2026, these devices receive no firmware updates, no security patches, and no technical support. Running unpatched firewalls on a public-facing perimeter is a risk no compliance framework will accept.
CVE exploitation is accelerating. The access control flaw CVE-2024-40766 became the primary entry point for the Akira ransomware group’s campaign against SonicWall devices from mid-2025 onward. CISA confirmed active exploitation. Arctic Wolf observed a surge of SonicWall-targeted intrusions in July 2025, with full encryption occurring in under an hour from initial breach in some cases. Even patched devices remained vulnerable where local credentials had not been reset after migration from Gen 6 to Gen 7 firmware.
NIS2 requires more than perimeter filtering. Belgium’s NIS2 implementation is active, with CyberFundamentals (CyFun) certification deadlines in April 2026 for essential entities. The directive requires identity-based access control, centralised logging, incident reporting within 24 hours, and demonstrable network segmentation. A SonicWall firewall handles some of these. Not all. Organisations that rely solely on firewall rules and VPN access will struggle to produce the evidence auditors expect.
What SonicWall gives you and what it doesn’t
SonicWall deserves honest credit. The TZ and NSa series are proven appliances. Admins know the interface. The NSM (Network Security Manager) dashboard centralises basic monitoring across multiple devices. SonicWall’s deep packet inspection engine is solid, and the AGSS/CGSS licensing bundles gateway anti-virus, IPS, and content filtering into a single subscription.
Where SonicWall falls short is architectural. The platform was built around a perimeter model: traffic flows through a box, the box applies rules, and anything inside the perimeter is trusted by default. That model has three structural gaps that matter in 2026.
First, no native Zero Trust Network Access. NetExtender and Mobile Connect provide SSL VPN tunnels that grant network-level access. Once a user is connected, they can reach anything on the subnet unless you build complex firewall rules to restrict them. That is the opposite of least-privilege access.
Second, limited cloud-native capability. SonicWall’s Cloud Secure Edge (CSE) exists, but user feedback consistently notes configuration complexity and a licensing model shift (per-user pooling) that differs significantly from the per-appliance model mid-market teams are accustomed to.
Third, no agentless device isolation. Printers, IoT sensors, and OT equipment sit on the network as trusted endpoints. SonicWall offers no mechanism to isolate these devices at the application level without additional hardware and complex rule sets.
Jimber addresses all three. ZTNA replaces VPN tunnels with identity-based, per-application access. The Secure Web Gateway and FWaaS handle web filtering and firewall policy from the cloud. NIAC hardware isolates agentless devices inline, without requiring software installation. And everything runs from a single management console.
Configuration mapping: SonicWall to SASE
The most practical step in migration planning is mapping what you have to what replaces it. This table covers the core SonicWall components and their SASE equivalents.
| SonicWall component | SASE equivalent | Migration notes |
|---|---|---|
| Firewall rules (TZ/NSa zone-based) | FWaaS policies | Map per zone. Simplify where possible. Most mid-market environments have accumulated rules over years that no longer serve a purpose. |
| NetExtender / SSL VPN | ZTNA | Identity-based, per-application access. No network-level tunnel. Device posture checks verify endpoint health before granting access. |
| Content Filtering Service (CFS) | Secure Web Gateway (SWG) | URL categories plus threat inspection. Cloud-delivered, so the same policy applies whether the user is in the office or at home. |
| Site-to-site VPN (IPsec) | SD-WAN overlay | Secure site-to-site connectivity over commodity internet. No appliance required per location. Faster failover, automatic path selection. |
| Gateway Anti-Virus / IPS | Cloud-native threat inspection | Automatic updates. No firmware dependency. Single-pass inspection across all traffic. |
| NSM (cloud management) | Single management console | All policies, logging, and compliance reporting in one interface. Multi-tenant for service partners managing multiple customers. |
| Unmanaged devices (printers, IoT, OT) | NIAC hardware | Inline isolation. Devices that cannot run an agent get controlled access paths without touching the device itself. |
Jimber’s single console maps all these components into one policy engine. Instead of managing rules across individual TZ firewalls per site, you define policies once and they apply globally, with per-site or per-user exceptions where needed.
Step-by-step migration timeline
A phased approach keeps risk low and delivers measurable progress at each stage. Here is a realistic timeline for a mid-market organisation with 50 to 400 users across two to five sites.
Week 1 to 2: Audit and discovery. Map every application currently accessed through NetExtender or site-to-site VPN. Document user groups, access requirements, and device types. Export your SonicWall firewall rules and identify which ones are active, which are redundant, and which conflict. This step often reveals that 30 to 40 percent of rules are no longer needed. Flag any agentless devices (printers, building management systems, production equipment) that will need NIAC isolation rather than agent-based access.
Week 2 to 3: Identity integration and policy design. Connect your identity provider (Azure AD/Entra ID, Google Workspace, or another IdP) to the SASE platform. Sync user groups and map them to application access policies. Design device posture baselines: minimum OS version, disk encryption, endpoint protection status. This is where the migration fundamentally differs from a hardware refresh. You are moving from IP-based rules to identity-based policies.
Week 3 to 4: Pilot with remote users. Deploy ZTNA for two to three low-risk, high-usage applications. Remote workers are the ideal pilot group because they experience the most VPN friction and benefit immediately from faster, more reliable access. Run ZTNA alongside the existing SonicWall VPN during the pilot. Monitor user experience, access logs, and support tickets. Refine posture policies based on real-world device states.
Week 4 to 5: Phased rollout. Expand ZTNA to cover business-critical applications: ERP, CRM, file shares, internal tools. Enable SWG and FWaaS policies for web traffic. Deploy SD-WAN overlays to replace site-to-site IPsec tunnels. Each application published through ZTNA reduces the traffic flowing through the SonicWall, gradually shifting load to the SASE platform.
Week 5 to 6: SonicWall sunset. Once application coverage reaches 80 percent or more and support ticket volume stabilises, begin decommissioning. Disable VPN access for migrated applications. Remove firewall rules that have been replaced by SASE policies. Some organisations retain a SonicWall at the data centre edge during an observation period. That is fine. The goal is to get there within a quarter, not to force a single weekend cutover.
We have published similar guides for Fortinet customers migrating from SSL VPN. The pattern is consistent: phased migration with parallel running delivers the best outcomes. For a detailed view of how the full deployment fits together, see the SASE implementation timeline.
Running SonicWall and SASE in parallel
The transition period is where most teams worry. The good news: cloud-native SASE does not conflict with on-premise firewalls. Both can operate simultaneously.
During the parallel phase, set up an IPsec tunnel between your SonicWall appliance and the SASE cloud point of presence. This creates a hybrid path where migrated users route through SASE while non-migrated users continue through the firewall. DNS plays a key role. Internal DNS queries for migrated applications should resolve to the SASE gateway. Queries for applications still behind the SonicWall resolve to the local network as before. Split DNS configuration handles this cleanly.
Jimber’s cloud-native architecture means there is no hardware conflict during the transition. No rack space competition, no port contention, no firmware compatibility issues. The SASE platform runs entirely in the cloud. Your SonicWall continues to function as it always has until you are ready to retire it.
Start with the users who feel the most VPN pain: remote workers, frequent travellers, and contractors. They benefit immediately from faster access and better reliability. As each group migrates, reduce the VPN’s scope. Disable NetExtender access for specific user groups once they are confirmed on ZTNA. Keep a documented rollback procedure available until you are confident the migration is complete.
The legacy VPN risk report details why maintaining VPN access longer than necessary increases exposure. Every week with both systems running is a week with two attack surfaces instead of one.
What about devices that can’t run an agent?
This is the question SonicWall customers rarely think about until it becomes a problem. Printers, IP cameras, building management systems, medical devices, and industrial controllers sit on the same network as managed endpoints. SonicWall treats them as trusted devices on the local subnet. If an attacker compromises one, they gain a foothold that the firewall cannot see.
SASE with NIAC hardware changes this entirely. Jimber’s NIAC isolates agentless devices inline, restricting each device to explicitly defined communication flows. A printer can reach the print server. An IoT sensor can reach its cloud endpoint. Nothing else. The rest of the network is invisible to the device.
For organisations with OT equipment, this IT-OT bridge is particularly valuable. Production controllers, PLCs, and SCADA systems rarely support software agents. Placing them behind NIAC isolation provides segmented access without disrupting production processes or voiding equipment warranties. External maintenance vendors get time-limited, brokered access to specific machines only. The factory floor stays isolated.
The IPsec VPN vs ZTNA migration guide covers how agentless device handling fits into the broader migration strategy, including how NIAC works alongside device posture checks for managed endpoints.
Who is Jimber built for?
Rather than defining when SonicWall might still be the right choice, here is the profile of organisations where Jimber delivers the strongest results.
You have 50 to 400 users across multiple sites or with a significant remote workforce. Your IT team is small, typically two to five people, and managing multiple consoles is eating into productive time. You are facing NIS2 or CyFun compliance deadlines and need centralised logging, identity-based access, and audit-ready reporting. You have agentless devices on your network that need isolation, not just firewall rules. You work with a service partner (MSP) who needs multi-tenant visibility across their customer base. And you want transparent pricing without bandwidth surcharges or hidden add-on costs.
If that description fits, the SASE vendor comparison framework can help structure your evaluation across architecture, pricing, OT support, and data sovereignty.
Frequently asked questions
Can I migrate from SonicWall to SASE without downtime?
Yes. The parallel running approach means users are never without access. During the transition, both systems operate simultaneously. Applications migrate one at a time. Users switch to ZTNA gradually. At no point does the SonicWall need to be powered off for the SASE platform to function. Most organisations complete the migration without a single unplanned outage.
What happens to my SonicWall hardware after migration?
Generation 6 appliances reaching end of support have limited resale or repurposing value. Some organisations keep a single unit as a temporary fallback during the observation period. Generation 7 or 8 appliances can be repurposed as simple routers or sold through your existing channel partner. Once SASE is fully deployed, the hardware is no longer needed for security enforcement.
Do I need to replace my SonicWall switches too?
No. SASE operates at the application and identity layer, not the switching layer. Your existing switches, access points, and cabling remain in place. NIAC hardware connects inline for agentless device isolation but does not require replacing your switching infrastructure.
How does SASE pricing compare to SonicWall AGSS licensing?
SonicWall’s licensing model bundles security services (AGSS/CGSS) per appliance, with separate costs for each firewall in your environment. SASE consolidates all security functions into a single per-user subscription. You eliminate hardware procurement cycles, appliance-specific licensing, and the hidden costs of firmware maintenance, power, and rack space. For multi-site deployments, the cost difference is significant because you no longer need a dedicated firewall and licensing bundle at every location.
Can my MSP manage the migration for me?
Absolutely. SASE platforms with multi-tenant architecture are designed for service partners to manage multiple customer environments from a single console. Your MSP can template policies, standardise baselines, and run the migration using repeatable processes from previous deployments. The NIS2 compliance checklist covers the controls your service partner should be implementing alongside the migration.
Does migrating to SASE help with NIS2 compliance?
It addresses approximately 80 to 90 percent of the technical controls under NIS2 Article 21. Identity-based access satisfies access control requirements. Centralised logging enables the 24-hour incident notification obligation. Device posture checks demonstrate endpoint governance. Network segmentation through NIAC and FWaaS shows risk compartmentalisation. A standalone firewall covers some of these. A unified SASE platform covers most of them from a single evidence source. Read the SSL VPN deprecated timeline for broader context on why the entire industry is moving away from legacy VPN access.
Ready to plan your SonicWall migration? Book a demo and walk through a deployment plan tailored to your environment, site count, and compliance requirements. Jimber’s platform is built for mid-market teams that need to move quickly without the 12-month implementation project.
