Can an open-source CMDB replace the ServiceNow CMDB?
For many estates, yes: GLPI or iTop can replace the ServiceNow CMDB module, with GLPI strongest on inventory of hardware and software and iTop strongest on modeling relationships between configuration items and running impact analysis. Which one fits depends on the configuration item (CI) classes you actually use. If your ServiceNow CMDB is mostly servers, laptops, licenses and their contracts, GLPI covers that ground with less modeling work. If your value sits in application-to-service dependencies and change impact, iTop's customizable CMDB is the closer match. Either way, the CI classes in use are the first thing to inventory, because each class needs an equivalent definition on the open-source side before any data moves.
Two parts of the estate do not carry over on their own. ServiceNow Discovery, which populates the CMDB from the network, needs a separate replacement, such as GLPI Agent inventory and network discovery, and the feed from every integration that writes CIs into ServiceNow must be rebuilt as an import or synchronization job. Confirm with your own team which integrations and scheduled jobs write to the CMDB today, since those are easy to miss in a renewal review. Also confirm that the relationship types and custom attributes you rely on can be expressed in the target tool before you commit.
Plan the CMDB decision as a data ownership question, not only a feature comparison. Ask who maintains CI records after go-live, which teams are allowed to change them, and how stale records will be detected. Request a written statement from each vendor or implementation partner covering the CI classes in scope, the import method for each source, and the work needed to keep the database current. Those answers, not the feature lists, determine whether the open-source CMDB stays accurate once the commercial one is switched off.
How ServiceNow CMDB capabilities map to GLPI and iTop
This table compares the CMDB capabilities teams typically use in ServiceNow with what GLPI and iTop cover. Read each row as a question to test against your own class model, and treat a check mark as a starting point to confirm in a proof of concept rather than a sign-off.
| ServiceNow capability | GLPI coverage | iTop coverage | Notes |
|---|---|---|---|
| CI classes and custom class models | Configuration management with asset types and custom asset definitions | Fully customizable CMDB with its own class model | iTop is designed around extending classes; confirm each ServiceNow CI class you need has a counterpart before migrating |
| Relationships between CIs | Links between items and related objects; depth of relationship modeling is limited compared with iTop | Typed relationships between objects, visible in the object graph | Confirm the relationship types your change and incident workflows depend on in each product |
| Configuration management and item lifecycle | Asset status and inventory records, with contracts and financial data alongside | Lifecycle states can be modeled per class | Map ServiceNow lifecycle states to each product's states before importing records |
| Graphical impact analysis | Limited: confirm whether the relationships you need can be traversed in the interface | Graphical impact analysis is a core iTop feature | Gap risk is highest for GLPI if impact analysis drives change approval |
| CSV import | Imports through the web interface and CSV files for assets and related objects | CSV import is a documented feature | Export from ServiceNow first; CSV handles flat records more reliably than deep relationship chains |
| Data synchronization and federation | Inventory arrives through GLPI Agent; cross-instance synchronization needs confirmation | Data synchronization for federation is a documented feature | Plan the source of truth for each CI before enabling any synchronization |
| Data consistency audits | Duplicate and completeness checks depend on your configuration; confirm in your version | Data consistency audits are a documented feature | Run audits on a copy of imported data before go-live |
| Automated discovery feeding the CMDB | GLPI Agent collects hardware, software and network data without a MID Server | Relies on imports, synchronization or integrations; confirm the collectors you need | Replacing ServiceNow Discovery is a separate decision, covered on its own page |
| Reporting and dashboards | Built-in reports and dashboards for assets and service data; confirm the ones you need | Reporting and dashboards are included; confirm against your required reports | Build the report list from current ServiceNow reports before choosing |
GLPI or iTop: which CMDB fits which estate
Both GLPI and iTop can hold configuration items, relationships and asset records outside ServiceNow, but they model the CMDB differently and suit different estates. The cards below set out where each product's CMDB strengths lie, how data gets in, and what each stack requires to run.
GLPI configuration management and asset definitions
GLPI manages configuration items through its asset types, with custom asset definitions that let you add the fields your estate needs beyond the built-in classes. Its CMDB sits inside a broader ITSM suite that also covers incidents, problems, changes, contracts and a knowledge base, so asset and service records share one database. Check whether your CI classes and relationships map onto GLPI's asset model before you commit, since the relationship modeling is less granular than a dedicated CMDB.
iTop's customizable CMDB and impact analysis
iTop is built around a fully customizable CMDB, so you can define CI classes and the relationships between them to match how your services depend on infrastructure. Its graphical impact analysis shows which services, users and contracts are affected by a change or outage, which is often the main reason CMDB-centered teams choose it. Plan time to design the data model, because the value of impact analysis depends on relationships being recorded accurately.
GLPI Agent as an inventory feed
GLPI Agent collects hardware and software inventory from Windows, macOS and Linux endpoints and sends it to GLPI, and it also performs network discovery and inventory. This replaces much of the discovery role that ServiceNow Discovery plays, but it is agent-based, so you must deploy, update and monitor the agent on every device you want in the CMDB. Confirm which device types, network ranges and remote ESX inventory your estate needs before assuming full coverage.
iTop data synchronization for federation
iTop's data synchronization lets one iTop instance pull and align CI data from another, which suits estates split across business units, regions or subsidiaries that need a shared view. Federation adds design work: you must agree which instance is the authority for each class, how identifiers match, and how conflicts are resolved. Test synchronization with a sample of real records before you rely on it for change approvals.
iTop Community limit and paid editions
iTop Community is free for up to 10 agents, while Atelier covers up to 50 agents and Forge covers more than 50, each available on premises or as SaaS. The agent count is the license driver, so count the people who will work in the service desk, not only the people who request tickets. Ask Combodo to confirm how agents are counted and what support, training and consultancy each edition includes.
PHP and MariaDB runtime requirements
GLPI 12.0.0 requires PHP 8.3 or later and MariaDB 10.11 or later or MySQL 8.0 or later, while iTop 3.3.x requires PHP 8.2 to 8.4, MySQL 5.7 or later or MariaDB 10.6 to 11.8, and GraphViz for its impact diagrams. Both run on the LAMP-style stack your team may already operate, but the PHP and database versions differ and so do the upgrade paths. Confirm the exact versions in the release notes and the requirements pages before you size the server.
How CSV import and data synchronization move CI data
CSV import is the most direct way to move exported ServiceNow CI records into iTop or GLPI, but it carries flat rows, not the connected model you had. iTop's README lists CSV import as a built-in feature, and GLPI's asset and configuration management can be fed the same way, so the first job is to export configuration items class by class and map each ServiceNow field to an iTop attribute or GLPI asset field. Expect that relationships between CIs do not come across in a plain CSV load. Dependencies, hosting links, and service-to-CI mappings must be rebuilt as their own import files or entered in the tool. Change history, work notes, and attachments are also outside a standard CSV load. Decide before the cutover whether historical records are archived in a read-only export, and whether attachments are carried over through a separate extraction, as the sibling page on exporting from ServiceNow describes.
For iTop, data synchronization is the mechanism for federation, meaning several iTop instances that hold part of the same CMDB and keep shared objects aligned. Confirm with Combodo which synchronization sources and targets your edition supports before designing the topology, because the answer determines which instance is the system of record for each CI class. Whatever mechanism you use, the reader should run data consistency audits after every load and on a schedule afterward. An audit reports records that break the rules of the data model, such as CIs without an owner, orphaned relationships, or duplicate names, so drift from manual edits and repeated imports is visible rather than silent. Set an owner for the audit findings, and treat a clean audit as an acceptance criterion for each migration wave.
Running the CMDB alongside the rest of ServiceNow
This split is common when incidents and changes stay in ServiceNow for now, but configuration items are being held in GLPI or iTop. The risk is that ServiceNow still references CIs in tickets, change requests and service mappings while the authoritative record lives somewhere else. Every reference that points at a retired CI table becomes a stale link, and every new CI created in the new CMDB must be visible to ServiceNow workflows that expect it.
- Pick one owner per CI class: Decide which system is authoritative for servers, network devices, business services and applications, and write that down before any sync starts.
- Re-point inbound integrations: Scripted imports, REST callers and MID Server jobs that write to ServiceNow CI tables need a new target or a documented retirement date.
- Freeze CI edits in ServiceNow: Make ServiceNow CI tables read-only for the migrated classes so changes cannot diverge silently.
- Keep the CI key stable: Carry an external identifier from ServiceNow into the new CMDB so tickets and changes can still be matched to the right item.
- Test change impact: Confirm that change risk and impact checks in ServiceNow still resolve when the related CI is served from the other system.
Before cutover, ask the vendor or your own team to confirm which integration hooks, such as business rules or flow actions, read CI data directly.
If ServiceNow Discovery remains active, it keeps writing CI records and relationships into ServiceNow while you build replacement feeds. The main hazard is duplication: Discovery may create a server record that GLPI Agent inventory also creates under a different name or identifier, leaving two entries for one device. Discovery scheduling, credentials and probes also have dependencies that change once the feed moves.
- Map identifiers before feeds overlap: Match serial number, hostname and MAC address rules between Discovery and GLPI Agent so duplicates are found during the parallel run.
- Run feeds in parallel for a defined window: Compare what each source reports for the same device and record the differences.
- Retire Discovery per network segment: Turn off scheduled scans one segment at a time, not all at once, so gaps are visible.
- Review relationship data: Discovery builds dependency maps that agent inventory does not produce on its own, so decide whether those relationships come from another source or are rebuilt manually.
- Watch for stale records: Set a rule for how long a CI can go without an update before it is flagged or archived.
Confirm with your own environment team which Discovery patterns and probes are in use, since a partial retirement often leaves some device classes without any feed.
When the entire service desk leaves ServiceNow, the CMDB is only one part of the cutover. Incidents, problems, changes, service catalog items and approval flows all reference CIs, so the CMDB move has to be sequenced with ticket migration. Running ServiceNow alongside a new ITSM for a period is possible, but every ticket must be assigned to one system so that work is not split between two queues.
- Set a single cutover date for ticket ownership: Open tickets stay in the system where they were created, and new tickets go only to the new platform after that date.
- Migrate CIs before tickets: Load configuration items first so that migrated tickets can link to them without broken references.
- Rebuild approval and workflow logic: Workflows, SLAs and catalog items do not carry over as data, so plan them as separate work items.
- Redirect integrations last: Monitoring alerts, HR feeds and email intake should switch only after the new service desk accepts test records.
- Keep an archive of ServiceNow records: Retain exports for audit and reference, marked as read-only.
Ask for a written list of every integration, scheduled job and report that touches CI data, and confirm it is either re-pointed or retired before ServiceNow access is removed.
Migrating CI classes, relationships and owners
This sequence turns ServiceNow's CI classes, relationships and ownership data into a tested CMDB in GLPI or iTop, with a pilot load proven before any feed is switched over. The output is a populated, audited inventory that the team trusts enough to use for change and incident work.
Inventory CI classes and relationships in ServiceNow
Work with the ServiceNow administrator to list every CI class in use, its record counts and the relationship types that connect them, such as runs on, depends on and hosted on. Filter out classes that nobody populates, because they add migration effort without adding value. The output is a signed-off inventory that maps each class to a business purpose, which the target design will use as its checklist.
Define target classes in GLPI or iTop
Decide which ServiceNow classes become GLPI asset types with custom definitions, or iTop classes in its customizable data model, and which ones collapse into a shared type. Confirm how each target platform represents relationships, since GLPI's configuration management and iTop's impact analysis model links differently and must be checked against the platform documentation. The output is a written data model reviewed by the CMDB owner and the teams that consume it.
Export data within ServiceNow's export limits
Extract CI and relationship records from ServiceNow in batches small enough to stay within its default export limits, and keep the exports in a controlled location with a record of what was extracted and when. The step-by-step method, scheduled exports and REST extraction for attachments are covered in the sibling guide on exporting from ServiceNow. The output is a set of versioned extract files with row counts that match the source reports.
Map fields and relationships
Build a field-level mapping from each ServiceNow column to a GLPI or iTop attribute, and expect relationships to need rebuilding rather than direct transfer, because the exported relationship tables do not carry over as native links. Write the rules for identifiers, status values and dates, and flag any field with no target so the decision is explicit. The output is a mapping document approved by the data owner and used as the input for the import files.
Load a pilot set through CSV import
Prepare CSV files for one business service and its dependent CIs, then load them through the target platform's CSV import into a non-production instance. Check that object identifiers resolve, that relationship rows link to the correct parents, and that rejected rows are logged with a reason. The output is a pilot load report that lists imported, updated and rejected records, which is used to correct the mapping before the full load.
Run consistency audits
Run the platform's data consistency audits on the full load and compare results with the pilot findings, looking for orphaned CIs, duplicate names, missing owners and relationships pointing to retired items. Record each exception with an owner and a decision to fix, accept or retire it. The output is an audit log showing that the open exceptions are known and assigned, which becomes the baseline for later reconciliation.
Reconcile owners
Match each CI's owner, support group and business service in ServiceNow against the users, groups and teams defined in the target platform, using the directory integration that will authenticate users. Resolve records with departed owners or unclear support groups with the service owners, not only with IT. The output is a list of every CI with a confirmed owner, with any gaps tracked to a named person and date.
Cut over feeds
Repoint discovery agents, integrations and scheduled imports from ServiceNow to the new CMDB in a planned sequence, starting with the feeds that create or update CIs most often. Keep ServiceNow read-only for the cutover window so that no record changes in two places, and confirm each feed writes to the new data model. The output is a documented feed inventory with each source confirmed as writing to the new CMDB, with a rollback path agreed before the switch.
Questions buyers ask before replacing the CMDB
What does the CMDB migration effort depend on most?
The effort depends mostly on how many configuration items exist, how many CI classes and relationships ServiceNow uses, and how clean the existing records are. A CMDB with a small set of well-understood classes and current data moves far faster than one with years of duplicate records and undocumented relationships. Also count the integrations that write to the CMDB today, because each one must be replaced or re-pointed. Ask your team to produce a class-by-class inventory before anyone estimates the work.
What drives the cost of replacing the ServiceNow CMDB?
Cost is driven by the license model you choose, the hosting you run, the implementation work and the people who operate the result. Open-source software carries no license fee, but hosting, data mapping, integration rebuilds and ongoing administration still cost money. For GLPI, the vendor's subscription page lists GLPI Network public cloud at 19 euros per user per month and 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), per the GLPI Network subscriptions page. Support is optional. Ask every vendor and partner for a quote built from a written scope.
Which CMDB costs are one-time and which recur?
One-time costs usually include discovery of the current estate, data extraction, mapping, cleanup, the initial import, integration rebuilds and user training. Recurring costs include hosting, backups, patching and upgrades, support contracts if you buy them, and the staff time that keeps data current. For iTop, Combodo offers Community free for up to 10 agents, Atelier for up to 50 agents and Forge for more than 50 agents, per combodo.com, so the license line recurs with the agent count. Confirm with each vendor whether licenses are perpetual or subscription based.
Can our team migrate and run the CMDB without outside help?
Some teams can, especially when they already administer a PHP and MySQL or MariaDB application and have a named owner for each CI class. The harder part is usually not the software but the data decisions: which classes survive, who owns each relationship, and which records are retired. Teams without database and web server administration experience, or without time to clean data, often bring in a partner for the migration and hand over the runbook. A fixed-scope engagement, agreed in writing before work starts, makes that split explicit.
How long does a CMDB migration take for our estate size?
Duration depends on the number of CIs, relationships, integrations and the quality of the source data, so no general timeline applies. A useful planning step is to measure those four inputs and then ask for a timeline in the written scope. Combodo's requirements page suggests an all-in-one iTop server with 2 vCPU and 4 GB of memory for fewer than 200 tickets a month and under 20 console users, and separate web and database servers of up to 8 vCPU and 16 GB for larger installations, per the iTop software requirements page. Those figures size the platform, not the project.
What does the work need from our side?
The project needs named business and technical owners for each CI class, access to current discovery or inventory data, and time from people who know which records are wrong. Expect to decide what happens to stale, duplicate and orphaned records before import, because a CSV import copies whatever it receives. You will also need a window to validate impact analysis and reports against your service map. Ask the implementation partner to list these inputs, with dates and owners, in the written scope.
How do we keep the CMDB current after ServiceNow Discovery is gone?
Plan at least one automated source for each class of CI before cutover. The GLPI Agent collects hardware and software inventory, runs on Windows, macOS and Linux, and can perform network discovery and inventory, according to the GLPI Agent documentation. For iTop, the README describes CSV import, data consistency audits and data synchronization for federation. Decide which source is authoritative for each attribute, schedule audits, and confirm with the vendor how each connector handles deleted assets, because stale records are the most common cause of a CMDB losing trust.
Keeping the CMDB accurate once Discovery is gone
A CMDB stays accurate only when someone owns it as an ongoing operation, and that owner has to be named before the first import runs. Once ServiceNow Discovery is retired, the replacement is a schedule: GLPI Agent runs on endpoints and reports hardware and software inventory to GLPI, and its network discovery and inventory features cover devices that cannot host an agent. Assign a CMDB owner who approves changes to asset classes and relationships, and separate ownership of each source (agent inventory, CSV imports, manual entries from contracts or procurement) so every record shows where it came from. Confirm with your own environment which agent deployment tool you will use to push and update agents, since the GLPI Agent documentation covers the agent itself, not your rollout.
Reconciliation rules decide what happens when two sources disagree about the same device, such as an agent report that conflicts with a purchase record or a serial number that appears under two names. Write these rules down before the first scheduled collection: which source wins for hardware fields, how stale records are flagged, when a device is retired rather than deleted, and who reviews duplicates. Test the rules on a sample of assets from each source. In iTop, the data consistency audits and data synchronization features can enforce some of these checks, so confirm in a pilot which checks you can automate and which need a person to review.
Periodic audits close the loop. Schedule a recurring comparison of CMDB records against the agent inventory, the contract register and a physical or logical sample of the estate, and log every exception with an owner and a closure date. Staff this as a recurring task for named people, not a project that ends at go-live, and keep the runbook, reconciliation rules, audit results and agent deployment records in a document set that an auditor or a new administrator can read. Ask any implementation partner to price this as a retainer or as recurring internal effort, because it is the cost that most often disappears from the budget after migration.
Checks to run before you commit to a target
This sequence tests whether GLPI or iTop can hold the CMDB you actually run today, at the scale and stack you can support. Each step closes with a finding you can take into a vendor conversation or a proof of concept. Confirm every item below with the vendor or in your own environment before you commit.
Inventory your current CI classes and attributes
Your CMDB or platform owner exports the list of configuration item classes in use, with the attributes and reference fields each one carries, and marks which ones drive incident routing, change approval or impact reports. Count the classes that are used in practice rather than only those that exist in the schema. The output is a one-page class register that becomes the baseline for every later check.
Map each class to GLPI or iTop equivalents
The CMDB owner and an architect map each class to a GLPI asset type with custom asset definitions, or to an iTop class in its customizable data model. Mark every class with no clean match, and note where a custom field or extension would be needed. Confirm the mapping against the GLPI assets documentation and the iTop documentation, since class coverage depends on the version you test. The output is a mapping sheet with gaps flagged in a separate column.
Test relationship depth in a proof of concept
Load a representative sample of configuration items and relationships into a test instance, including a service that spans several servers, databases and network devices. Check whether the target can express each relationship type your reports depend on, and whether it can query them in both directions. The output is a short list of relationship types that work as-is, those that need configuration, and those that have no equivalent.
Validate impact analysis against real change scenarios
Pick three or four recent changes or outages from your records and ask the test instance to show what they would affect. Compare the results with what your team actually found at the time. iTop lists graphical impact analysis among its features, and GLPI covers configuration management, so confirm how far each one traces dependencies in your setup. The output is a pass or fail note per scenario, with the reason for any miss.
Size the target against Combodo's suggested server profiles
Compare your monthly ticket volume, console user count and expected CI count with the sizing Combodo suggests for iTop: an all-in-one server with 2 vCPU and 4 GB of memory for fewer than 200 tickets a month and under 20 console users, and separate web and database servers of up to 8 vCPU and 16 GB for larger installations. Ask GLPI's team or Teclib' for equivalent guidance. Run the proof of concept at production-like data volume before you accept any sizing. The output is a sizing note that states which profile you need and what you still need to verify.
Confirm the PHP and database stack your team can run
Check the target's current requirements against your standard platform. iTop 3.3.x requires PHP 8.2 to 8.4, supports MySQL 5.7 or later and MariaDB 10.6 to 11.8, prefers MariaDB, and needs GraphViz. GLPI 12.0.0 lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later on its README, while its installation docs list different minimums for GLPI 11.0. Confirm which versions your operating system and security baseline allow. The output is a signed-off stack list that your platform team accepts.
Assess whether your team can run upgrades
Ask the operations lead to walk through one upgrade in the proof of concept, including the backup of the database, application files and config directory, the replacement of application files, and the database update command. For GLPI, note that plugins are suspended after a new version is detected and must be reactivated after major updates. Record who performs each step and how long your team needs for each, based on what you observe. The output is a runbook draft and a named owner for each upgrade task.
Decide on support and record open questions
List the questions the proof of concept did not answer, such as class gaps, licensing for your agent count, or support tiers, and send them to the vendor or Combodo, Teclib' and your own platform team in writing. For iTop, note that the free Community edition covers up to 10 agents, and Atelier and Forge cover larger agent counts. Review the answers against your requirements before you decide. The output is a written decision record that names the target, the open items and the owner of each one.
How DeployOpen scopes and delivers a CMDB replacement
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For a CMDB replacement, that means turning your existing configuration item classes and relationships into a scoped, tested and documented GLPI or iTop deployment that your team can run after handover.
How we scope
- Inventory which ServiceNow CI classes, relationships and reports your teams actually use before choosing GLPI or iTop
- Agree in writing which data sources feed the CMDB, such as GLPI Agent inventory, CSV imports or iTop data synchronization
- Define the written scope, deliverables and timeline before work starts, since most engagements are fixed-scope
How we build
- Model asset types, CI classes and relationships in the target platform, including custom asset definitions or iTop CI classes
- Load and reconcile exported records through CSV import, then run data consistency checks on duplicates and orphaned items
- Configure authentication, web server, PHP and MariaDB or MySQL settings according to the platform's installation documentation
How we hand over
- Document the data model, import procedures, feed schedules and the steps to keep the CMDB current without Discovery
- Provide runbooks for backups of the database, files and configuration keys, plus the update procedure for your chosen release
- Walk your administrators through daily CMDB upkeep, so your team can maintain the data after handover
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Repeat data consistency audits and inventory feed checks as your estate changes and new platform releases ship
- Confirm with you which parts of compliance readiness, such as evidence for controls, your auditors will need to review
