Amar Jeer

Migrating Off a Cloud-Proxy SSE: What Changes When Inspection Moves to the Device

August 12, 2026

MIN READ

Migrating Off a Cloud-Proxy SSE: What Changes When Inspection Moves to the Device

The short answer

Migrating from a cloud-proxy SSE to an on-device model is simpler than migrating between two cloud proxies, because you are removing infrastructure rather than reconfiguring it. There are no tunnels to re-point, no PAC files to rewrite, and no connector mesh to rebuild. You deploy an agent through your MDM, translate your existing policy, run the two side by side, then cut over. Most teams do it in days or weeks, not quarters.

This is the decision-stage end of the two-architecture story. If you have read why on-device removes the backhaul detour, this is how you actually get there. Start with the SSE architecture guide for the why.

What you are removing, not adding

A cloud-proxy migration usually means standing up new forwarding: agents or tunnels pointed at a new vendor's points of presence, PAC files updated, connectors deployed, traffic steering reconfigured. That is why those projects run long.

Moving to on-device inverts it. There is no point of presence to route to, so the forwarding layer goes away. What you deploy is a single agent that inspects locally. The migration is mostly about translating policy and validating traffic, not rebuilding a network path. See on-device SWG: how it works.

The five steps

1. Export your current policy. Pull your URL categories, allow and block lists, and any DLP and app-control rules from your existing cloud SWG.

2. Translate policy into dope.console. Recreate the rules in one console. Because SWG, CASB, and DLP live together, you are not stitching policy across multiple products.

3. Deploy the agent through your MDM. Push dope.endpoint via Intune, Jamf, or your MDM of choice. No manual configuration on each machine. The agent is under 100 MB of RAM.

4. Run side by side. Keep the incumbent live while the agent inspects in parallel. Watch latency and AI activity on real traffic. Use the SSL error notifications to create bypasses for any pinned-certificate apps in a few clicks.

5. Cut over and decommission. Once policy and traffic check out, switch enforcement to the agent and retire the forwarding infrastructure.

What changes for your team

	Cloud-proxy SSE	On-device (Fly Direct)
Traffic forwarding	Tunnels, PAC files, connectors	None, inspection is local
Policy changes	Polling cycle, can take minutes	Real-time push from the console
Consoles	Often multiple products	One console for SWG, CASB, DLP
Rollout time	Weeks to quarters	Days to weeks via MDM

Proof the cutover is fast

The deployment record is the reason migration fear is usually overblown. A Fortune 100 customer scaled from 900 to more than 18,000 devices in weeks, averaging around 3,000 per week, deploying silently via Intune. Outreach Health secured 99% of its fleet within a week. Greylock Partners moved off a legacy SSE and signed in 27 days. One Cisco Umbrella customer migrated 2,000 machines in two days. None of them built a forwarding architecture, because on-device inspection has nothing to route.

Where to go by incumbent

If you are replacing a specific vendor, the direct comparisons pick up here:

Frequently asked questions

How hard is it to migrate off a cloud-proxy SSE? Usually easier than moving between two cloud proxies, because you remove the forwarding layer instead of rebuilding it. You translate policy, deploy an agent through your MDM, run in parallel, and cut over.

How long does migration take? Days to weeks for most teams. A Fortune 100 scaled past 18,000 devices in weeks; a Cisco Umbrella customer moved 2,000 machines in two days.

Do I have to rebuild my policy? You translate existing URL, app-control, and DLP rules into one console. Because SWG, CASB, and DLP are unified, you are not stitching policy across separate products.

What about apps that break under inspection? Certificate-pinned apps that reject inspection are surfaced as SSL errors, so admins create bypasses in a few clicks rather than hunting for them.

Can I run the new tool alongside my current one? Yes. Running side by side is the recommended step: keep the incumbent live, let the agent inspect in parallel, verify latency and policy on real traffic, then cut over.