Why open source IT asset management and CMDB projects stall after discovery
GLPI handles inventory-first asset management, where agents report what is actually installed on endpoints and servers, and iTop handles a highly customized CMDB, where you define the classes, relationships and lifecycle states your service model needs. Which one fits depends on how your data must be modeled and reconciled, not on which product installs faster. Most projects that stall do so after discovery has already produced a large inventory, because the hard part is deciding which source wins when endpoint agents, server records, network scans, monitoring tools and procurement spreadsheets describe the same device in different ways. A single authoritative record per asset is a design decision you must make before import, and it is rarely made by the people who install the software.
Installation is a few weeks of configuration. Reconciliation and ownership run for the life of the platform. Expect duplicates where a laptop reports a hostname, a serial number and a MAC address that do not match the purchase order, and expect monitoring tools to know about devices that the asset register has never seen. Decide in writing which key identifies an asset (serial number, asset tag, hardware UUID or a composite), which system is the master for each attribute such as owner, cost center or location, and what happens to a record that no discovery source has seen for a defined period. Ask your partner to show how the chosen platform's data consistency audits and synchronization features would flag these conflicts, and confirm the behavior of your chosen version against your own sample data before you commit to a design.
After go-live, the risks move to people and process. Someone must own each asset class, approve new CI types, retire records that are no longer real and review exceptions from the discovery agents on a schedule. Without named owners and a recurring review, the inventory drifts within months and users stop trusting it. Plan for the agent rollout and the reconciliation rules as one workstream with clear roles for the service owner, the procurement contact and the team that runs monitoring. Ask any implementation partner who maintains the data model after handover, how changes are versioned, and what the support scope covers, because those answers determine whether the CMDB is still accurate when your next audit or incident review asks for it.
Requirements an open source IT asset management and CMDB must meet
This table maps each inventory, tagging, network and retention requirement to its source and to what it means for the build. Read it as a checklist for scoping the CMDB before selecting GLPI or iTop, because several rows depend on decisions about classes, discovery coverage and record retention that are hard to change after go-live. Confirm each regulatory scope with your counsel and assessors before design sign-off.
| Requirement | Source | What it means for the build |
|---|---|---|
| Complete inventory of endpoints, servers and network devices | ISO/IEC 27001:2022 Annex A control 5.9 (asset inventory), referred to by ID only | Agent-based discovery on Windows, macOS and Linux plus network discovery must cover every asset class in scope. Define the authoritative source for each class and reconcile gaps regularly. |
| Tagging of assets that store or transmit ePHI | 45 CFR 164.312(b) audit controls for systems containing ePHI | Add a data-classification field or CMDB relation that flags ePHI systems, so audit logging scope can be drawn directly from the CMDB rather than from memory. |
| Mapping of network segments that carry ePHI | 45 CFR 164.312(e)(1) transmission security for ePHI over electronic networks | Record subnet, VLAN and network-device relations for ePHI paths in the CMDB. Confirm with your security team how discovered segments will be linked to these records. |
| Retention of records for firms subject to SEC Rule 17a-4 | 17 CFR 240.17a-4(b)(4), three-year preservation of business communications | Set retention rules for ITSM records and attachments, and confirm with counsel whether asset and ticket records fall in scope before configuring purge or archive jobs. |
| Authentication of CMDB administrators | GLPI user documentation: authentication order of internal database, LDAP, IMAP and other external methods | Decide which directory governs administrator access. Because GLPI tries methods in order, confirm the internal database fallback is restricted or disabled for privileged accounts. |
| Traceable changes to asset and CMDB records | Audit expectations under ISO/IEC 27001:2022 change control and HIPAA audit controls | Enable history logging for asset and relation edits, and export logs to central storage. Test that a sample change can be traced to a named administrator and timestamp. |
| Data currency after go-live | Internal inventory policy aligned with ISO/IEC 27001:2022 control 5.9 | Agree on agent check-in expectations, stale-asset rules and a periodic reconciliation with monitoring and procurement data, with named owners for each. |
How GLPI Agent inventory differs across Windows, macOS, Linux and network scans
The GLPI Agent runs on Windows and is the successor of FusionInventory Agent. On Windows endpoints it collects hardware and software inventory and sends it to GLPI, which is the core of the endpoint record that the CMDB and asset register depend on. The same agent can also be used for network discovery and package deployment, but each of those functions should be enabled deliberately rather than assumed from the installation.
- Hardware and software inventory: the agent reports hardware and installed software to GLPI, giving you the baseline for the asset record.
- Package deployment: confirm whether your design uses this function and who approves the packages it deploys.
- Deployment method: confirm whether the agent is pushed by your endpoint management tool, a GPO, or a manual installer, and who owns that process.
- Privileges: confirm which account the agent service runs under and which collection tasks need elevated rights in your environment.
- Unmanaged Windows devices: the agent only reports where it is installed, so confirm how laptops that are off the network or personal devices will be found.
Before go-live, check that the installed software list matches what your software asset management team expects on a sample of machines.
The GLPI Agent also runs on macOS, so Apple endpoints can report to the same GLPI asset model as Windows machines. The collected data is the same category of hardware and software inventory, but the practical rollout differs because macOS fleets are often managed through a separate mobile device or endpoint management platform. Plan the agent deployment as part of that tooling, not as a separate manual step.
- Hardware and software inventory: the agent reports machine and application data to GLPI for the asset record.
- Deployment channel: confirm whether installation and updates are delivered through your MDM or endpoint management product and who controls the package.
- Permissions: confirm which privacy and administrative permissions the agent needs under your macOS management profile and whether users can alter them.
- Ownership mapping: confirm how the agent links a machine to a user, since shared and loaned Macs can distort the asset-to-person relationship.
- Unmanaged Apple devices: confirm how BYOD Macs, or Macs that are not enrolled, will appear in your inventory or be excluded from it.
Check that the collected software names for common macOS applications are consistent with your license records before you reconcile them.
The GLPI Agent runs on Linux, which is often where server and infrastructure inventory matters most. The agent reports hardware and software inventory to GLPI, and the same platform family is common for virtual machines and hosts that are not visible to end-user management tools. Confirm the distributions and init systems you run, because packaging and service management differ from one distribution to the next.
- Hardware and software inventory: the agent reports host, package and hardware data that can be matched to server records in the CMDB.
- Packaging: confirm the installation package format your distributions use and whether it is available from your internal repository.
- Service account: confirm which user the agent runs as and what read access it needs to hardware and package data.
- Server ownership: confirm how hosts are tagged to applications, environments and owners, because the agent records what is installed, not who is accountable.
- Unmanaged hosts: confirm how servers outside the agent rollout, such as appliances or legacy systems, will be discovered or recorded manually.
Compare the host list from the agent with your cloud and virtualization inventory to find hosts that were never enrolled.
Network discovery and inventory is a separate function from the endpoint agent. According to the GLPI Agent documentation, the agent can perform network discovery and inventory and can collect inventory from ESX hosts remotely. This reaches devices that have no agent installed, such as printers, network equipment and virtualization hosts, but the depth of what is found depends on the scan configuration and the protocols your devices answer.
- Network discovery and inventory: the agent can scan address ranges and record devices it finds, which helps identify unmanaged assets.
- Remote ESX inventory: the agent can collect inventory from ESX hosts without installing software on each host, so confirm the access account and permissions you will grant.
- Scan scope: confirm which subnets, VLANs and address ranges are in scope and who approves scanning them, especially on segmented or operational networks.
- Device coverage: confirm which device types respond to your chosen discovery methods, since not every device will be identified or classified correctly.
- Change control: confirm how scan results are reviewed before they update the CMDB, so new or unexpected devices do not enter the record unchecked.
Run a scan in a test segment first and compare the results with a manually maintained list before scheduling broader discovery.
GLPI or iTop for IT asset management and CMDB: which fits and why
GLPI and iTop both cover inventory and configuration data, but they start from different places. The cards below separate the decisions that matter most for an asset inventory and CMDB, from data model and discovery to licensing, runtime requirements and paid support. Start with how complex your CMDB model needs to be and what reporting you must produce.
GLPI for inventory-led asset management
GLPI fits organizations whose first priority is an accurate hardware and software inventory with a broad asset and contract model. The GLPI Agent collects hardware and software inventory, performs network discovery and inventory, and runs on Windows, macOS and Linux, so discovery is built into the platform. Check whether your contract, license and financial data needs fit GLPI's native modules before you plan custom work.
iTop for a customizable CMDB
iTop is built around a fully customizable CMDB model, so classes, attributes and relationships can match how your services and dependencies are structured. Its graphical impact analysis shows what a failing component affects, which matters when change and incident reviews depend on dependency maps. Expect more design work up front to define the model, and plan it before importing data.
Federation and data synchronization
iTop supports data synchronization for federation, which can help when several instances or departments must keep shared configuration items consistent. GLPI is not designed around the same federation pattern, so multi-entity estates should be modeled and tested before choosing a platform. Ask any partner to demonstrate how conflicting records and ownership are resolved between instances.
Licensing and modification obligations
GLPI is distributed under GPL-3.0, and iTop is distributed under AGPL-3.0. Both licenses carry source-sharing obligations when you modify and distribute the software, and AGPL-3.0 extends those obligations to network use of modified versions. Have your legal team confirm how your planned extensions, integrations and internal hosting fit each license before the design is fixed.
Database and PHP runtime requirements
GLPI 12.0.0 lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, while iTop 3.3.x requires PHP 8.2 to 8.4, supports MySQL 5.7 or later and MariaDB 10.6 to 11.8, and needs GraphViz. Confirm your database and PHP standards against these ranges with your platform team. Check the current requirements pages for the exact release you plan to deploy.
Optional paid services from each vendor
Teclib' offers GLPI Network as a managed service, with subscriptions for public cloud, private cloud and self-hosted deployments. Combodo sells commercial support, training and consultancy for iTop, and offers its editions on premises or as SaaS. These are optional and recurring, so ask each vendor and your partner to separate what the subscription covers from what implementation work will cost.
Reconciling asset records with monitoring and procurement data
A CMDB stays accurate only when every attribute has one authoritative source, and that rule has to be written down before any data is loaded. Procurement should own ownership, contract, purchase and warranty fields. Discovery should own state: whether a device exists, what hardware and software it reports, and when it was last seen. Monitoring should supply operational status such as up, down or degraded, but it should not overwrite hardware records. Assign each attribute to one source in a reconciliation matrix, and have the CMDB owner sign it off before the first import.
Matching keys decide whether two records describe the same configuration item. Serial numbers are the strongest key for physical hardware, hostnames are useful but change, MAC addresses change with network cards and virtual interfaces, and cloud instance IDs are stable within a provider account but not across accounts. Re-imaged machines and virtualized hosts create duplicates when a new record appears with the same hostname or a cloned identity. Define which key wins when keys conflict, how a re-imaged device is linked to its previous record, and when a record is retired instead of merged. The exact logic must be designed and tested in your environment against a sample of real hosts, because agents, network scans and imports can each report the same device differently.
Route every unresolved match, conflicting attribute and missing serial number into an exception queue with a named owner, a target response time agreed internally and a closure reason. In iTop, CSV import and data consistency audits can flag records that break the rules, and in GLPI, inventory from the GLPI Agent can be compared against existing asset records and procurement lists. Confirm both tools' current matching and deduplication behavior with your own test data before relying on them. Schedule reconciliation runs after each import and after each discovery cycle, and track the exception count over time, since a rising queue usually signals a broken key or a new source that was never mapped.
Deployment pattern for a self-hosted CMDB in your own network
A self-hosted CMDB touches your network, databases, identity and monitoring from day one, so the deployment decisions matter as much as the data model. The cards below cover sizing, placement, agent paths, backup, runtime versions and integration points, in the order most teams need to settle them.
Start with an all-in-one sizing baseline
Combodo 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. Above that, the same guidance points to separate web and database servers of up to 8 vCPU and 16 GB each. Treat these as starting points, not commitments: your discovery volume, the number of CMDB objects and reporting load can push you past them. Confirm sizing with a test load before production, using realistic inventory counts from a pilot group.
Place the server and database inside your network
Keep the iTop application server and its database on infrastructure you control, in a management or service zone that only your administrators and integration hosts can reach. Decide early whether the web tier faces users directly or sits behind your existing reverse proxy and load balancer. The database should accept connections only from the iTop web tier, never from user segments.
Map agent traffic across segmented networks
Inventory agents on endpoints and network discovery probes in other segments must reach the GLPI or iTop collection endpoints, and in many designs they also need a path to the server for updates. Each segment, DMZ or OT zone usually needs its own firewall rule, so list every source subnet and destination port before rollout. Confirm these paths with your network team in a lab, because a blocked path often looks like an empty inventory rather than an error.
Back up database, files and configuration keys
A CMDB restore is only useful if it brings back the data and the settings that read it. Schedule backups of the database, the application files and the configuration directory, including the keys that protect stored credentials in GLPI. Test a restore on a separate host at least once before go-live, and store copies outside the server's own failure domain. Record who may access backup media, since it contains asset and network data.
Match PHP and database versions to the release
iTop 3.3.x requires PHP 8.2 to 8.4 and supports MySQL 5.7 or later and MariaDB 10.6 to 11.8, with MariaDB preferred and MySQL 8 discouraged for performance reasons. GLPI 12.0.0 requires PHP 8.3 or later and MariaDB 10.11 or later or MySQL 8.0 or later. Pick the platform first, then fix the PHP, database and GraphViz versions on your operating system baseline, and check them again before each upgrade.
Plan integration points before go-live
The CMDB becomes useful when it reconciles with other systems. Identify the monitoring tool that will confirm which configuration items are alive, the directory that supplies users and owners, and the procurement or finance source that holds purchase and contract records. For each, decide whether the flow is manual import, scheduled sync or API, who owns conflicts, and which system wins when two records disagree. Confirm the connector options with the vendor for your versions.
Evidence an auditor asks for from the asset inventory
This table maps the evidence an assessor typically requests about an asset inventory to the GLPI or iTop component that produces it and what it shows. Read it as a preparation checklist: each row names a record that should exist before the assessment starts, not a finding. DeployOpen prepares these systems, controls and exports for the client, but independent auditors and certification bodies issue the audit reports and conclusions.
| Evidence item | What it shows | Produced by |
|---|---|---|
| Inventory exports with discovery dates | Which assets were known, when they were first and last seen, and their owner or location at each export | GLPI assets module, with scheduled exports retained outside the live database |
| Agent run logs and coverage reports | Which endpoints reported on each run, failed or skipped runs, and the share of the estate covered | GLPI Agent on Windows, macOS and Linux, and GLPI network discovery logs |
| Reconciliation exception records and closure | Assets that appear in monitoring or procurement data but not in the CMDB, with the decision and date on each exception | GLPI or iTop tickets linked to the affected asset records, plus the reconciliation export |
| CMDB change history linked to change records | Who changed an asset or configuration item, what changed, and which approved change record authorized it | iTop change management and CMDB history, or GLPI change records with asset links |
| Data consistency audit results | Orphaned relations, missing mandatory attributes and duplicate objects found by the audit and their remediation | iTop data consistency audits, run on a schedule and kept as dated reports |
| Administrator access records | Which administrators signed in, which sessions were active and revoked, and which privileged actions required step-up authentication | GLPI 12.0.0 active session view and step-up authentication, plus web server and database logs |
| Backup and configuration key custody | That the inventory database, files and encryption keys can be restored together after a failure | Documented GLPI backup procedure covering the database, files and config directory, with restore tests |
Rollout of an open source CMDB from first discovery to steady state
This sequence moves a CMDB from a spreadsheet and partial inventory to a reconciled, owned and maintained record of assets and configuration items, with each phase closing on a named output that the next phase depends on.
Scope CMDB classes and data owners
Agree which configuration item classes the CMDB will hold in the first release, such as endpoints, servers, network devices, software and contracts, and name a data owner for each class. The workshop should also define the mandatory attributes for each class, the source that is authoritative for each attribute and the reports that consumers such as security, finance and operations need. This step is done when the owners have signed a class and attribute list and know which fields the first release will not cover. Confirm with your own stakeholders which classes are regulated or audited, because those usually need stricter ownership.
Select platform and size the deployment
Choose between GLPI and iTop, or a combination, based on the scope from the previous step, the agent discovery model you need and the skills in your team. Size the database and web tiers against the expected number of agents, assets and console users, and confirm the supported PHP and database versions for the release you select. Vendor requirements pages, such as the GLPI installation prerequisites or the iTop software requirements, are the right source to confirm supported versions before you order hardware or virtual machines. The step closes with a written architecture note and a test instance that the team can log into.
Run pilot discovery on one segment
Deploy the inventory agent and, where needed, network discovery to a single, well-understood segment, such as one office network or one data center rack. Compare what the tool finds with the team's known list of devices and note every gap, duplicate and unknown device. Use the pilot to tune discovery ranges, credentials, scheduling and the rules that match a discovered device to an existing asset record. The pilot is complete when the owner of the segment accepts the discovered inventory as accurate and the list of open issues is short and assigned.
Roll out agents by operating system
Deploy the GLPI Agent to Windows, macOS and Linux endpoints and servers in waves, one operating system family at a time, so that packaging, permissions and check-in behavior can be verified for each. Confirm how each platform is managed, including software distribution, privileges and any endpoint security product that may block the agent. Track check-in rates per wave and investigate devices that never report. The step is done when the agreed population reports on schedule and the exceptions list, including devices that cannot run an agent, is documented with an owner for each.
Reconcile with monitoring and procurement data
Match the discovered inventory against your monitoring tool's host list and against purchase and contract records from procurement or finance. Create a reconciliation report that lists assets seen only in discovery, assets seen only in procurement and assets in monitoring without a CMDB record. Resolve each category with a named owner, and agree which system wins when two sources disagree on the same attribute. The step closes when the unmatched count is small enough that each remaining item has a documented reason, and the agreed authoritative source for each attribute is recorded in the data ownership model.
Cut over and retire the spreadsheets
Freeze the spreadsheet inventory on an agreed date, load the reconciled records into the CMDB and tell asset owners that the CMDB is the only place to change records. Keep a read-only copy of the old spreadsheet for audit reference and set a date by which it is archived. Update requests, change records and reports so they point to the CMDB, and check that no team still maintains a parallel list. The step is complete when the spreadsheet is no longer used for updates, every consumer report runs from the CMDB and the archive location is recorded.
Operate the CMDB with owners and upgrades
Establish a steady-state model with a named owner for each class, a recurring review of data quality and discovery exceptions, and a set cadence agreed with the business for reviewing the CMDB against monitoring and procurement. Plan upgrades as controlled changes: back up the database, the files and the configuration directory with the encryption keys, such as glpi.key and glpicrypt.key in GLPI, apply the new release, and run the database update step. After a major GLPI update, reactivate plugins and retest reports. Record each upgrade as a change so the evidence trail stays complete.
Questions to ask an implementation partner about CMDB scope
Start by asking how the partner will decide between GLPI and iTop for your data model. GLPI is built around inventory, assets, contracts and financial management, and has native inventory through the GLPI Agent. iTop is built around a fully customizable CMDB with change, service and impact analysis. Ask the partner to map your required classes (servers, network devices, business services, applications, contracts) against each tool, to name the classes that would need custom development, and to show which relationships drive your impact analysis. Ask who owns the data model decision in writing and what evidence they will present before you commit. Also ask how they will measure discovery coverage: the answer should be a defined comparison of the GLPI Agent's inventory results against your directory, your network address records and your endpoint management tooling, reported per site and per device class, with a named owner for the gap list and a date by which each gap is closed or formally accepted. Next, ask how reconciliation rules and owners will be documented. Request the written rule for each source of truth: which system wins for hostname, serial number, owner, location and lifecycle status when the monitoring tool, the procurement system and the discovery agent disagree. Ask who approves those rules, who resolves exceptions, and how duplicate records are merged in GLPI or iTop without breaking historical tickets. Ask how sizing will be validated before go-live, including the test that proves the chosen database and server layout can hold your asset count and agent check-in rate. The partner should be able to point to the sizing guidance for the version they recommend, such as the iTop software requirements, and explain what they will measure in your environment. Confirm the version and PHP and database requirements that apply to the release they install. Finally, ask what the written scope excludes and how upgrades will be handled after go-live. Confirm whether OT or industrial assets, cloud resources, container platforms, mobile devices and third-party data feeds are in scope, and whether the partner will build the integrations or only document them. For upgrades, ask for the backup and update procedure in writing, including how the configuration keys are preserved. For GLPI 11.0 and later, ask how plugins are reactivated after a new version is detected and after major updates, who tests each plugin before reactivation, and whether the retainer covers that testing. Ask for the schedule of agent upgrades as well, since agent and server versions must stay compatible across the estate.
What open source IT asset management and CMDB costs and requires from your team
What drives the cost of an open source asset inventory and CMDB?
Scope drives most of the cost: how many endpoints, servers, network devices and cloud accounts you bring in, how many systems hold asset data, and how hard it is to reconcile them. The software license is usually not the main line item, because GLPI and iTop are open source. The paid work is the configuration of the CMDB model, agent rollout across Windows, macOS and Linux, migration of existing spreadsheets or exports, reconciliation with monitoring and procurement data, and ongoing administration. Costs fall into one-time work (design, rollout, migration) and recurring work (administration, upgrades, optional support). Ask any partner for a quote that lists each of these separately, with the number of sources and the reconciliation rules stated, so you can see what changes the price if scope grows.
Can our own team run an asset inventory and CMDB without a partner?
Yes, for a small estate with a skilled team, the work can be done internally. Plan for skills in Linux and web server administration, PHP and database operations (MariaDB or MySQL), directory integration, endpoint management and data modeling. A small team usually needs someone who can design the CMDB classes and relationships, someone who owns agent deployment through existing endpoint tooling, and someone who runs upgrades and backups. GLPI's documentation says plugins are suspended after a new version is detected and must be reactivated after major updates, so upgrade planning needs an owner. Be realistic about where the gaps are, and a partner can fill them for a fixed scope.
How long does an asset inventory and CMDB project take?
The duration depends on scope: the number of endpoints and sites, the number of data sources to reconcile, how much existing data must be cleaned, and how quickly your change windows and data owners can respond. No duration is set in this guide, so ask for it in the written plan. A good plan separates discovery and pilot from full agent rollout, migration and reconciliation, and handover. Ask the partner to name the milestones, the decisions you must make at each one, and what happens if a data source is late.
What does the work need from our team and our network?
The work needs named data owners for each source (directory, endpoint tooling, network, monitoring, procurement and finance), because they decide what counts as the asset of record. It also needs network access for the GLPI Agent to reach the server, and for network discovery to scan the subnets you approve. Plan change windows for the server build, database migration and any agent pushes that touch production endpoints. Finally, someone must approve the data model, including classes, mandatory fields and naming, before migration begins. Confirm each of these in the written scope, since they are the usual sources of delay.
How does GLPI Network pricing compare with self-hosting GLPI?
GLPI Network is the managed service offered by Teclib', the company that maintains GLPI. According to the GLPI Network subscriptions page, the public cloud option costs 19 euros per user per month and the private cloud option costs 21 euros per user per month, with a 25-user minimum. Self-hosted subscriptions on that page range from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise). Self-hosting keeps the platform in your infrastructure, but you carry the hosting, upgrades, backups and administration. Compare the managed fee with your internal or partner labor for those tasks, and confirm current pricing directly with Teclib' before you decide.
How do iTop Community, Atelier and Forge limits compare with self-hosting?
Combodo sets the tiers by agent count. According to combodo.com, iTop Community is free for up to 10 agents, iTop Atelier covers up to 50 agents, and iTop Forge covers more than 50 agents, each available on premises or as SaaS. Because iTop is AGPL-3.0 licensed, the software itself is open source, so the tiers mainly reflect the commercial support, training and consultancy Combodo sells. Confirm which tier matches your agent count and whether the support scope covers your CMDB customizations, since iTop's model is highly customizable and custom work is a common reason for support questions.
What hardware does an iTop or GLPI server need at this scale?
Hardware depends on ticket volume, console users and the number of assets and agents. For iTop, Combodo suggests 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. For larger installations it suggests separate web and database servers of up to 8 vCPU and 16 GB each. For iTop 3.3.x, PHP 8.2 to 8.4 is required, MariaDB 10.6 to 11.8 is preferred over MySQL, and GraphViz must be installed. GLPI 12.0.0 requires PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later. Confirm sizing with your agent count and inventory frequency before procurement, because the initial discovery run often produces the heaviest load.
How DeployOpen scopes, builds and supports an asset inventory and CMDB
DeployOpen plans and implements self-hosted open-source platforms inside your own infrastructure, including GLPI or iTop for asset inventory and CMDB work. Engagements start with a written, fixed scope that defines which asset classes, sources and integrations are included before any agent is deployed.
How we scope
- Written scope lists asset classes, operating systems, network segments and data sources to be inventoried.
- Scope defines which CMDB classes and relationships are modeled, and which records are authoritative.
- Scope names reconciliation sources such as monitoring, procurement and identity systems, with ownership agreed up front.
How we build
- Deploy and configure the chosen platform in your cloud accounts, data centers or air-gapped network.
- Roll out GLPI Agent or the agreed discovery method across Windows, macOS and Linux endpoints in tested waves.
- Configure CMDB data model, import routines and data consistency checks, then test reconciliation against sample records.
How we hand over
- Documentation covers the data model, agent packaging, discovery schedules, reconciliation rules and admin procedures.
- Handover includes backup and update runbooks, including protection of encryption keys and plugin re-activation steps.
- Your team receives training on maintaining asset records, handling unknown devices and running consistency audits.
How we support
- Ongoing support, upgrades and periodic testing are available as a retainer, scoped in writing.
- Support can cover new agent versions, platform upgrades and reconciliation rule changes as your estate changes.
- Confirm with DeployOpen which support hours, response commitments and escalation paths the retainer includes.
