Migrating from on-prem ProxySG appliances to Symantec Cloud SWG (WSS) is the second-most-common Symantec project of 2026. The technical cutover is fast; the policy intent extraction, traffic forwarding redesign, and SSL inspection re-implementation are what take time. Plan 12-20 weeks for a multi-site enterprise. Run both in parallel during cutover.
Blue Coat ProxySG was the most deployed enterprise web proxy of the 2010s. Its cloud-delivered successor - Symantec Cloud SWG (still called WSS in much of the documentation) - has matured into the strategic platform for new SSE deployments. Most large enterprises today run ProxySG appliances in branch offices and data centers, often racked years ago, often running on hardware that is end-of-support or end-of-sale. The migration to cloud is a 2025-2026 strategic priority for those organizations, and it is one we run several times a year at CyberKIS.
This playbook walks through the migration step by step, based on running it across multi-site enterprises. The product overview is on our Cloud SWG implementation page. The hardest parts are not technical - they are organizational and policy-related.
Why this migration matters now
ProxySG hardware has reached end-of-sale on most SKUs. Existing appliances continue to work - Broadcom has not killed support - but new capacity has to go somewhere, and that somewhere is Cloud SWG. Three additional pressures: the operational cost of maintaining branch-office appliances, the need to extend web security to remote workers (which ProxySG was never designed for), and the policy integration with CASB (CloudSOC) and DLP that requires the cloud platform.
The migration is rarely a forklift. Most organizations move ProxySG-fronted traffic to Cloud SWG site by site over months - large data center sites last, branch offices and remote users first. This is correct. A single weekend cutover for an enterprise web proxy is how you create a Monday-morning crisis.
Phase 1: Policy intent extraction (Weeks 1-4)
The single biggest part of ProxySG-to-Cloud-SWG migration is policy work. ProxySG policy is expressed in Content Policy Language (CPL) or Visual Policy Manager (VPM). Cloud SWG policy is JSON / web UI based - different model, different constructs, different evaluation order. Direct CPL-to-Cloud-SWG translation does not work cleanly. Instead, we extract the policy intent: what the rule was trying to do, why it was created, who benefits from it today.
A typical mid-sized ProxySG estate has 5,000-15,000 lines of CPL across multiple policy files, accumulated over 5-10 years. Probably 30-50% of those rules are stale (created for a person who left, an application that retired, a threat that is no longer relevant). The migration is a chance to clean up.
For each policy block we ask:
- What user, group, or device does this apply to?
- What was the intent? (Block, allow, inspect, log, redirect, authenticate)
- Why does it exist? (Compliance requirement, threat response, business request, unknown)
- Is the intent still valid in the current environment?
- How would we express the same intent in Cloud SWG?
This is a 3-4 week effort for a moderately complex environment. Skipping it leads to either too-permissive Cloud SWG policy (security gap) or too-restrictive Cloud SWG policy (user disruption). Both are bad. Neither is recoverable without going back through extraction.
Teams budget 1-2 weeks for "policy migration." It takes 4-6. The temptation is to export ProxySG VPM and import it as JSON-ish into Cloud SWG. Resist. Build the intent map first, then author Cloud SWG policy from intent. You will end up with fewer rules, cleaner logic, and a maintainable estate.
Phase 2: Traffic forwarding design (Weeks 2-3, parallel to policy)
ProxySG was usually deployed inline at branch perimeters or in WAN data centers. Users connected to the proxy directly (explicit proxy via PAC) or transparently (WCCP, policy-based routing). Cloud SWG forwarding works differently. Options:
- Explicit proxy via PAC - laptops and desktops use a PAC file that routes traffic to Cloud SWG. Works for both office and remote users. Bypassable; depends on PAC file integrity.
- WSS Agent - a lightweight forwarding agent installed on each device. Most secure option for endpoint forwarding. Roaming users get consistent enforcement regardless of network.
- IPsec / GRE tunnels - branch perimeters tunnel traffic to Cloud SWG nodes. Works well for branches with hundreds of users; ties branch to a specific Cloud SWG region.
- SD-WAN integration - some SD-WAN vendors have direct Cloud SWG integration (Cisco Viptela, Versa, Fortinet, Cato). Cleanest option if you already have SD-WAN.
Most enterprises end up with 2-3 forwarding methods. WSS Agent for laptops (employees and contractors), IPsec tunnels for branch offices, SD-WAN integration if available. This is the design decision we work through with the customer; it ripples through everything else.
Phase 3: SSL inspection (Weeks 3-4)
SSL inspection is mandatory for meaningful web security in 2026 - 95%+ of web traffic is HTTPS. ProxySG inspected SSL traffic via SSL Forward Proxy. Cloud SWG inspects SSL traffic at the cloud nodes. Same general concept, different mechanics.
The political conversation around SSL inspection often surprises new teams. You must:
- Update the acceptable use policy disclosure to mention inspection.
- Build the SSL exception list (banking, healthcare, government services, certificate-pinned apps).
- Deploy the SSL inspection root certificate to every endpoint (via MDM for managed, BYOD strategy for unmanaged).
- Validate that certificate-pinning apps (banking apps, Microsoft Teams in some configurations, internal apps) are correctly bypassed.
Work with legal and HR on the disclosure language before turning on inspection. We have run projects where the technical work was done but the legal disclosure took 6 weeks to ratify.
Phase 4: Pilot site cutover (Weeks 5-6)
Pick a small, friendly site - a satellite office with 50-150 users where IT has good relationships and the business can absorb minor disruption. Convert the pilot site to Cloud SWG forwarding while keeping ProxySG running for parallel observation. Run for 2 weeks. Watch logs, ticket volume, and user feedback.
The pilot validates four things: policy correctness (do the same sites get blocked/allowed?), traffic forwarding mechanics (do tunnels stay up?), SSL inspection coverage (any unexpected breakage?), and user experience (any latency complaints?). Tune all four during pilot.
Phase 5: Phased site cutover (Weeks 7-16+)
After pilot succeeds, roll out site by site. Typical sequence:
- Small branches first (fewer users, simpler policy).
- Mid-size branches (clear-cut traffic patterns).
- Headquarters and data centers (most complex policy, most political risk).
- Remote workers globally (typically simplest because WSS Agent is uniform).
Each site has a similar pattern: change traffic forwarding to Cloud SWG, observe for 1-2 weeks while ProxySG still runs in parallel, fully cut over, document any issues. Slower is better - large enterprises spread cutover across 8-12 weeks of sites.
Phase 6: ProxySG decommission (final weeks)
Only after all traffic has been on Cloud SWG for 2-4 weeks with no rollback do you decommission ProxySG appliances. The sequence:
- Confirm no traffic still routes through ProxySG (check logs, monitor for stragglers).
- Export ProxySG configuration and logs for retention.
- Take appliances offline.
- Update DNS, PAC files, firewall rules, monitoring to remove ProxySG references.
- Schedule physical decommission and rack space reclamation.
Common pitfalls we have walked into
WAN performance. ProxySG handled traffic locally at the branch. Cloud SWG sends traffic to the nearest cloud node, which may add 20-80ms latency. For most office use this is invisible. For real-time apps (VoIP, video conferencing) it can be noticeable. Plan the SLA expectations and test from each region during pilot.
Certificate-pinned applications. Some apps (banking, Microsoft Teams in certain configurations, financial trading apps, some healthcare apps) refuse to work through SSL inspection. Build the bypass list during pilot, not in production.
SaaS integrations. If you integrated ProxySG with CASB (CloudSOC) or DLP via legacy interfaces, those integrations need to be re-pointed to Cloud SWG. Test cloud DLP and CASB connectivity during pilot, not at cutover.
Forgotten policy. A 5-year-old ProxySG environment has shadow policy - rules added by people who left, exceptions for systems that were decommissioned, allow-lists for vendors who no longer exist. Audit these during intent extraction, not after cutover.
What this looks like with CyberKIS
A typical CyberKIS ProxySG-to-Cloud-SWG engagement runs 12-20 weeks. We bring the policy intent extraction framework, the forwarding design playbook, the SSL inspection deployment templates, and engineers who have done this multiple times across regulated industries. You bring the appliances and the access; we bring the migration.
Want to scope this migration for your environment? Talk to a CyberKIS engineer or read the Cloud SWG deep-dive for product specifics. Other migration playbooks: SEPM to SES Complete, VPN to ZTNA in 90 days.