Jira Service Management vs GLPI

Jira Service Management organizes agent work around queues, which are saved views over work items that show each team what needs attention next. Queues are built per service project and are usually driven by request type, assignee and status, so routing depends on how the project is designed. GLPI handles intake differently. Tickets arrive through the helpdesk, by email or from agents, and assignment rules, categories and the ticket status flow decide who sees each one. Both can run an internal IT desk, but they group incoming work in different ways, and migration planning depends on that difference.

• Queue design: Map each JSM queue to a GLPI assignment group, category or saved search, and confirm that every filter can be reproduced without custom code.
• Routing rules: Compare JSM automation that moves issues between queues with GLPI assignment rules, and test both against your real category tree.
• SLA timers: Check how each platform attaches response and resolution targets to a ticket and whether those timers pause when status changes.
• Agent views: Confirm how agents filter their own work in each product and whether dashboard counts match after a test import.

Confirm queue, routing and SLA behavior in the current JSM and GLPI documentation, then run a representative set of tickets through a trial instance before fixing the target layout.

In Jira Service Management, request types define the fields, instructions and approvals that a requester sees in the service portal, and each type is tied to a queue and a workflow. This makes the request catalog a central design task. GLPI models demand through tickets, ITIL categories and ticket templates, and requesters submit through the self-service helpdesk. The catalog is therefore less visible as a single list, and the fields users fill in depend on how templates and categories are set up. Neither approach is simply a copy of the other, so the catalog needs its own mapping exercise.

• Catalog inventory: Export the list of JSM request types, their fields and their approval steps, and mark which ones are used often enough to justify a template in GLPI.
• Field mapping: Check whether each custom field type has an equivalent in GLPI templates, and note where a field must be replaced by a category or a free-text description.
• Requester experience: Test how a requester finds, submits and tracks a request in the GLPI self-service interface compared with the JSM portal.
• Knowledge links: GLPI 12.0.0 lists a rewritten knowledge base, so confirm how articles can be linked from templates and categories in your chosen release.

Confirm the template and portal capabilities you need in the GLPI documentation for your version, and build two or three of your most common requests in a test instance before deciding how much catalog work to migrate.

Jira Service Management includes change requests as a request type with approval steps, and teams often extend them with templates and related work items. Change handling depends on how approvals, change categories and review boards are configured, so the design choices sit with the administrator. GLPI lists change management among its ITIL modules, alongside incident, problem and service level management. Changes can be linked to tickets, problems and configuration items, which helps teams that want change records connected to the rest of the service history. The exact approval routing and the change types you need should be verified, not assumed to match.

• Change types: Confirm how each platform separates standard, normal and emergency changes and whether your own change categories can be modeled.
• Approval flow: Document the approvers, sequence and fallback rules you use today, then check whether GLPI can reproduce them without add-ons.
• Linked records: Test whether a change can be linked to affected assets, incidents and problems in each product, and whether those links appear in reports.
• Review meetings: Check whether change calendars or review board views exist in either platform, or whether you need an external process.

Confirm the change workflow features in the current JSM documentation and in the GLPI ITIL module documentation, then walk one normal change and one emergency change through a trial instance from start to close.

Jira Service Management Assets stores configuration items in object schemas, with typed attributes and references between objects. Discovery data, where used, arrives through separate tooling, so the ownership of each asset record needs to be decided before any data moves. GLPI covers asset inventory, configuration management and a CMDB, and the GLPI Agent collects hardware and software inventory on Windows, macOS and Linux. The agent also performs network discovery and inventory, package deployment and remote ESX inventory, and it is the successor of FusionInventory Agent. The schema question is still the important one: an Assets object model does not automatically map to GLPI item types.

• Schema mapping: List each JSM object type and its references, then decide which GLPI item type, relation or custom field holds the same information.
• Discovery sources: Identify which records come from agents, scans or manual entry today, and confirm which GLPI Agent tasks cover them.
• Relationships: Test how dependencies between configuration items are shown in GLPI and whether impact views meet your needs.
• Export gaps: Note that a Jira Cloud backup excludes Assets, so the Assets data needs its own export and validation.

Confirm the object model, relationship and import options in the GLPI documentation and the Assets export options in your JSM tenant, then compare a sample of configuration items in a trial instance.

Jira Service Management is delivered as a hosted service, so most of the setup is configuration inside the product. Self-hosting GLPI moves the platform work to your team, including the web server, PHP, the database and upgrades. The GLPI README lists PHP 8.3 or later and MariaDB 10.11 or later or MySQL 8.0 or later for the current main branch, while the installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6 for GLPI 11.0. Version requirements differ by release, so the target version must be fixed first. The web server document root must point to GLPI's public directory, and during updates the config directory keys must be backed up.

• Platform stack: Choose a supported web server, PHP version and database, and confirm them against the docs for the release you plan to run.
• Upgrades: Plan backups of the database, files and the config directory, including the glpi.key and glpicrypt.key files, before each update.
• Plugins: Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so schedule plugin testing.
• Support: Decide whether internal staff or an outside provider will handle incidents, and what response terms you need.

Confirm the prerequisite table for your chosen release in the GLPI installation prerequisites and test the upgrade path in a staging copy before you commit to a go-live date.