Cisco Umbrella served mid-market IT teams well as a DNS-layer security product. With legacy Umbrella SKUs hitting end-of-sale in September 2025 and software maintenance ending September 2026, the migration clock is running. The question is no longer whether to move, but how to do it without breaking DNS resolution, losing SIEM visibility, or creating a protection gap during cutover.
This post is a 60-day playbook. Four phases: 14 days of discovery, 21 days of parallel deployment, 14 days of DNS cutover, and 11 days of decommissioning. The highest-risk moment is the DNS switch in Phase 3. The rest is methodical project management.
If you need background on why Umbrella’s architecture creates limitations for mid-market teams, the Cisco Umbrella vs Jimber comparison covers the feature-level analysis. This post assumes you have decided to migrate and need execution certainty.
The 60-day migration timeline at a glance
Replacing Cisco Umbrella with a single-vendor SASE platform takes 60 days across four phases: discovery and planning (14 days), parallel deployment (21 days), DNS cutover and validation (14 days), and decommissioning (11 days). The critical path runs through the DNS cutover in Phase 3, where resolver changes propagate across your network and any misconfiguration causes immediate connectivity loss.
| Phase | Days | Main activities | Output | Risk level |
|---|---|---|---|---|
| 1. Discover | 1-14 | Policy export, integration mapping, vendor selection | Project plan and RFP | Low |
| 2. Deploy | 15-35 | Parallel deployment, agent rollout, policy build | Functioning new stack alongside Umbrella | Medium |
| 3. Cutover | 36-49 | DNS switch, validation, monitoring | Production migration complete | High |
| 4. Decommission | 50-60 | Contract cancellation, agent removal, audit | Closed Umbrella tenant | Low |
Phase 1 (days 1-14): discovery and planning
Every failed SASE migration traces back to an incomplete discovery phase. These 14 days prevent the surprises that turn a controlled migration into a fire drill.
Audit your current Umbrella implementation
Start with an export of everything Umbrella controls.
Policy export. Use the Umbrella Management API v2 to pull destination lists, DNS policies, web policies, and firewall rules. The /policies/v2/destinationlists endpoint exports custom domain lists as JSON. The admin console allows CSV export of destination lists manually. Export both.
DNS resolver documentation. Identify every device, DHCP scope, and Group Policy Object that references Umbrella’s resolvers: 208.67.222.222 and 208.67.220.220 for IPv4, 2620:119:35::35 and 2620:119:53::53 for IPv6. Check routers, firewalls, Windows DNS servers with conditional forwarders, and hardcoded resolver entries on servers. The most common migration failure is a forgotten DNS entry on a single branch router that keeps sending queries to Umbrella after cutover.
Investigate API integrations. Document every script, playbook, and SOAR workflow that calls the Investigate API. These integrations require a rebuild against the new vendor’s threat intelligence API.
SIEM connectors. Umbrella typically exports logs to an Amazon S3 bucket encrypted with AES-256. Splunk uses the Cisco Umbrella Add-on. Microsoft Sentinel uses an Azure Function or REST API connector. Document the log format, retention period, and custom dashboards built on Umbrella data. SIEM connector rebuilds account for 15-20% of total migration effort in security platform transitions (Gartner, 2025).
Custom block pages and SAML SSO. Export any customised block page HTML and document your identity provider integration, whether Microsoft Entra ID, Okta, or on-premises AD Connector.
Map features to your new platform
| Umbrella feature | SASE equivalent | Migration effort |
|---|---|---|
| DNS-layer filtering (phishing, malware, C2) | DNS security module | Low, destination list import |
| Intelligent Proxy (grey domain inspection) | Full SWG inline proxy | Medium, broader coverage |
| Investigate threat intelligence API | Vendor-specific threat feed | High, API schema change |
| Content category filtering | SWG URL categories | Low, category mapping review |
| CASB / shadow IT discovery | CASB module | Low to medium |
| Cloud-delivered firewall (CDFW) | FWaaS | Medium, rule translation |
| S3 log export | Platform-native logging | High, SIEM connector rebuild |
| AD Connector / SAML | Identity provider integration | Low |
| Custom block pages | Block page editor | Low, different syntax |
The biggest conceptual shift is from Umbrella’s “Intelligent Proxy” to a full Secure Web Gateway. Umbrella only proxies traffic to risky or unknown domains. An SWG inspects 100% of web traffic inline, which requires deploying a root certificate to every managed endpoint for TLS inspection.
Build the project team and select a vendor
A 200-user migration needs five roles (project manager, network engineer, identity admin, security analyst, helpdesk lead). In lean mid-market IT teams, one person often covers two.
If you have not yet selected a replacement platform, focus on: cloud-native architecture versus virtualised appliance heritage, DNS and web security in a single policy engine, agentless device support for IoT and OT, SIEM log schema documentation, and time-to-first-policy. The seven-criteria SASE vendor evaluation framework covers this in depth. For a detailed breakdown of how SASE architecture works, the architecture guide explains single-pass inspection, PoP distribution, and policy enforcement models.
Phase 2 (days 15-35): parallel deployment
Running your new SASE platform alongside Umbrella for three weeks lets you validate policies and catch integration issues before they affect production traffic.
Deploy in parallel and migrate DNS policies
Start with 10-20% of your users: office-based staff, remote workers, and at least one branch office. Avoid the executive team as pilot. Choose users who report issues accurately and tolerate minor inconveniences during the validation period.
The parallel phase means both platforms run simultaneously. Umbrella handles the majority of users. The pilot group routes through the new platform. This dual-stack approach requires careful DNS scoping to prevent traffic leaking between platforms. Configure the pilot group’s DHCP scope or MDM profile to use the new SASE resolvers, while the rest of the network continues using Umbrella.
Export Umbrella destination lists as CSV and import them into the new platform. Before importing, review every list manually. Deployments running for years accumulate stale entries: domains that no longer exist, temporary blocks from past incidents, and overly broad wildcard rules. Run a two-week comparison: apply the same intended policy on both platforms and compare what each blocks. The delta reveals translation gaps.
Umbrella’s content category taxonomy does not map perfectly to other vendors. “Security” category blocking in Umbrella may cover different threat types than the equivalent category on your new platform. Document every discrepancy and adjust policies before Phase 3.
Set up identity and rebuild integrations
Connect your identity provider. Verify that the UPN format matches what Umbrella used. A mismatch between user@company.com and DOMAIN\user breaks policy enforcement silently.
For SIEM rebuilds, replace the Umbrella data source entirely. Splunk needs a new add-on or HEC input. Sentinel needs a new data connector and rebuilt analytics rules. Budget 3-5 days for Sentinel, 2-4 days for Elastic or QRadar. SOAR playbooks calling Umbrella’s Enforcement API require a full rewrite against the new platform’s API.
Deploy the new vendor’s root certificate via GPO, Intune, or Jamf. Allow a full seven-day window. Do not enable TLS inspection until certificate deployment reaches 95%+ coverage, or users will face browser warnings on every HTTPS site.
Single-vendor SASE platforms with multi-tenant architecture, including Jimber, handle service partner access natively. Verify that your partner’s admin access maps correctly to the new console.
Phase 3 (days 36-49): DNS cutover and validation
This is the highest-risk phase. DNS underpins every internet connection. A misconfigured cutover means users cannot reach anything.
DNS cutover strategies
| Strategy | Best for | Rollback time | Risk |
|---|---|---|---|
| Gradual rotation | 200+ users | Minutes per subnet | Low |
| Hard cutover | Under 50 users | 15-30 minutes | Medium |
| Dual-resolver transition | Not recommended | Unpredictable | High |
Gradual rotation is recommended. Change DHCP scopes one subnet at a time, starting with the subnet that performed best during pilot. Wait 24 hours between subnets. Dual-resolver setups sound safe but create unpredictable behaviour: most operating systems prefer whichever resolver responds fastest, not which is listed first.
The cutover playbook
- Lower DNS TTL to 300 seconds one week before cutover.
- Pre-cutover validation. From a test machine on the new resolvers, resolve 50 representative domains. Confirm resolution under 50ms and blocked domains returning custom block pages.
- Update DHCP scopes to the new SASE resolvers. Push via Group Policy or MDM for endpoints.
- Wait for DHCP lease propagation (8-24 hours). Do not force-renew all leases simultaneously.
- Monitor for 48 hours. Track resolution success rate (target 99.9%+), latency (under 50ms), and NXDOMAIN responses for domains that should resolve.
- Validate policy enforcement across three network segments.
- Decision point. Clean metrics for 48 hours means cutover is complete. Degradation triggers rollback.
Common pitfalls
Split-brain resolution. Any device still pointing to Umbrella’s resolvers operates under old policies while the rest of the network uses the new platform. This creates an invisible protection gap. Run a network scan post-cutover specifically checking DNS settings on routers, servers, and network appliances.
DNSSEC chain breaks. If the new SASE platform handles DNSSEC validation differently than Umbrella, certain secure domains may become unreachable. Test DNSSEC-signed domains during the pilot phase, not during production cutover.
IPv6 edge cases. Umbrella’s IPv6 resolvers (2620:119:35::35) may exist on devices your IPv4-focused audit missed. Dual-stack servers and network equipment are the usual culprits.
Agent conflicts. Both the Cisco Secure Client and the new SASE agent should never be active simultaneously on the same endpoint. They compete for control of the routing table and DNS settings, causing unpredictable resolution behaviour. The parallel phase should have validated this, but verify again at scale.
Cached entries. Even after DHCP changes, endpoints cache DNS responses until TTL expires. Lowering TTL to 300 seconds in advance (step 1) limits this window to five minutes rather than hours.
Rollback strategy
Revert DHCP scopes to Umbrella resolvers (208.67.222.222, 208.67.220.220). Force DHCP renewal on critical servers. Verify resolution through Umbrella. Do not delete Umbrella network identities or cancel the subscription until Phase 4 is complete.
Phase 4 (days 50-60): decommissioning
Validate, remove agents, close the contract
Confirm zero DNS traffic reaching Umbrella by checking the dashboard’s Activity Search for the past 72 hours. Any queries appearing mean a device or network segment was missed during cutover. Run a network scan to identify endpoints or appliances with hardcoded DNS entries still pointing to 208.67.222.222.
Compare the new platform’s threat blocking statistics against pre-migration baselines. The numbers will not match exactly because policy logic differs, but the order of magnitude should be consistent. A 200-user organisation blocking 500 threats per day on Umbrella should see comparable or higher numbers on the new platform. A significant drop suggests a policy translation gap that needs investigation.
Remove the Umbrella Roaming Client from every endpoint. It binds to port 53 on the loopback address and intercepts queries even after the service stops. Deploy an MDM script that stops the Umbrella_RC service, runs the uninstaller, clears registry keys under HKLM\SOFTWARE\OpenDNS, and resets adapter DNS settings. Remove the Umbrella root certificate from trust stores.
Notify Cisco of non-renewal in writing. Most contracts auto-renew with 30-60 day notice periods. Export final compliance reports and activity logs before tenant deactivation. For NIS2-regulated organisations needing 12-24 months of searchable logs, transfer historical data to your SIEM before closing the tenant.
Schedule a 30-day post-migration review comparing threats blocked, resolution latency, false positive rates, and SIEM alert coverage against pre-migration baselines. Document the entire migration for NIS2 Article 21 compliance and as a template for future platform transitions.
What catches most teams off guard
Custom policies nobody remembers. Deployments running 3+ years accumulate destination lists created by staff who have left. Review each against current requirements.
Hidden API integrations. Security analysts write quick scripts calling the Investigate API that live in personal folders or SOAR playbooks. Send a targeted email asking about Umbrella API usage.
Logging gaps during transition. During parallel operation, security events split between platforms. Neither has complete visibility. Communicate reduced SIEM coverage to your security team and compliance stakeholders.
SIEM rebuild underestimation. Rebuilding dashboards, alerts, and automated workflows for a new log schema takes 30-40 hours for a typical mid-market deployment. Budget this explicitly.
Certificate deployment lag. Devices that are powered off or disconnected may take days to receive the new root certificate via MDM. Enable TLS inspection only above 95% coverage. Devices on slow VPN connections or those rarely restarted are the last to receive GPO-pushed certificates. Track deployment progress through your MDM reporting before toggling TLS inspection to “enforce”.
Frequently asked questions
Can I run Cisco Umbrella and a new SASE platform in parallel during migration?
Yes. The parallel phase runs both platforms simultaneously. Umbrella handles the majority of users while the pilot group routes through the new platform. Keep both active until Phase 4 decommissioning.
What happens to my Investigate API integrations?
Investigate access stops when your Umbrella subscription ends. There is no cross-vendor equivalent. Rebuild threat hunting workflows against your new platform’s threat intelligence API during Phase 2.
Will my Umbrella contract automatically renew if I miss the cancellation deadline?
Most contracts include auto-renewal with a 30-60 day notice period. Submit non-renewal notification in writing during Phase 4 and retain confirmation. Missing the deadline can commit you to another 12-36 month term.
What is the typical downtime during DNS cutover?
Zero, if executed correctly. Gradual rotation changes DHCP scopes one subnet at a time. Users experience the change transparently at their next DHCP lease renewal.
Do I need to remove the Umbrella Roaming Client from every endpoint?
Yes. The Roaming Client binds to port 53 on the loopback address and intercepts DNS queries even after the service stops. Incomplete removal causes intermittent resolution failures.
Can I migrate to a non-Cisco SASE platform without retraining my team?
The concepts transfer directly. DNS filtering, web policies, identity-based access, and SIEM integration work on the same principles. Budget 2-3 days for admin training. Some single-vendor SASE platforms, including Jimber, reduce the learning curve by consolidating all policy management into a single console rather than separate dashboards for DNS, web, and firewall policies.
How does CASB capability compare between Umbrella and a SASE platform?
Umbrella’s higher tiers include basic CASB for shadow IT discovery. Most unified SASE platforms provide more comprehensive CASB in SASE, including inline DLP, app-level policy controls, and integration with the same identity source that governs all other access.
Sixty days from now, your Umbrella tenant can be closed, your DNS traffic flowing through a unified SASE platform, and your SIEM rebuilt with complete visibility. The broader SASE implementation timeline covers how this migration fits into a larger platform rollout. If your team is planning a Q3 or Q4 migration, Jimber offers a parallel deployment setup where you run the platform alongside Umbrella from day one, with no commitment until you are ready to cut over. Book a demo to scope your migration.
