Migrating SEPM 14.x to SES Complete: the engineer's playbook

Symantec Endpoint Protection Manager (SEPM) has been the backbone of enterprise endpoint security for two decades. Its successor - SES Complete, the cloud-managed evolution - has been generally available since the Broadcom acquisition and is now the strategic platform for new deployments. Most large enterprises run SEPM 14.x today, often on virtualized 2016 / 2019 servers with on-prem databases and aging reporting infrastructure. The pressure to migrate comes from three directions: end of support roadmaps for old SEPM versions, the rising operational cost of maintaining on-prem management infrastructure, and feature gaps (modern EDR, mobile, attack surface reduction) that exist only in SES Complete.

This playbook is what we run when CyberKIS leads a SEPM 14.x to SES Complete migration. It is built from running the migration across multiple enterprise environments, and it focuses on the parts that surprise teams who have not done this before. For the deeper product overview, see our Symantec Endpoint Security implementation page.

Why this migration matters now

Three forces converge in 2026. First, Broadcom has been clear that SES Complete is where ongoing product investment happens - new prevention engines, new EDR content, mobile and attack surface reduction modules ship to SES first and to SEPM only when (and if) they are backportable. If you are running SEPM 14.3.x, you are running a fully-supported product, but you are no longer running the strategic product.

Second, SEPM operational cost is rising. The on-prem stack requires Windows Server licensing, SQL Server licensing or Express limits, certificate management, a reporting database, patching, backup, and disaster recovery. Most teams we work with spend 0.25-0.5 FTE on SEPM operations alone. SES Complete moves all of that to Broadcom-managed cloud, with no agent rollout disruption.

Third, the EDR story is real. SES Complete bundles a full EDR capability - detection content, retention, threat hunting, response actions - that SEPM never offered. Organizations that bought SEP for prevention and a separate EDR tool (CrowdStrike, SentinelOne, etc.) often discover during the SES migration scoping that they can consolidate.

Phase 1: Discovery and current state (Week 1)

The success of every endpoint migration depends on knowing what you actually have, not what you think you have. Discovery is short but cannot be skipped. Start by extracting an inventory from SEPM: client groups, policy assignments, exception lists, application rules, scan exclusions, custom IPS signatures, and the trail of one-off policies that accumulated over years. Most environments have 30-60 distinct policy variations across groups - and most of those variations are unnecessary, layered for forgotten reasons.

Next, validate identity. SES Complete authenticates users and computers via Active Directory or Entra ID (Azure AD). If your on-prem AD integration to SEPM is healthy and your Entra ID sync (via Entra Connect or similar) is clean, you are ready. If not, fix identity before you start the migration - it is the most common cause of stalled rollouts.

Finally, inventory the agent fleet. Run a SEPM report showing agent version, OS version, last check-in, and managed status. You want to know how many endpoints are on the modern SEP 14.3.x agent versus older agent versions, how many are offline for extended periods, and how many are unmanaged. The older the agent, the more transitional work it needs.

Phase 2: Tenant prep and policy translation (Week 2)

Once Broadcom provisions your SES Complete tenant, two parallel work streams begin. The first is policy translation. You do not import SEPM policies directly; you re-author them in SES Complete based on the policy intent extracted in discovery. This is a feature, not a bug - most SEPM policy estates have accumulated 5-10 years of patches, exceptions, and edge cases that no longer serve their original purpose. The translation gives you a chance to clean up.

The second stream is integration. Configure AD or Entra ID as the identity source. Set up the SIEM forwarder (Splunk HEC, Sentinel, etc.) so the new tenant streams events from day one. Configure threat hunting workspaces and incident routing. Build the dashboards your operations team will live in.

Phase 3: Pilot (Weeks 3-4)

Choose 100-200 endpoints across IT, security, and a representative user population. Avoid finance and executives in pilot - too much political risk. Convert these agents from SEPM-managed to cloud-managed by pushing a configuration change from SEPM. The agent picks up the new manager URL and registers with SES Complete; no reboot, no user interaction, no reinstall. The conversion takes 10-30 minutes per agent depending on check-in interval.

For two weeks, run with enforcement disabled on SES Complete and enforcement enabled on SEPM. Watch what SES would have caught versus what SEPM caught. Build a feel for false positive rate differences. Tune policies and exceptions accordingly.

At the end of pilot, flip enforcement on SES Complete. SEPM continues to monitor but enforcement is now driven by the cloud. You are still running both; only one is taking action.

Phase 4: Production rollout (Weeks 5-8)

Roll out in waves. Typical wave structure: 10% (engineering and IT), 25% (general office workers), 25% (manufacturing or operational staff), 30% (remote workers), 10% (executives and finance - last, always last). Each wave runs for 3-5 days before the next starts, with daily check-ins on tickets, alerts, and user feedback.

Wave-of-rollout discipline is what separates clean migrations from ones that hit the help desk hard. Resist the temptation to "do them all on Friday." Slower waves give you time to catch policy issues before they affect 10,000 users.

Phase 5: SEPM decommission (Week 9-10)

Once every endpoint has reported in to SES Complete and the policy enforcement parity has held for two weeks, SEPM decommission begins. The sequence: disable replication if you had multiple SEPM servers, stop services, export the database for archival (most enterprises retain SEPM data for 1-2 years for compliance), uninstall SEPM components, decommission Windows Server VMs. Document the database export location in your retention catalog.

If you used SEPM for asset discovery or had third-party tools reading from the SEPM API, point those integrations at the SES Complete API before decommission. Common integrations: ServiceNow CMDB, asset management tools, security data lakes.

What to expect post-migration

The first 30 days post-cutover are exception tuning. You will discover policy edge cases that did not surface during pilot. The 30 / 60 / 90 day health check pattern works well - tune at 30 days, validate at 60, formal handoff to operations at 90. After 90 days, the operational rhythm shifts entirely into SES Complete with no further reference to SEPM.

The second 30 days are EDR enablement. If your SKU includes EDR (most SES Complete SKUs do), this is where you turn on detection content, configure threat hunting workspaces, and integrate with your SOC tools. EDR enablement is its own project - plan accordingly.

Common pitfalls we have walked into

Air-gapped or partially-disconnected endpoints. SES Complete requires cloud connectivity for management. Endpoints in restricted networks (OT, certain compliance zones) need either a proxy path or a hybrid deployment with on-prem management server bridging back. We have done both; both are documented; neither is fun.

Mac and Linux agent fragmentation. The conversion mechanics are different per OS. Windows is the cleanest. Mac requires updated Configuration Profiles via your MDM. Linux requires a manual or scripted reconfiguration. Budget time for each OS family separately.

Old SEP 14.x agent versions. Anything older than SEP 14.3 RU1 needs an agent upgrade before conversion. We typically do the agent upgrade and the cloud-conversion in the same wave to minimize user disruption, but it adds 5-15 minutes per endpoint depending on initial state.

Tenant region mismatch. If you have a global enterprise, you want the SES Complete tenant in the right region for data residency. This is settled at provisioning time and is difficult to change later. Check with Broadcom before the tenant is created.

What this looks like with CyberKIS

A typical CyberKIS SEPM-to-SES-Complete engagement runs 4-6 weeks for a 5,000-endpoint estate, 8-12 weeks for 20,000-50,000. We bring the playbook, the migration scripts, the policy translation framework, and engineers who have done this multiple times. You bring the AD and the access. We document everything, transfer knowledge to your operations team along the way, and leave you with a fully operational SES Complete deployment and a decommissioned SEPM.

Want to scope this migration for your environment? Talk to a CyberKIS engineer or read the Symantec Endpoint Security deep-dive for product specifics. Other migration playbooks: ProxySG to Cloud SWG, VPN to ZTNA in 90 days.