Open-source alternative to Jira Service Management Assets: the short answer
If your configuration items, object schemas and references live in Jira Service Management Assets, the decision comes down to what you need the asset data to do. GLPI suits an inventory-led asset register, with hardware and software inventory collected by the GLPI Agent, contracts and configuration management in one platform, and an ITIL service desk alongside it. iTop suits a customizable CMDB with impact analysis, where the object model, relationships and data synchronization matter more than automated discovery. Either way, the timing is set by Atlassian's dates: Data Center licenses become read-only on March 28, 2029, and cloud teams should weigh their renewal date against the migration work described on this page.
Start with the export, because it is the step most teams underestimate. Jira Cloud's backup manager does not include Assets for Jira Service Management, so an ordinary backup will not protect your object data. Atlassian's Assets export produces one CSV per object type, with all available columns, and a format intended for migration that keeps references and dates intact. Run that export on a copy of current data and confirm with Atlassian which object types and attributes it covers in your instance before you plan the target schema.
Before you pick a target, confirm three things in your own environment: how many object types and reference chains your schema uses, whether your configuration items are populated by discovery tools or maintained by hand, and whether your team needs impact analysis across relationships. Those answers determine whether GLPI's inventory model or iTop's CMDB model needs less rework. Ask any implementation partner for a written scope that names the object types, the reference mapping and the test cases used to verify them, so the migration is checked against your data rather than assumed.
Which Assets capabilities map to GLPI and iTop
This table compares the main Jira Service Management Assets capabilities with GLPI's inventory and CMDB and iTop's customizable CMDB. Use it as a checklist against your own object schema: a check mark means the capability has a direct counterpart that still needs testing on your data, a dash means the answer depends on your configuration, and a cross marks a gap you should plan around before committing.
| Assets capability | GLPI inventory and CMDB | iTop customizable CMDB |
|---|---|---|
| Object types and custom attributes | Built-in asset types such as computers, monitors and network equipment, with extra fields added through dropdowns and custom forms; confirm each type your schema needs | Object classes are defined in the data model and can be extended; confirm attribute types and lifecycle states for each class |
| References between objects | Links between items and tickets, contracts and users are native; confirm that your Assets references map to GLPI relations | Relations between objects are a core feature with graphical impact analysis; confirm the relation types you rely on |
| Object schema structure | Schema is fixed by GLPI item types, so a custom hierarchy may need plugins or redesign; confirm before migration | Schema is defined by the data model in XML, so custom classes are possible but require skilled configuration; confirm the effort |
| Discovery and inventory | GLPI Agent collects hardware and software inventory and performs network discovery on Windows, macOS and Linux | Discovery depends on external tools or integrations; confirm which sources feed your CIs |
| Import and export | Import and export are available; Jira Assets CSV exports must be mapped to GLPI fields and reference IDs checked | CSV import and data synchronization for federation are documented; confirm reference handling for your Assets CSV export |
| Access control | Profiles and entity-based rights control visibility; confirm that your Jira permission model maps cleanly | Profiles and user rights are configurable per class; confirm scope rules for each team |
| Reporting and consistency checks | Standard reports and dashboards are included; confirm the exact reports your change and audit processes need | Data consistency audits and impact analysis are included; confirm the audits that match your CMDB rules |
| Automation rules tied to Assets | Rules engine covers ticket and asset workflows; Jira automation rules do not transfer and must be rebuilt | Trigger and notification behaviour must be rebuilt in iTop; confirm each rule before cutover |
When GLPI or iTop fits an Assets replacement
Two open-source options cover Assets replacement with different trade-offs. GLPI brings discovery and ITIL modules built in, while iTop gives you an object model you can reshape to match Jira's schema. Read the cards against your object count, agent count and how much discovery you need.
GLPI: inventory through the agent
GLPI Agent collects hardware and software inventory from endpoints and sends it to GLPI. It also runs network discovery, package deployment and remote ESX inventory, and it is the successor to FusionInventory Agent. It runs on Windows, macOS and Linux. The trade-off is breadth against schema freedom: discovery fills GLPI's built-in asset types well, but Jira Assets object types with custom attributes need a mapping check before you commit. Test that mapping with a sample export from your own Assets data.
GLPI: CMDB inside ITIL modules
GLPI is licensed under GPL-3.0 and combines assets, CMDB, contracts and ITIL incident, problem, change and service level management in one application. That matters when asset records must link directly to incidents, changes and contracts without a second tool. GLPI 12.0.0 was released on October 7, 2026, so review its release notes for changes to the assets and knowledge base modules before you plan the upgrade path. Requirements such as PHP and database versions change between releases, so confirm them against the release you deploy.
iTop: schema you can reshape
iTop describes itself as a fully customizable CMDB, with graphical impact analysis, CSV import, data consistency audits and data synchronization for federation. For a team with custom Assets object schemas, iTop may be the closer match, because you define the object model, including object classes, attributes and relations. The cost is that schema design and its upkeep fall to your team or your implementation partner. Plan time for schema mapping, and run the consistency audits after each CSV import to catch broken references.
iTop: licensing above 10 agents
Combodo offers iTop Community free for up to 10 agents, iTop Atelier for up to 50 agents and iTop Forge for more than 50 agents, each available on premises or as SaaS. A team under the Community limit pays no license fee, but you should test that limit against your headcount and expected growth. Above it, you move to a paid tier, so ask Combodo for the current terms, what each tier includes and whether support is part of it. Commercial support, training and consultancy are separate purchases to budget for.
How object schemas, references and discovery data map across
Assets exports each object type as its own CSV file, with all available columns and a consistent format that keeps references to other objects and dates intact. That export carries the data but not the model. Each Assets object type has to be rebuilt in the target: in GLPI as an item type or as a set of existing item types with custom fields, and in iTop as a class with its own attributes. Before importing anything, list every object type in your Assets schema, its attributes, and each reference field that points to another type (for example, an application that references its owning team or its hosting server). Each reference becomes a relation in the target, and those relations must exist before the referencing rows can be loaded. Confirm with the vendor how GLPI and iTop each represent one-to-many and many-to-many references, and whether reference IDs in the export can be mapped to the new identifiers without manual editing.
Discovery data is a separate stream and should not be pushed through the same import. GLPI Agent feeds hardware and software inventory directly into GLPI, and it also performs network discovery, so inventory that today comes from scanners or agents can point at the new platform without a custom connector. iTop has no equivalent bundled agent in the sources reviewed here, so the usual route is a connector or a scheduled CSV feed from your discovery tool into iTop's CSV import, with data consistency audits run afterward. Decide which system is the source of truth for each attribute, such as serial numbers or installed software, before the cutover, because two feeds writing the same field will produce conflicts. Confirm in the target product which discovery sources it accepts, how it matches devices to existing records, and what happens to Assets objects that no discovery tool can rediscover, such as contracts or licenses.
Running the CMDB next to the rest of the JSM suite
Some teams keep Jira Service Management for requests and approvals and move only the configuration data. GLPI or iTop then holds the CMDB, and Jira keeps a reference to each configuration item. This is the smallest change for people who raise requests, but two systems must agree on every asset.
- Ticket references: Jira issues keep an identifier for each configuration item, so the external CMDB needs to store the same identifier as a stable key.
- Sync ownership: Choose one system as the owner of each attribute, such as hardware status from discovery in GLPI, and have the other system read it.
- Sync mechanism: Confirm whether the integration runs on scheduled CSV imports or on API calls, and who maintains it after go-live.
- Consistency checks: iTop provides data consistency audits, which can flag orphaned or mismatched references between sync runs.
Check how your Jira instance stores Assets references before choosing the key, because changing identifiers later breaks every existing link.
Moving requests, incidents, changes and the CMDB into one platform removes the sync layer entirely. GLPI covers ITIL incident, problem, change and service level management along with asset inventory and configuration management. iTop covers its CMDB, helpdesk, change management and SLA handling. The work shifts from integration to rebuilding workflow in the new tool.
- Object mapping: Each Assets object type becomes a CMDB class or asset type, and each reference attribute becomes a relation in the target platform.
- Ticket history: A Jira CSV export carries ticket content, but linked asset values must be re-pointed to the new identifiers.
- Request types and approvals: Rebuild these in the target platform, since a data export does not carry them.
- Endpoint inventory: GLPI Agent collects hardware and software inventory, which can replace manually maintained records for endpoints.
Confirm which object types have active relations to tickets, because those relations need a tested re-linking step before cutover.
While the target platform is built, Jira Cloud stays the system of record for agents and requests. The main risk is that the cloud backup does not include Assets, so the CMDB must be exported on its own schedule alongside the normal backup.
- Backup gap: Jira Cloud backups exclude Assets for Jira Service Management, and they also exclude automation rules and third-party apps, so each needs its own export.
- Backup frequency: With attachments included, Atlassian requires 48 hours between backups, which affects how closely the separate exports can track the main backup.
- Assets export format: Export objects per type as CSV using the data consistent format, which keeps references and dates intact for later import (Atlassian's export objects guide).
- Freeze point: Agree a cutover window in which Assets edits stop, so the final exports reflect one point in time.
Run a test export and import into a non-production instance before the freeze, and confirm which Atlassian plan and app dependencies apply to your site.
Moving Assets out of Jira breaks anything that depends on Assets being inside Jira. The data can arrive intact while the logic that used it does not. Inventory these dependencies before setting a decision timeline, and check each item against your own instance.
- Automation rules: Rules that read or set Assets fields stop working in Jira, and they are not captured by Jira Cloud backups.
- Reference fields in forms: Request forms that look up objects need a new lookup source that points at the CMDB.
- Reports and searches: Dashboards and filters built on Assets attributes need rebuilding as GLPI or iTop reports.
- Approvals and impact checks: iTop describes graphical impact analysis, but confirm that it covers the approval logic your change process uses.
List every automation rule, form field and dashboard that touches an Assets object, and assign an owner to each before setting a cutover date.
Migrating Assets data out of Jira Service Management
This sequence takes Assets data from Jira Service Management into GLPI or iTop with its object types, references and dates intact, and it keeps the CSV export as the only archived copy. Each step ends with a check so the cutover rests on verified data.
Inventory object types and schemas
Start by listing every object schema and object type in Assets, along with its attributes, reference fields and the objects that point to them. Assign this to the Jira administrator who owns Assets and a service owner who knows which configuration items drive incidents and changes. Record which object types are actively used and which are stale, since stale types often do not need to move. The output is a signed-off inventory that becomes the migration scope.
Export each object type as CSV
Export each object type from Assets as CSV, choosing all available columns and the Data consistent format so that references to other objects and dates are kept. Store the files in a controlled location with a checksum and a record of the export date and the Jira site. Because Jira Cloud backups exclude Assets, these CSV files are the only complete copy of that data, so treat them as records to retain. The check is that every object type in the inventory has a file and that row counts match what Assets shows.
Map attributes and references to the target
Build a mapping table that pairs each Assets attribute with a field in GLPI's inventory and CMDB or with an iTop class and attribute. Decide how each reference field becomes a relation in the target, and whether each object type maps to a GLPI asset type or an iTop class, and record the decisions for review. Confirm in the target's own documentation how it handles custom types and relations, since the exact import behaviour depends on the version you run. The output is a reviewed mapping document that the service owner signs off.
Load the data into a test instance
Install the target on a separate test instance in your own infrastructure, following its installation requirements for PHP, database and web server. Import the CSV files in dependency order, so that objects referenced by others load first, and log every rejected row. The team that runs the target does this work, with the Jira administrator on hand to explain the source data. The check is a clean import log with rejected rows resolved or explained in writing.
Reconcile reference integrity and dates
Compare the test instance with the export by sampling objects across every type, then verify that each reference points to the intended object and that no relation is broken or duplicated. Check that creation and update dates survived the import and that time zones are consistent, because date errors are easy to miss in a small sample. Record each discrepancy, fix the mapping and reload until the counts and relations agree. The output is a reconciliation report that lists each object type with its verified counts and any accepted exceptions.
Run discovery against the target
Deploy the GLPI Agent or the discovery method you chose for iTop to a representative set of endpoints, and confirm that discovered items match or update the imported configuration items instead of duplicating them. Review the duplicates and merge rules with the service owner, since discovery data often arrives under names that differ from those in Assets. Finish by checking that discovery feeds the same relations your incidents and changes depend on. The check is a short list of agreed matching rules and a set of endpoints reporting correctly into the target.
Cut over and archive the export
Freeze edits in Assets, run a final export, load the delta into production and repeat the reconciliation for the changed records. Once the service owner accepts the result, move the original CSV files, the mapping document and the reconciliation report into long-term archive storage that your retention policy covers. Keep the Assets export as the copy of record, because Jira Cloud backups do not hold this data. The output is a production target, an accepted reconciliation record and a labeled archive.
Questions buyers ask about replacing Jira Assets
What does it cost to replace Jira Assets with GLPI or iTop?
The cost is mostly people and hosting, and only some of it is a licence. GLPI and iTop Community carry no licence fee, so the recurring costs are the servers, the database, the internal staff who run upgrades and backups, and any optional vendor support. Hosting scales with users, assets and ticket volume. For a small iTop install, 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, and separate web and database servers of up to 8 vCPU and 16 GB for larger installations. For paid support, GLPI Network lists self-hosted subscriptions from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise). Ask any vendor for a written quote that separates one-time work from recurring fees.
How long does an Assets migration take?
The duration depends on how many object types you have, how clean the data is, and how many integrations depend on the schema. No supplied timeline applies to your estate, so treat any number from a vendor as a starting point to check. The biggest drivers are the number of object types and references to rebuild, the volume of records, the amount of cleanup needed before import, and how many automations or dashboards must be recreated by hand. Teams also need time to test reports and sign off. Ask for a phased plan with named milestones, and agree the scope in writing before work starts.
What must our team provide before a Jira Assets migration starts?
You will need to supply three things: a complete schema inventory, named data owners, and a test instance. The schema inventory lists each object type, its attributes, its references to other objects, and the object schemas that group them. Data owners decide which records are current, which are duplicates and which can be retired. A test instance, separate from production, lets you import, compare and fix records without risk to live service management. Also collect the Assets CSV exports, since Jira Cloud backups do not include Assets. Confirm these items with your Atlassian administrator before the project plan is set.
Can our own IT team migrate Jira Assets without outside help?
A capable team can do the work, but it needs time, database and web server skills, and a clear owner for the decision. The export side is straightforward: Assets objects export per type as CSV with the data consistent format, which keeps references and dates intact. The harder parts are installing and hardening GLPI or iTop, mapping object types onto the target model, rebuilding discovery, and validating results. Many teams split the work, keeping data mapping in-house and bringing in an implementation partner for installation, hardening and testing. DeployOpen plans, implements and supports self-hosted platforms in your own infrastructure under a written, fixed scope.
Should we choose GLPI or iTop for Assets and discovery?
Choose GLPI if automated discovery and inventory are the priority, and iTop if your CMDB model must follow your own structure closely. GLPI Agent collects hardware and software inventory, performs network discovery and inventory, and runs on Windows, macOS and Linux. It is the successor of FusionInventory Agent. iTop describes a fully customizable CMDB with graphical impact analysis, CSV import, data consistency audits and data synchronization for federation. iTop Community is free for up to 10 agents, so larger teams will need Atelier or Forge. Test both against a sample of your real asset classes before deciding.
Do object schemas and references survive the move to GLPI or iTop?
Simple fields and most references survive, but schema-level features do not carry over automatically. The Assets export keeps references to other objects and dates intact in its migration format, which gives you the data. What it does not give you is the schema itself, the attribute rules, or the workflows that depend on them. Each target needs its own data model, so object types, relationships and any custom attributes must be rebuilt and then mapped record by record. Expect a validation pass to catch broken references, and ask any implementation partner to show how orphaned objects are reported.
Will our Jira Assets integrations and automations need rebuilding?
Yes, integrations and automations usually need to be rebuilt because they do not transfer with the data. Jira Cloud backups exclude automation rules, third-party apps and Assets, so you must document each rule and integration separately before cutover. Inventory every automation that reads or writes Assets, every app connected to it, and every report that depends on those fields. Then decide which ones the new platform should replace and which can be retired. Ask for a test plan that compares outputs from both systems during a parallel run.
Risks that break Assets migrations
Assets migrations rarely fail on the import itself. They fail on what the import silently changes: identifiers, dates, attributes, duplicate records and the fallback copy you no longer have. Each card below names one of these failure points and the check to run before cutover.
References that break on new IDs
Assets objects link to each other by reference, and a target CMDB assigns its own identifiers on import. If a ticket, configuration item or dependency still points at an old Jira object key, it will resolve to nothing or to the wrong record. Before cutover, export each object type with the Data consistent format, load a small set of linked objects into a test instance, and confirm that every reference resolves to the intended target. Then check that the same links appear in impact analysis views.
Dates lost in conversion
Purchase dates, warranty end dates, install dates and maintenance windows often pass through a CSV as text, and the target application may read day and month in a different order or drop the time zone. The result is warranty alerts that fire on the wrong day or expired assets that look current. Before cutover, sample records from each date field, compare them against the source export, and confirm the date format the target expects for the import file.
Unmapped custom attributes
Object schemas in Assets often carry custom attributes added over several years, such as cost centre, data classification or application owner. A GLPI or iTop data model does not have them unless someone creates matching fields first, and a column with no destination is easy to miss in an import report. Before cutover, list every attribute in each object type, map each one to a target field or a documented decision to drop it, and confirm that the import report shows no unmapped columns.
Discovery duplicates against existing inventory
If the GLPI Agent or another discovery tool starts reporting hosts while migrated records already exist, the same server can appear twice: once as an imported item and once as a new inventory entry. Duplicate configuration items distort impact analysis and license counts. Before turning on discovery, decide which record is the system of record for each asset class, agree on a matching key such as serial number or hostname, and run a reconciliation report after the first full inventory cycle.
No Jira-side snapshot retained
Jira Cloud backups do not include Assets, so a failed migration leaves no built-in copy of the schema or object data unless you keep one. Once a team decommissions the Jira Assets objects, rolling back or answering an auditor's question about historical configuration becomes costly. Before cutover, store dated CSV exports of every object type with the schema definitions in a location you control, record their checksums, and set a retention period that your records policy requires.
How DeployOpen scopes and delivers an Assets replacement
DeployOpen plans, implements, customizes, integrates, documents and supports self-hosted open-source platforms inside your own infrastructure, so an Assets replacement starts with a written scope covering your object types, references and discovery sources. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins.
How we scope
- Inventory every Assets object type, attribute and reference that teams rely on today
- Decide whether GLPI inventory, iTop's customizable CMDB or both fit your data model
- Agree in writing which discovery sources, export files and reconciliation checks are in scope
How we build
- Install GLPI or iTop in your own cloud account, data center or air-gapped network
- Map Assets CSV exports to target classes, relations and identifiers, then test imports in a non-production instance
- Configure GLPI Agent or other discovery sources and run data consistency checks before cutover
How we hand over
- Deliver the data mapping, import scripts, configuration records and run books in writing
- Document backup and update steps, including the GLPI or iTop items that must be preserved
- Run a handover session with administrators so your team can maintain the CMDB after go-live
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Repeat data checks and discovery reviews when Atlassian exports or your asset sources change
- Ask any quote to name the scope, deliverables and support terms, which we confirm before work starts
