Why teams move from FusionInventory to GLPI Agent
If your FusionInventory agents already report into GLPI, the move to GLPI Agent is a planned change of agents and server-side inventory, not a data import. GLPI Agent is the successor of FusionInventory Agent, and it runs on Windows, macOS and Linux, so the endpoints you already manage can be moved in waves rather than rebuilt. The work is to decide which inventory tasks you still need, confirm that each one has a supported path in the new stack, and then run old and new collection side by side until the asset records agree.
Since GLPI 10, core hardware and software inventory is native to GLPI, so most endpoint collection does not need an extra plugin. The GLPI Inventory plugin is still required for network discovery, SNMP, VMware host inventory, data collection and package deployment. Before you plan, list every FusionInventory task your estate uses today, including any scheduled network scans, ESX inventory and software deployment jobs, and map each one to native inventory or to the plugin. Confirm the current plugin behavior and version compatibility with your GLPI release in the GLPI Help Center and the plugin documentation before you commit to a sequence.
Effort depends mostly on estate size and on how many of those tasks you run. A fleet of workstations that only reports hardware and software is a relatively contained change, while a mixed estate with SNMP discovery, ESX hosts and deployment jobs adds configuration, testing and rollback work for each task. Ask any partner or internal lead to break the effort into agent rollout, plugin setup, task-by-task parity testing, and retirement of the old FusionInventory plugin, and to state which of those steps will run in parallel.
Which FusionInventory capabilities map to GLPI Agent and which need rework
This table compares each FusionInventory agent and plugin capability with its GLPI Agent, native inventory or GLPI Inventory plugin equivalent, and notes what must be checked during migration. A check mark means the capability has a direct equivalent that still needs confirmation, a cross means it does not carry over, and a dash means the answer depends on your version and setup. Treat every row as a checklist item, because existing FusionInventory history and custom configuration are not converted automatically.
| Source capability | Platform equivalent | Migration notes |
|---|---|---|
| Hardware and software inventory from agents | GLPI Agent with native inventory since GLPI 10 | Run both agents in parallel on a sample of machines and compare results before switching. Confirm the GLPI Agent documentation for your versions. |
| Network discovery and inventory | GLPI Inventory plugin with GLPI Agent | Discovery tasks must be recreated in the new plugin. Old FusionInventory task definitions are not converted, so list each subnet and its scan settings first. |
| SNMP device inventory | GLPI Inventory plugin SNMP discovery | Re-create community or credential settings and device models in the new plugin. Verify that each device type you rely on is covered for your version. |
| ESX or VMware host inventory | GLPI Agent remote ESX inventory and GLPI Inventory plugin | Confirm the ESX connection method and credentials in the documentation. Check that virtual machine records link correctly to existing host records. |
| Package deployment | GLPI Inventory plugin deployment tasks | Deployment jobs and their target groups must be rebuilt. Test each package on a pilot group before scheduling any wide rollout. |
| Agent configuration and server targets | GLPI Agent configuration files and task settings | Update server URLs and configuration on every endpoint. Remove or repoint any agent still reporting to the old FusionInventory server. |
| Historical asset records and history | Existing GLPI asset records and inventory history | Historical FusionInventory data is not automatically converted. Decide per item whether to keep, merge or retire records, and document the decision. |
| Custom inventory fields and plugin settings | Rework in GLPI Inventory plugin or GLPI custom fields | Custom configuration must be reviewed item by item. Confirm each custom field or setting against the current GLPI Agent documentation before relying on it. |
Documented paths for moving agents, tasks and inventory data
FusionInventory migrations usually separate into three workstreams: the agents on endpoints, the advanced tasks that the GLPI Inventory plugin takes over, and the historical asset records already stored in GLPI. Each card below covers one of these decisions so you can sequence them before retiring anything.
Deploy GLPI Agent on endpoints
GLPI Agent is the documented successor of FusionInventory Agent and runs on Windows, macOS and Linux. It collects hardware and software inventory and sends it to GLPI. Before rollout, confirm which operating systems in your estate are in scope, which server URL each agent will report to, and how agent configuration will be pushed. Pilot on a small group of machines and compare the resulting computer records with what the old agent produced.
Enable native inventory in GLPI
Since GLPI 10, inventory is native, so agent reports from GLPI Agent can be processed without the older FusionInventory plugin. Check that your target GLPI version supports this flow, then confirm how inventory submissions are accepted and stored on your instance. Review the computer records after the first reports arrive, paying attention to fields that custom rules or previous imports populated.
Install the GLPI Inventory plugin
Network discovery and SNMP inventory, VMware host inventory, data collection and package deployment are advanced tasks that require the GLPI Inventory plugin. List every FusionInventory function your organization uses today, then map each one to a supported task. Any function without a documented equivalent should be recorded as an open item for the architecture review rather than assumed to carry over.
Retire FusionInventory agents safely
Stop FusionInventory agents only after GLPI Agent is reporting for the same machines and the advanced tasks have been verified. Keep a dated inventory of which endpoints run which agent version, and remove the FusionInventory plugin from GLPI only after no task still depends on it. Confirm with the GLPI Agent documentation how to remove the old agent on each platform in your estate.
Import and export existing asset records
Existing computer, network and software records already held in GLPI usually stay where they are, because agents update them in place. For records held outside GLPI, such as spreadsheets, confirm the import route your GLPI version supports before building a migration. Do not assume a documented importer exists for FusionInventory-specific data until you have checked the current GLPI documentation for your version.
How the agent cutover runs with a parallel period
The sequence moves inventory from FusionInventory to GLPI Agent in controlled stages, so each group is proven against existing records before its old agent is removed. The result is one reconciled source of asset data and a documented decommissioning record.
Inventory existing FusionInventory agents and tasks
Your team lists every FusionInventory agent deployed across Windows, macOS and Linux endpoints, along with the plugin tasks, discovery ranges, SNMP settings, deployment packages and remote ESX inventory targets currently configured in GLPI. DeployOpen can help map these against the GLPI Agent and GLPI Inventory plugin equivalents. The step is done when every agent, task and setting has a named owner and a target state, and the list is signed off by the service owner.
Back up before any plugin or version change
Before changing plugins, take a backup of the database, the files directory and the config directory, including glpi.key and glpicrypt.key, as the GLPI update procedure requires. Store the backup where a restore can be tested without touching production. Confirm the backup can be restored on a separate host before proceeding. Note that since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so plan the reactivation check into the change window.
Pilot GLPI Agent with native inventory
Deploy GLPI Agent to a small, representative pilot group of endpoints covering each operating system and department in scope. Configure the agent to send hardware and software inventory to GLPI using native inventory, which has been part of GLPI since version 10. Keep the existing FusionInventory agents running on these devices during the pilot. The step is complete when pilot devices report to GLPI on schedule and each device has a single, expected computer record.
Enable GLPI Inventory tasks for discovery and SNMP
Install and activate the GLPI Inventory plugin, then enable only the advanced tasks you need, such as network discovery, SNMP inventory, VMware host inventory, data collection or package deployment. Start with one discovery range and one SNMP-capable device group, and confirm that task results land on the expected network devices. Record the credentials, ranges and schedules used. The step is done when each enabled task has produced results that match a manual check of a sample of devices.
Run a parallel period and compare records
Keep FusionInventory and GLPI Agent reporting on the same devices for a period you agree in advance. For each device, compare serial number, operating system, installed software, network addresses and assigned user between the two sources. Log every mismatch with its cause, such as duplicate records, changed hostnames or unsupported fields. Confirm with the service owner which source is authoritative for each attribute. The step closes when mismatches are either corrected or accepted in writing.
Cut over agents in stages by group
Move remaining device groups to GLPI Agent one group at a time, starting with the lowest-risk groups and ending with servers and critical endpoints. For each group, deploy GLPI Agent, confirm that new records appear and that existing records are updated rather than duplicated, then stop the matching FusionInventory agent. Keep a rollback path for each group until its first full inventory cycle has completed. The step is done when every group reports through GLPI Agent and no group is waiting on a pending change.
Decommission FusionInventory agents and plugin
Once every in-scope device is reconciled and reporting through GLPI Agent, remove the FusionInventory agents from endpoints using your standard software removal process. Disable and then uninstall the FusionInventory plugin in GLPI after confirming no tasks or saved configurations still depend on it. Take a final backup, record the change and update the asset management procedure. The step is complete when no FusionInventory agents or plugin components remain and the decommissioning record is filed with the reconciliation results.
What drives the effort and duration of the move
This table lists the factors that most change the effort of moving from FusionInventory to GLPI Agent and native inventory, who carries each piece of work, and what makes it grow. Use it to see which drivers apply to your estate, then ask for a quote built from a written scope rather than a generic estimate.
| Driver or cost component | Who does the work | What increases it |
|---|---|---|
| Number of endpoints and platforms | Your team sets the target list, DeployOpen plans the rollout waves | Mixed Windows, macOS and Linux fleets, plus servers and remote sites, each need tested agent packages and deployment paths |
| SNMP and network discovery | DeployOpen configures discovery tasks with your network team | Many subnets, SNMP v1 or v2c community strings to rotate, and devices whose MIBs need validation before import |
| VMware host inventory | DeployOpen and your virtualization team set credentials and scope | Large ESX estates, several vCenters, and hosts that need dedicated access accounts and firewall rules |
| Package deployment tasks | DeployOpen designs packages, your team approves them for production | Software packages with dependencies, per-site distribution points, and change approval for every package |
| Custom FusionInventory configuration | DeployOpen reviews existing config and maps each setting to GLPI Agent or the GLPI Inventory plugin | Custom tasks, scripts, local extensions or inventory fields that have no direct equivalent and need rebuilding |
| Deployment tooling for agents | Your endpoint management team runs the rollout, DeployOpen supplies packaging and test scripts | Several tools in use, no existing software distribution, or manual installs across unmanaged devices |
| Duplicate asset handling | DeployOpen designs matching and merge rules, your asset owners decide on conflicts | Hardware replaced or reimaged, two agents reporting the same machine, and assets recorded under old FusionInventory identifiers |
| History retention needs | Your compliance or asset owners define retention, DeployOpen implements the purge and archive settings | Long audit windows, legal holds, or a requirement to keep prior FusionInventory records alongside new GLPI data |
| GLPI version in use | DeployOpen confirms plugin compatibility and the upgrade sequence | An older GLPI release that needs an upgrade first, or plugins that must be reactivated after a major update |
| Access to change windows | Your change board schedules windows, DeployOpen plans cutover steps around them | Limited maintenance periods, freeze dates, or the need for a parallel run long enough to compare both inventories |
| One-time: pilot | DeployOpen with a sample of your endpoints and a few network segments | Number of device types in the pilot and the number of issues found in the first comparison of old and new data |
| One-time: configuration, parallel run and decommission | DeployOpen builds the configuration, your team validates results and removes FusionInventory | Length of the parallel run, the number of reports that must match, and the cleanup of old agents and plugin data |
| Recurring: agent and plugin maintenance | Your team with DeployOpen under a retainer, if you choose one | Agent version updates, GLPI Inventory plugin upgrades on each GLPI release, and new device types added to discovery |
What usually goes wrong during an agent migration
Most problems in a FusionInventory to GLPI Agent move come from running two inventory paths at once, from losing records during mapping, or from GLPI maintenance steps that touch the inventory plugins and keys. Each card below names one risk and a prevention step to put in the plan before the first agent is redeployed.
Duplicate assets during overlap
While old FusionInventory agents and new GLPI Agents both report, the same device can appear as two asset records, often with different names or serial formats. Decide before rollout which source is authoritative for each device class, and set the deduplication and merge rules in GLPI before the overlap window opens. Check a sample of migrated hosts for a single record after each wave.
Lost or unmapped history
Tickets, contracts, licenses and manual edits linked to an asset can be orphaned if the record is recreated instead of matched to its existing entry. Export the current asset and software data, map each device to its existing GLPI record, and confirm linked items still resolve on a staging copy. Ask your team to name the fields that must survive the change.
Agents left on decommissioned hosts
Retired or re-imaged machines can keep running the old FusionInventory agent, which keeps reporting stale data or consuming scheduled tasks. Build a list of every host still running the legacy agent from your deployment and endpoint tooling, and remove or disable those agents as part of each wave. Reconcile the list against the GLPI inventory before closing the project.
Plugins suspended after a GLPI update
Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates. If the GLPI Inventory plugin is not reactivated, discovery, deployment and VMware tasks stop without an obvious error in the inventory views. Add plugin reactivation and a check of scheduled inventory tasks to the update runbook.
Missing glpi.key and glpicrypt.key backups
The GLPI update procedure expects the config directory, including glpi.key and glpicrypt.key, to be backed up along with the database and files. Without these keys, encrypted values stored in GLPI can become unreadable after a restore or move. Store a copy of both keys in your secrets vault, and confirm the restore on a test host before any agent or plugin change.
Discovery scope gaps for network devices
Agents only report hosts where they are installed, so switches, firewalls, printers and access points that were covered by SNMP discovery under FusionInventory may disappear from GLPI. Inventory every network device class that the old discovery covered, then configure discovery tasks and SNMP credentials in the GLPI Inventory plugin for each subnet. Compare device counts before and after cutover.
Questions buyers ask before moving from FusionInventory
How much effort does moving from FusionInventory to GLPI Agent take?
The effort depends mostly on how many agents you run, how many distinct deployment methods you used and how much of your inventory logic lives in FusionInventory-specific configuration. A fleet deployed from one software distribution tool with a single agent configuration is a far smaller job than a fleet spread across manual installs, login scripts and several operating systems. Discovery and SNMP work add effort because the GLPI Inventory plugin must be installed, configured and tested before you retire the old tasks. Ask any partner to size the work from an inventory of your agent versions, deployment paths, network discovery tasks and plugin usage before agreeing a fixed scope.
Can our internal team complete this migration without outside help?
Yes, many teams do, provided they have someone who understands the GLPI server, the agent packaging for each operating system and the change control needed to roll agents out across production endpoints. The work is well suited to in-house teams when the estate is small and the deployment tooling is already mature. Outside help tends to pay off when discovery tasks, VMware inventory or package deployment must move at the same time as the agents, or when the team has no capacity for a parallel run. The GLPI Agent runs on Windows, macOS and Linux, so confirm that your platform owners can package and test it on each of those systems.
How long should FusionInventory and GLPI Agent run in parallel?
Run both agents long enough to show that the new inventory matches the old for every device class you report on, which usually depends on your change calendar and how often devices are online. The length is set by the amount of variation in your fleet, not by a fixed period. Laptops that connect rarely need more time than always-on servers, and devices that appear through discovery need a full cycle of scans. Agree the comparison criteria before the parallel run starts, such as software counts, hardware fields and asset matching rules, so the decision to retire FusionInventory rests on evidence.
Does existing FusionInventory history carry over into GLPI?
Inventory history is not automatically rewritten by installing a new agent, so plan for what happens to records already in GLPI. Devices that report through GLPI Agent will update their existing asset records when the matching rules recognize them, but the reconciliation rules, duplicate handling and any custom fields need to be checked on a test copy first. Old FusionInventory-specific configuration, tasks and plugin data are a separate question from asset history. Ask your partner to document which data is kept, which is recreated and which is archived before any cutover.
What does the internal team need to provide for this work?
The team needs named owners for the GLPI server, the endpoint management tooling, the network team for discovery and SNMP credentials, and the change board that approves agent rollouts. It also needs access to a staging GLPI instance that matches production closely enough to test inventory rules and plugin behavior. Expect to supply current agent versions, deployment scripts, a list of discovery ranges and a sample of devices across every operating system in use. Confirm these responsibilities in the written scope so that gaps in access or approvals do not stall the rollout.
Do we need a GLPI Network subscription for this migration?
A GLPI Network subscription is not required to move from FusionInventory to GLPI Agent and the native inventory in GLPI 10 and later, because the agent is open source and the inventory features are part of the platform. The GLPI Inventory plugin is needed for advanced tasks such as network discovery, VMware host inventory and package deployment, and its licensing should be confirmed for your version. If you choose a managed or subscription service, the published GLPI Network prices are 19 euros per user per month for public cloud and 21 euros per user per month for private cloud with a 25-user minimum, while self-hosted subscriptions start at 100 euros per month. Those figures are list prices from the GLPI Network subscriptions page and should be checked before budgeting.
How the team verifies that records match before decommissioning
Verification means proving that GLPI shows the same estate that FusionInventory showed before anything is switched off. Start by taking a sample of devices, ideally spread across operating systems, sites, device types and both physical and virtual hosts, and compare each one across the old and new sources. For every sample device, check the serial number, asset tag, hostname, operating system and version, CPU and memory figures, disk and network interfaces, and the installed software list. Record each difference in a shared worksheet with the device identifier, the field name, the old value, the new value and the likely cause. Most early differences come from timing, such as a device that reported after one run and not the other, or from fields that are formatted differently in the two sources. Those are rules to write down, not errors to hide.
Once the sample behaves predictably, extend the same comparison to the full estate and to discovery results. Compare SNMP-discovered network devices and any VMware host inventory that the GLPI Inventory plugin now produces against the records FusionInventory created, and confirm that tasks you rely on for package deployment still reach the devices they target. Agree reconciliation rules before the full run: which source wins for each field, how duplicates are merged when the same device appears under two identifiers, and what happens to devices that have an old record but no new one. Confirm the exact field-level behavior, including how the native inventory and the GLPI Inventory plugin handle duplicate rules, in your own GLPI version, because the matching logic has changed across releases and your import rules are configured locally.
Finish with a written sign-off before FusionInventory is removed. The sign-off should list the sample size, the fields checked, the count of unresolved differences and who accepted each rule, and it should be signed by the owner of the asset register and the team that operates the agents. Keep the comparison worksheet and the sign-off with your change record so that auditors and future staff can see how the records were judged. Only after sign-off should you stop the FusionInventory agent services on endpoints and remove the plugin, and keep a tested backup of the database so that the old state can be restored if a gap surfaces later.
How DeployOpen scopes and delivers the GLPI inventory move
DeployOpen approaches the move from FusionInventory to GLPI Agent and native inventory as a planned change to your inventory pipeline, not a simple package swap. We inventory the existing agents, plugins and data flows first, then build, test and document the replacement inside infrastructure you control.
How we scope
- We list every FusionInventory agent, plugin task and inventory source currently feeding your GLPI instance.
- We identify which tasks need the GLPI Inventory plugin, such as network discovery, SNMP, VMware host inventory and package deployment.
- Engagements are fixed-scope, so the written scope states agent platforms, device counts, plugins and deliverables before work starts.
How we build
- We configure GLPI Agent on Windows, macOS and Linux targets and test inventory results against a staging GLPI instance first.
- We compare imported asset records during parallel running so duplicate or orphaned computers are found before cutover.
- We document the deployment method, agent configuration and inventory rules used for each device group in your environment.
How we hand over
- You receive the tested agent configuration, deployment packages, discovery task settings and an inventory verification checklist.
- We provide a cutover record and a retirement plan for old FusionInventory agents and the FusionInventory plugin once validation passes.
- Your team receives operating notes covering agent updates, failed inventory runs and ownership of each inventory source.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, including checks after GLPI 11 or 12 upgrades.
- Confirm with your team the GLPI version, plugin versions and support window you need before the retainer scope is written.
- Support covers agent version checks and plugin reactivation after major updates, scoped to the agreed written terms.
