Broadcom’s acquisition of VMware brought Carbon Black into a portfolio managed on very different commercial principles, and endpoint customers have felt the same packaging and minimum-commitment pressure that vSphere customers did. The technology is still capable, which makes this a licensing-driven migration rather than a capability-driven one. Elastic Security is an unusual destination in this category because it is one of the few open-core options that both detects and genuinely prevents, so you are not forced into the detection-only compromise most open endpoint migrations require.
Why prevention changes the shape of the project
Most open destinations in endpoint security replace the detection half and leave you to source prevention separately, usually from OS-native controls. That works, but it means the migration carries an extra architectural decision and an extra deployment.
Elastic Defend, the endpoint integration that ships with the Elastic Agent, includes malware, ransomware, and memory-threat protection with blocking behaviour, in the free tier. That means the target architecture is a straight one-for-one agent swap rather than an agent-plus-prevention-layer redesign.
That said, “has prevention” and “prevents as well as the product you are leaving” are different claims, and only your own testing settles the second one. Build a validation suite before you deploy anything: EICAR as a smoke test, atomic red-team techniques mapped to the attacks you actually care about, and if you have the capability, a ransomware simulation in an isolated environment. Run it against both agents on the pilot ring. That comparison, not a datasheet, is what should authorise the rollout.
The mapping
- Carbon Black sensor → Elastic Agent with the Elastic Defend integration.
- The Carbon Black backend → your Elasticsearch cluster (self-hosted or Elastic Cloud).
- Carbon Black Cloud console → Kibana’s Security app.
- Watchlists → Elastic detection rules (KQL, EQL, or threshold rules).
- Process lineage / process analysis → the Elastic Security analyzer view.
- Reputation, approval, and banned lists → trusted applications, blocklist, and endpoint exceptions (data, not logic).
- Policies and sensor groups → Fleet agent policies and integration policies.
- Live Response → Elastic’s response actions (isolate host, terminate process, retrieve file).
- Alerts and triage → Elastic Security alerts plus its case management.
Elasticsearch is the real thing you are taking on
Be direct about this in planning, because it is where the cost that left the licence line reappears.
Carbon Black Cloud is a SaaS backend; capacity, retention, upgrades, and availability are the vendor’s problem. Self-hosted Elastic Security makes all of that yours. You will own index lifecycle management, shard sizing, node roles, hot and warm tiers, snapshot policy, and version upgrades of a distributed system that does not forgive careless configuration.
Endpoint telemetry is also high-volume by nature. Process, network, file, and registry events across a large fleet generate far more data than most teams anticipate, and retention length is now a direct storage cost rather than a plan feature. Size on events per second and target retention, put hot indices on fast local storage, and write the lifecycle policy before the first agent enrolls rather than after the disks fill.
If that is not a capability you have or want, Elastic Cloud is a legitimate answer. You keep the product and the portability of the data model while paying someone to operate the cluster, and the total is still typically well below a commercial EDR at enterprise scale. Choosing self-hosting purely for the licence saving and then under-resourcing the cluster is the outcome to avoid.
Rebuilding detection content
Elastic ships a large, actively maintained set of prebuilt detection rules mapped to MITRE ATT&CK, and they are genuinely good. Start there rather than porting everything.
Then migrate what is specifically yours. Custom watchlists written for your environment become custom detection rules, and the translation is query-language work rather than conceptual redesign. Elastic’s EQL is particularly well suited to the sequence-based logic Carbon Black watchlists often express (this process spawned that process, which then did this), so some watchlists actually get clearer in translation.
The reputation and approval data, approved hashes, banned hashes, trusted certificates, transfers as data into Elastic’s trusted applications and blocklists. Export it and import it rather than rebuilding by hand, and take the opportunity to review entries nobody can justify, because approval lists accumulate exceptions the way firewalls accumulate rules.
Rings, and the coexistence check
Run the migration in rings, as with any endpoint change, and do the coexistence testing seriously. Carbon Black’s sensor and Elastic Defend both operate at a low level, and running them together on the same host is exactly the scenario that produces performance problems and mutual suspicion.
Configure exclusions in both directions so neither agent treats the other as a threat, measure CPU and memory impact on every OS build in the estate, and confirm both are reporting before widening. Then, per ring: enroll the Elastic Agent, run the validation suite against both, confirm prevention actually blocks (not just alerts), confirm response actions work, and only then uninstall the Carbon Black sensor from those hosts.
Order of operations
- Build the validation suite first, so the rollout decision rests on evidence.
- Export watchlists, approval lists, and policy configuration while the console is live.
- Decide self-hosted or Elastic Cloud honestly, based on whether you have Elasticsearch operations capability.
- Stand up the cluster, with index lifecycle policy and retention decided before enrollment.
- Deploy Fleet and define agent policies mirroring your existing sensor groups.
- Enable prebuilt detection rules, then add custom rules translated from watchlists.
- Import approval and blocklist data as trusted applications and blocklists.
- Pilot ring across every OS build, testing coexistence, prevention efficacy, and performance.
- Roll out ring by ring, dual-running and tuning exceptions at each step.
- Uninstall the Carbon Black sensor per validated ring, reducing the licence count as you go.
Clearing the bar before you cut over
Per ring: the validation suite passes on Elastic with prevention actually blocking, custom detections fire on replayed real events, response actions (isolate, terminate, retrieve) execute successfully, agent performance is measured and acceptable on that OS build, alerts land in cases with the right routing, and cluster capacity has absorbed the ring’s telemetry with headroom. Only then does the old sensor come off.
The short version
Carbon Black to Elastic Security is one of the cleaner endpoint migrations available, because the destination actually prevents rather than only detecting, which removes the layered-architecture compromise most open moves require. The cost that leaves the licence line reappears as an Elasticsearch cluster, so decide self-hosted versus Elastic Cloud on capability rather than sentiment, and write the retention policy before the first agent enrolls. Validate prevention against your own test suite, not a datasheet. Model illustrative per-endpoint economics in the calculator above, and count the cluster and its operator as part of the real total.