From Qualys VMDR to Greenbone / OpenVAS

Qualys VMDR is sold as one platform and licensed as many modules, each per asset. That structure means the bill grows on two axes at once and the renewal conversation is never simply about how many machines you have. Greenbone replaces the scanning engine cleanly. What it does not replace is the platform around it, and the most common failure in this migration is treating a workflow platform as if it were a scanner.

There is also a specific architectural obstacle here that the Tenable path does not have to the same degree: the cloud-agent estate.

Enumerate the modules before anything else

Qualys estates accumulate modules, and people forget which ones are actually producing output somebody reads. Before scoping, list every licensed module and, for each, name the person who consumes its output and the process it feeds.

The replacements diverge sharply:

• Vulnerability Management → Greenbone. This is the only part Greenbone covers.
• Policy Compliance → OpenSCAP, or Wazuh’s SCA module if you are already running Wazuh.
• File Integrity Monitoring → Wazuh, or your EDR’s FIM capability.
• Patch Management → your existing patching tooling. Greenbone does not patch anything.
• Web Application Scanning → OWASP ZAP or a dedicated web scanner.
• Cloud Security Posture → a dedicated CSPM tool or your cloud provider’s native posture service.
• Asset Inventory → your CMDB, or the inventory your endpoint agent already produces.

Modules with no named consumer are the easiest saving in the entire project, and you can often stop paying for them before the migration starts. Modules with real consumers each need their own replacement decision, and pretending Greenbone covers them is how a migration produces angry stakeholders in month three.

The agent estate is the migration

Qualys cloud agents are installed on hosts and report continuously to the platform. That model has genuine advantages you are about to lose: laptops that connect from home report anyway, cloud instances report the moment they boot, and no scan window or firewall path is involved.

Greenbone is fundamentally a network scanner. So segment the estate:

Reliably network-reachable on a schedule. Datacentre servers, on-premise infrastructure, virtual machines in networks your scanner can reach. Credentialed network scanning covers these well, and arguably better than agents, since an authenticated scan sees the whole package state at a known moment.

Roaming endpoints. Laptops that are on the corporate network unpredictably. Options are scanning them when they connect via VPN (partial coverage, and you should be honest about how partial), or keeping a lightweight agent-based package inventory feeding a CVE matcher.

Ephemeral cloud compute. Instances that live for hours. The correct answer is scanning images in the build pipeline rather than instances at runtime, which is better practice than either agent or network scanning and worth adopting regardless.

Size each segment. If the roaming and ephemeral segments are large, the migration is a bigger architectural change than a scanner swap and should be planned as one.

QIDs, and why reconciliation is harder here

Qualys findings are keyed on QIDs, which are Qualys’s own check identifiers. This matters more than it sounds, because your exception register, your ticket references, your report filters, and your SLA tracking are all built on them.

Reconcile on CVE, as with any scanner migration, but expect a messier mapping than a one-to-one. A single QID may cover multiple CVEs. Many QIDs, particularly configuration and policy checks, have no CVE at all and need individual review against whatever replaces that module. And your accumulated exceptions are recorded against QID-plus-asset pairs that will not exist in the new system.

So plan two reconciliation passes. A CVE-level scan comparison, which is mechanical and tells you whether Greenbone is finding what Qualys found. And a manual review of non-CVE QIDs and open exceptions, which is a spreadsheet exercise somebody has to own.

Export the history before you serve notice

The exception register is the item most often lost, and it is the one an auditor will ask for.

Accepted risks, compensating controls, expiry dates, and the justifications behind them are decisions your organisation made, recorded in a platform you are leaving. Export the full register with justifications, owners, and expiry dates while the subscription is live. Export remediation history and trend data too, because “we reduced critical findings by X over two years” is the kind of claim that becomes unprovable the day access ends.

Then re-enter the still-valid exceptions into whatever becomes your system of record. For most teams that is DefectDojo rather than Greenbone, because Greenbone’s exception handling is thinner than a compliance programme needs.

DefectDojo is not optional at any real scale

Say this plainly in the plan. Greenbone scans and reports; VMDR is a workflow platform. The things you will miss are deduplication across multiple scanners, finding ownership, SLA tracking, exception management with expiry dates, and trend reporting over time.

DefectDojo does those, it is open, and it takes Greenbone output natively along with output from every other scanner you run. Deploy it as part of this migration rather than as a later phase, because the gap between “we have a scanner” and “we have a vulnerability management programme” is exactly this layer, and losing it while saving a licence is not a good trade.

Order of operations

1. Enumerate modules and their consumers, and stop paying for the unconsumed ones immediately.
2. Segment the estate into network-reachable, roaming, and ephemeral, and size each.
3. Plan a replacement per module, not one replacement for the platform.
4. Export the exception register, remediation history, and trend data while the subscription is live.
5. Deploy Greenbone and DefectDojo together, with the feed decision (Community or Enterprise) made deliberately.
6. Create fresh, minimally privileged scanning credentials, and confirm firewall paths to every segment.
7. Scan the same assets with both platforms in the same window and reconcile on CVE.
8. Manually review non-CVE QIDs and re-enter valid exceptions in DefectDojo.
9. Address roaming and ephemeral coverage with pipeline scanning or agent-based inventory.
10. Cut over per segment, uninstalling cloud agents only after that segment’s coverage is proven.

Clearing the bar before you cut over

Credentialed scans authenticate successfully across every platform in the estate. The CVE-level delta against Qualys is documented and explained. Non-CVE checks have a named replacement or a documented accepted gap. The exception register is exported, reviewed, and re-entered with expiry dates intact. Roaming and ephemeral assets have real coverage, not an aspiration. DefectDojo is live with ownership and SLAs configured. And the cloud agents are removed only from segments whose replacement coverage has been verified.

The short version

Qualys VMDR to Greenbone is a module-by-module replacement wearing the clothes of a scanner swap. The agent estate is the architectural problem, QIDs make reconciliation messier than a CVE-keyed migration, and the exception register is the asset you lose permanently if you do not export it first. Deploy DefectDojo alongside Greenbone from the start, because the workflow layer is what VMDR actually sold you. Model illustrative per-asset economics in the calculator above, and count the modules you are replacing separately rather than assuming one open tool covers the platform.