Open-source alternative to ServiceNow Discovery

GLPI Agent and GLPI's network discovery can replace ServiceNow Discovery for most inventory and CMDB feeds, but agent deployment and reconciliation change how the data is collected and kept current.

On this page

Can GLPI replace ServiceNow Discovery for our inventory?

If your ServiceNow CMDB is fed by Discovery and a renewal, cost change or residency requirement is forcing a decision, the short answer is that GLPI Agent inventory plus its network discovery covers most hardware and software collection that feeds GLPI's asset inventory and CMDB. Dependency mapping, and the depth of ServiceNow-specific Discovery patterns and probes, are the parts to confirm before you commit. The agent runs on Windows, macOS and Linux and also performs package deployment and remote ESX inventory, but it does not replace Discovery's relationship mapping by default, so test that gap against your own service models.

Start by listing what Discovery populates today: which CI classes, which relationships, how often scans run, and which feeds from the MID Server or other integrations depend on it. Then run GLPI Agent on a representative sample of Windows, macOS and Linux hosts, plus a network scan of one subnet you already know well, and compare the results field by field against your current CMDB. Agent-based collection means each endpoint reports on its own schedule and needs the agent deployed, configured and kept updated, which shifts effort from scan credentials and probe placement to deployment tooling and agent health monitoring. Agentless devices such as network gear, printers and appliances still need the network discovery path, so confirm which of them you can reach and with what credentials.

DeployOpen plans and implements this comparison inside your own environment, including agent deployment, scan scope and reconciliation rules for the CMDB. We prepare the configuration and evidence that your auditors may ask for, but DeployOpen does not issue audit reports or certifications, and independent assessors make that determination. Ask the team that will run the platform to confirm dependency mapping requirements, and ask us for a written scope that covers the agent rollout, the network discovery design and the validation results before any migration of CI data begins.

Which Discovery capabilities GLPI covers and where to confirm gaps

This table maps the main ServiceNow Discovery capabilities to GLPI Agent inventory, GLPI network discovery and inventory, configuration management and reconciliation rules. Read Covered as a function GLPI documents, Partial as a need met with limits, and Confirm as something to verify on the GLPI version you install. Dependency mapping depth and cloud connectors must be tested in your own environment before you commit to a design.

Discovery capabilityGLPI equivalentCoverage
Hardware and software inventoryGLPI Agent collects hardware and software inventory and sends it to GLPI's asset inventoryCovered
Network scanningGLPI Agent performs network discovery and inventory; confirm scan ranges, protocols and frequency for your networkPartial
Agentless discovery of unmanaged devicesNetwork discovery reaches devices without an agent, but their data is thinner than agent inventory; test on your device typesPartial
CI classificationDiscovered items map to GLPI asset types and configuration items; confirm how classification rules are written and maintainedPartial
Relationships and dependency mappingConfiguration management records links between items; confirm how much dependency data is discovered automaticallyConfirm
Cloud and virtualization discoveryGLPI Agent covers remote ESX inventory; confirm cloud connectors for each provider you runConfirm
Scheduling and credentialsConfirm how inventory schedules and network or remote credentials are set, stored and scoped in your installed versionConfirm
Reconciliation and deduplicationGLPI's rules engine matches incoming data to existing assets; confirm matching criteria against your data sourcesConfirm

GLPI Agent, network discovery and the alternatives to compare

ServiceNow Discovery combines agentless scanning with a CMDB population engine. In GLPI, the equivalent work is split between GLPI Agent on endpoints, network discovery run through a designated agent, and the asset and CMDB model in GLPI itself. The cards below set out each collection path and the CMDB-centric alternative for teams that need richer relationships.

GLPI Agent on endpoints

GLPI Agent is the successor of FusionInventory Agent and runs on Windows, macOS and Linux. It collects hardware and software inventory and sends it to GLPI, so each managed device reports its own configuration on a schedule. The trade-off is deployment: every device needs the agent installed, updated and allowed to reach the GLPI server. Before rollout, confirm the agent version you will standardize on, how it is pushed by your endpoint tooling, and which devices, such as appliances and network gear, cannot run it and must be covered another way.

Network discovery through a designated agent

GLPI Agent also performs network discovery and inventory, so one agent on a server or dedicated host in each network segment can scan for devices that have no agent. This is the closest GLPI equivalent to ServiceNow's agentless discovery. Results depend on scan scope, SNMP access and credentials, and which segments the designated agent can reach. Confirm the discovery ranges, the credentials you will manage, and how unidentified devices are reviewed before they become CMDB records.

Remote ESX inventory and package deployment

The same agent can perform remote ESX inventory, which collects data from VMware hosts without installing software on each one, and package deployment for software distribution. These capabilities matter for virtualized estates where installing agents on hypervisors is restricted. Check which ESX versions and credentials your change policy allows, and whether package deployment is in scope for your environment or should stay with your existing endpoint management tool.

Agent fleet and reporting controls

Collection quality depends on how agents are managed as a fleet: versions, check-in frequency, duplicate device handling and clean-up of retired assets. Without these controls, the inventory drifts, and the CMDB inherits stale or duplicate records. Define who owns agent health, how missing devices are reported, and how decommissioned hardware is removed. Ask the GLPI partner or your team to document these steps as part of the discovery runbook.

iTop for richer CI relationships

iTop, from Combodo under AGPL-3.0, is a CMDB-centered service desk with graphical impact analysis and a fully customizable CMDB. If your ServiceNow discovery feeds dependency maps, application services and business impact views, iTop models those relationships more directly than GLPI's asset inventory. The trade-off is a separate data model and integration work to keep it fed from collection tools. Confirm whether your dependency mapping needs live relationship data, which the agent-based collection in GLPI does not provide on its own.

Choosing where CI records live

Deciding whether discovered assets stay in GLPI or move into a CMDB-centric tool is the central architecture choice for this migration. Keeping everything in GLPI reduces the number of systems to run, while a separate CMDB adds relationship depth at the cost of another platform, another backup scope and another upgrade cycle. Document which record types each system owns, and which fields are authoritative, before you decide on a single system or a split.

What agent-based collection changes compared with agentless discovery

Agent-based collection changes where coverage comes from. GLPI Agent runs on each endpoint, collects hardware and software inventory on its own schedule and pushes the results to GLPI, so a device is visible only once the agent is installed and has checked in. Agentless discovery works the other way: a scanner reaches devices over the network using credentials and network paths, which means it can see equipment where no software was installed, but it needs accurate credential stores, open routes and scan windows. With agents, the question changes from "can the scanner reach this subnet?" to "is every managed device enrolled, and when did it last report?" Before you retire ServiceNow Discovery, export its current device list and compare it with the agent deployment to find the gaps.

This shifts ownership of inventory to endpoint management. The team that already deploys software, manages laptops and enforces patch and enrollment policy becomes responsible for installing and updating the agent, and the service desk owns the data quality that results. Offline laptops are the main operational difference. An agent on a laptop that is off the network for weeks simply has no new data, so GLPI shows a stale record rather than a failed scan. Decide in advance how long a record may go without a check-in before it is flagged, who reviews those records, and whether returning devices are reconciled by serial number or hostname. Confirm with your own deployment tooling how agent upgrades reach machines that rarely connect.

Agents report what is on the device, not how devices depend on each other, so the relationships that Discovery built from network and process evidence must be rebuilt deliberately. Map which applications run on which servers, which services depend on which databases and which network devices carry them, and enter those links as configuration item relationships in GLPI's configuration management or in a separate source you load by import. Plan for this as a design task with the application owners, not as a data export. Check which relationships your team must keep for change impact analysis and incident routing, and treat anything you cannot reconstruct from a reliable source as a known gap until the owners confirm it.

Moving Discovery feeds into GLPI without losing CI history

This sequence keeps the configuration items that Discovery has built up available as reference while GLPI Agent inventory takes over collection, so the CMDB is fed by a tested process before ServiceNow Discovery is switched off.

  1. Inventory current Discovery schedules and patterns

    The ServiceNow administrator lists every active Discovery schedule, the IP ranges and patterns each one covers, the MID Server that runs it, and the CI classes it populates, such as servers, network devices, databases and business applications. Record which classes are fed only by Discovery and which also receive data from other sources, because those rules decide what GLPI must cover. The step is done when the list is signed off by the owners of each CI class and every schedule has a named replacement or a documented reason for retirement.

  2. Export CI history within ServiceNow limits

    Export the CI records, relationships and Discovery timestamps that the CMDB needs for history, using list exports or scheduled export sets. Check each export against ServiceNow's record limits, since a list export that stops at the default cap will silently drop CIs. Compare row counts against the CMDB before and after export, and confirm that relationship tables are complete. The step is done when counts reconcile for every CI class in scope and the export files are stored in a controlled location.

  3. Deploy GLPI on a supported stack

    The platform team installs GLPI on a PHP version and a MariaDB or MySQL release that the current installation documentation supports, with the web server document root pointed at GLPI's public directory and URL rewriting in place. Back up the glpi.key and glpicrypt.key files alongside the database from the first day, because they are needed to restore encrypted data. The step is done when GLPI loads over HTTPS, the database backup runs on a schedule, and a test restore has been completed.

  4. Pilot GLPI Agent on a limited subset

    Deploy GLPI Agent to a small set of Windows, macOS and Linux hosts that cover the operating systems in scope, and configure network discovery against one or two subnets that Discovery already scans. The agent sends hardware and software inventory to GLPI, so compare what arrives with what Discovery recorded for the same machines, including serial numbers, installed software and IP addresses. The step is done when the pilot hosts appear in GLPI with fields that match the Discovery records, and every gap has an owner and an explanation.

  5. Set reconciliation and matching rules

    Define how GLPI decides that an agent-reported asset is the same as an existing CI, using identifiers such as serial number, asset tag and hostname, and decide what happens when two sources disagree. Agent-based collection reports from the device, while Discovery could pick up devices the agent cannot reach, such as network appliances, so document which source is authoritative for each class. The step is done when the rules are written, tested against the pilot data, and approved by the CMDB owner.

  6. Run Discovery and GLPI in parallel

    Keep ServiceNow Discovery running while GLPI collection expands to the full estate, and compare the two inventories on a regular basis. Track missing devices, duplicate records and attribute differences, and feed the findings back into the matching rules. Confirm that the GLPI data covers the fields used by change, incident and impact processes before relying on it. The step is done when discrepancies fall to an agreed level for every CI class and the remaining exceptions are recorded with a decision.

  7. Cut over and retire Discovery

    Switch the authoritative source for each CI class to GLPI, disable the Discovery schedules in the order they were inventoried, and keep the MID Server and the exported CI history available for reference until the team has confirmed that no process depends on them. Update the operational runbooks and the dashboards that read CI data. The step is done when the disabled schedules are logged, the runbooks reflect GLPI as the source, and the archived ServiceNow export has been verified and stored.

How the approach differs for cloud, on-premises and air-gapped estates

Cloud workloads and user laptops are usually the easiest part of the estate to inventory with GLPI Agent, because the agent runs on the device and sends its own hardware and software data to GLPI. Devices that move between networks, such as laptops used off site, only appear in inventory when they can reach the GLPI server or a relay that forwards to it, so check-in frequency matters more than scan ranges.

  • Agent deployment: GLPI Agent runs on Windows, macOS and Linux, so confirm each operating system in your fleet is covered before you plan the rollout.
  • Reporting path: Confirm whether laptops reach GLPI directly, through a proxy, or through a relay inside the network, and test from outside the office.
  • Cloud instances: Virtual machines created and destroyed by autoscaling leave stale records unless someone defines a retirement rule for assets that stop reporting.
  • Identity mapping: Agent-reported devices must be linked to users and locations in GLPI, which usually depends on how your directory is connected.
  • Agent updates: Ask who pushes agent upgrades to laptops and how that is tracked, since outdated agents collect different data.

Confirm the agent version, reporting interval and inventory fields with your own pilot group before scaling to the whole fleet.

Discovery replacement questions buyers ask

Does GLPI have a license fee that replaces ServiceNow Discovery cost?

GLPI itself is free software under GPL-3.0, so there is no license fee for the inventory or the GLPI Agent. The costs that remain come from the infrastructure that runs GLPI and its database, the effort to roll out agents across endpoints, the design of reconciliation rules that decide how collected data updates asset and CMDB records, and the staff time to run it. If you want a vendor-backed option, Teclib' publishes GLPI Network subscription prices: public cloud at 19 euros per user per month, private cloud at 21 euros per user per month with a 25-user minimum, and self-hosted subscriptions from 100 euros per month (Basic) to 4,500 euros per month (Enterprise). Ask Teclib' to confirm current terms before budgeting, since those are the only figures we can point you to.

What drives the total cost of replacing Discovery with GLPI Agent?

Four components drive the total. Hosting covers the servers or virtual machines for GLPI, the web tier and the MariaDB or MySQL database, plus backups. Agent rollout covers packaging, deployment through your existing endpoint tooling, and testing across operating systems. Reconciliation design covers deciding which sources win when agent data, network scans and manual records disagree, which is usually the largest effort. Staff time covers operating GLPI, reviewing discovered devices and handling upgrades. Estate size, the number of distinct device types and how much custom CMDB modeling you need push each component up. Ask any implementation partner for a written scope that lists each component separately.

How long does a Discovery replacement take to implement?

The duration depends on estate size, the number of endpoints and network segments to cover, and how much of the CMDB model you need to rebuild. A small estate with a simple model is a different project from a multi-site estate with custom classes and relationships. No fixed timeline applies across all engagements, so treat any figure you see as a guess until your environment is assessed. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ask for a phased plan that separates a pilot group of endpoints from the full rollout and from the reconciliation tuning that follows.

What access and credentials must we provide for GLPI discovery?

Before work starts, you will need to provide the following:

  • Endpoint management rights to install and configure GLPI Agent through your software deployment or configuration management tooling.
  • Network scan credentials or SNMP community and v3 user details for switches, routers, printers and other devices you want inventoried.
  • Read access to directory services and any existing CMDB or asset register you intend to reconcile against.
  • A hosting environment inside your own network or cloud account, with firewall rules that let agents reach the GLPI server.
  • Named owners who can approve reconciliation rules and resolve conflicting records.

Confirm each item against your own security policy, since credential handling and scan scope often need change approval.

Can our own IT team run a GLPI Discovery deployment without a partner?

Yes, many teams do this in-house, since GLPI and GLPI Agent are open source and the documentation covers installation and agent configuration. The work that tends to need outside help is designing reconciliation rules, tuning agent collection for your device mix, and hardening the server before it holds an accurate picture of your estate. Check honestly whether your team has time to run pilot rollouts, review discovered devices each week and handle GLPI upgrades, because those tasks recur. DeployOpen can plan, implement, customize, integrate, harden and document a GLPI deployment in your infrastructure, or provide ongoing support through a retainer, so you can decide which parts to keep in-house.

Does GLPI reach dependency mapping parity with ServiceNow Discovery?

Not as a like-for-like feature. GLPI Agent collects hardware and software inventory, performs network discovery and inventory, and supports package deployment and remote ESX inventory, and GLPI covers configuration management and custom asset definitions. Discovery's automated relationship mapping between application services, processes and infrastructure is a different model, so you should not assume an equivalent exists. Confirm in a proof of concept which relationships you need, whether they can be modeled as GLPI items and links, and whether they must be maintained by hand. Compare this against the ServiceNow vs GLPI module review before you commit.

How do we avoid duplicate or stale CMDB records after switching discovery?

Duplicates usually appear when agent records, network scan results and manually entered assets describe the same device under different identifiers. Define one authoritative identifier per device type, such as serial number or hostname with a fixed domain, and set rules for which source updates which fields. Schedule regular review of devices that have not reported within your chosen window, and decide whether those records are retired or flagged. Run the old and new discovery side by side for a set period so you can compare results before ServiceNow Discovery is switched off. Ask your implementation partner to show the reconciliation rules in writing before rollout.

Where should GLPI and its discovery data be hosted for compliance?

Host GLPI inside your own data center or cloud account so inventory, user records and network scan results stay under your control. The compliance question is about where the data lives, who can access it and how it is backed up, not about any certification GLPI holds. GLPI's update process requires backing up the database, files and the configuration directory with its key files, so include those in your retention plan. DeployOpen prepares systems, controls and evidence for compliance assessments, but independent auditors and certification bodies issue any audit report or attestation. Ask your auditor which evidence they expect for asset inventory and access control.

Running GLPI alongside the rest of ServiceNow during cutover

The parallel run works only if every configuration item has one system of record at any given time. Most teams cannot switch Discovery off on day one, so ServiceNow ITOM keeps discovering some classes of CI while GLPI Agent inventory comes online for others. Before the first GLPI agent is deployed, export the list of CI classes and the scope of each ServiceNow discovery schedule, then assign each class a single owner in writing: ServiceNow, GLPI, or a named exception. Without that register, the same server will appear as a Discovery CI and as a GLPI asset, and reconciliation becomes a manual project.

Duplicates usually come from identity, not from data. Agent-based records in GLPI are keyed by the device, while ServiceNow Discovery keys CIs by its own identification rules, so the same laptop or virtual machine can be created twice with different names. Decide early which attribute is authoritative for matching (serial number, asset tag, or hostname within a defined domain), test the match on a pilot group, and confirm with your ServiceNow administrator how the Discovery identification engine is configured so the two systems do not disagree. Treat any device that reports to both systems as a defect to resolve, not as expected overlap.

The rest of the ITSM suite can stay in ServiceNow for as long as the wider migration is still being scoped. Incidents, changes and service catalog items may keep referencing CIs that now come from GLPI, which means the integration between the two must be checked, not assumed. Confirm with your ServiceNow team which tables and reference fields the suite reads from discovered CIs, and decide whether GLPI or ServiceNow is the source for each of them during the overlap. Record the cutover date for each CI class in the same register, so that switching ownership is a planned change, not a silent drift.

How DeployOpen scopes and delivers a Discovery replacement

DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For a Discovery replacement, that means agreeing in writing which networks, endpoints and asset records GLPI Agent will cover, then building and documenting the inventory and CMDB feed in your environment.

How we scope

  • Inventory the network segments, operating systems and subnets that Discovery covers today in your ServiceNow instance.
  • Agree which CI classes, asset fields and relationships GLPI must hold, and which ones you will retire.
  • Record the scope, deliverables and timeline in writing before work starts, since engagements are fixed-scope.

How we build

  • Deploy GLPI and configure GLPI Agent collection on Windows, macOS and Linux endpoints in your own accounts or data centers.
  • Set up network discovery and inventory jobs, and test them against a sample of subnets before wider rollout.
  • Integrate authentication with your directory and secure the GLPI instance, including backups of the database and glpi.key files.

How we hand over

  • Document the agent deployment method, discovery schedules, inventory data model and the reconciliation steps used.
  • Provide a runbook for adding new subnets, handling agents that stop reporting and applying GLPI upgrades safely.
  • Walk your operations team through the handover so they can run inventory without depending on the implementation team.

How we support

  • Ongoing support, upgrades and continuous testing are available as a retainer after handover.
  • Retainers can cover GLPI version upgrades, plugin reactivation after major updates and inventory health reviews.
  • Ask us to confirm agent coverage and data accuracy against your own environment at each review point.

Sources and further reading

Talk to our team.

Tell us what you're working on, whether it's a deployment, an audit, a security test or a cyber range. You'll speak with an engineer who can help you scope it.

  • 30-minute call: free, with no obligation.
  • NDA on request: we can sign before you share details.
  • Clear next steps: a scope and plan after the call.