Migrate from Jira Service Management to GLPI

Migrate from Jira Service Management to GLPI: what the move involves

An internal IT team moving from Jira Service Management to GLPI is usually facing Atlassian's Data Center dates, a licensing change, or a requirement to keep the service desk on its own servers. The move is a data, configuration and process migration with a real Assets gap: requests, incidents and changes transfer through exports, but the asset model and its automation do not come across in the same way. The effort depends on the Assets schema, the number of automation rules and the integrations that feed or read from the desk, so inventory those before estimating anything. The work is normally done by internal IT with an implementation partner for the parts that need platform knowledge. GLPI is free software under GPL-3.0, so the license is not the cost. The real costs are the hosting, the migration itself, and any support subscription you choose. Ask for the scope in writing, including the ticket history depth, the asset classes to rebuild, how automation is recreated in GLPI's rules, and who owns cutover testing. Confirm which GLPI version and PHP and database requirements apply to your environment before you commit to a timeline.

Start with the Assets export, because Jira Cloud's backup manager does not include Assets, automation rules or third-party apps. Export work items separately, then export Assets as its own dataset, and map each object type to a GLPI itemtype such as computers, network equipment or contracts. Record which Assets references link to tickets, since those links must be rebuilt by hand or by a script. Run a trial import into a non-production GLPI instance and count records by type before you touch live data. Also plan the authentication and roles early. GLPI checks the internal database first, then LDAP, IMAP and other external methods in that order, so decide whether agents will sign in through directory accounts and set those sources before users arrive. Keep the GLPI configuration key files with your backups, because they are needed to restore encrypted data. Finally, agree on a parallel-run period and a rollback point with the business owners of change and incident management.

Which Jira Service Management capabilities map to GLPI and which need rework

This table compares the main Jira Service Management capabilities with GLPI's ITIL modules, inventory, CMDB, knowledge base and contract management. Each row is marked clean, needs rework or gap, and lists what to confirm in your own JSM configuration and in the current GLPI release. Read the status as a planning signal, then verify it against your actual workflows before you commit to a migration scope.

Capability	Status in GLPI	What to confirm before migrating
Requests and service catalog	Needs rework	Map each JSM request type to a GLPI ticket category and form. Confirm which fields, approvals and default assignments your request types rely on.
Incidents	Clean	GLPI covers incident management under its ITIL modules. Confirm priority, urgency and impact matrices, and whether your SLA clocks need to carry over exactly.
Problems	Clean	GLPI includes problem management in its ITIL modules. Confirm how linked incidents and known error records are used in your JSM workflows so the links survive export.
Changes	Needs rework	Confirm your change approval flow, change types and CAB steps against GLPI's change module, and rebuild approval chains in the new release.
Service levels	Needs rework	GLPI supports service level management, and the 12.0.0 release notes mention group-managed OLAs. Confirm each JSM SLA target, calendar and escalation rule, which are not in a Cloud backup.
Knowledge base	Needs rework	GLPI includes a knowledge base, and the 12.0.0 release notes describe a rewritten version. Confirm article structure, attachments and how Confluence links are handled.
Assets and CMDB	Needs rework	GLPI offers inventory, configuration management and a CMDB. Confirm object types, relations and references in JSM Assets, since the Assets CSV export is separate from the Cloud backup.
Automation rules	Gap	Jira Cloud backups exclude automation rules. Rebuild them in GLPI rules or workflows, and document each rule from your JSM configuration before cutover.
Contracts and inventory	Clean	GLPI covers contract management and asset inventory. Confirm which hardware and software records you need and whether GLPI Agent will replace your current discovery tooling.

What can be exported from Jira Service Management and what must be extracted separately

Jira Cloud's backup manager covers the core ticket record but leaves out several things an internal service desk relies on every day. The cards below separate what the export carries from what must be extracted, rebuilt or re-authenticated before GLPI can take over the service desk.

Work items, comments and users

The Jira Cloud backup manager creates a backup for cloud that includes work items, comments, users and groups, and project configuration. This is the core ticket history you can carry into GLPI as tickets, followups and requester records. Check that comments keep their authors and timestamps, because GLPI attributes followups to user accounts that must exist before import. Confirm which projects and request types are included in the backup you select.

Automation rules are excluded

Automation rules are not in the Jira Cloud backup. Routing, escalation, notification and auto-assignment logic must be documented by hand from the automation rule list before the Jira tenant is retired. Each rule becomes a GLPI business rule, a ticket template behavior or an external workflow step, so list the trigger, condition and action for every rule. Teams that skip this step often discover missing escalations only after the first breached SLA.

Third-party app data

Marketplace apps store data that the backup does not capture, including approvals, custom fields, dashboards and forms from add-ons. Inventory every installed app and the data each one owns, then decide whether GLPI covers the function natively or needs a plugin or a custom extract through the Jira REST API. Record the app owner for each item, because some app data exists only in the vendor's storage and cannot be exported from Jira at all.

Assets exported separately

Assets is excluded from the Jira Cloud backup and must be exported on its own as CSV. Use the Assets export for configuration items, their attributes and their relationships, then map each object type to a GLPI itemtype such as computers, software or network equipment. Check that references between objects survive the mapping, since GLPI links items through its own relations and not through Jira object references.

Attachments and the backup interval

With attachments included, Atlassian requires 48 hours between backups, so plan the final extraction well ahead of the cutover window instead of running it on the last day. Attachments are large and slow to restore, so confirm their size in advance and decide whether they move with the tickets or stay in an archive. Verify a sample of attachments after import, because a failed transfer can remain hidden until a user opens an old ticket.

Users rebuilt through GLPI authentication

Jira accounts do not move into GLPI with their passwords, so each user must be recreated and tied to a sign-in method. GLPI tries authentication in order: the internal database, then LDAP directories, then IMAP mail servers, then external methods such as REMOTE_USER. Map each Jira user to the directory identity that will sign in, and decide which accounts stay local. Confirm this order with the GLPI authentication documentation for your version before you design the directory connection.

How to sequence the migration from inventory to decommission

This sequence moves an internal IT service desk from Jira Service Management to GLPI in controlled stages, so each stage produces evidence that the next one can rely on. Each step has a defined output, and the old system is retired only after the new one has run in parallel.

Inventory projects, request types, workflows and automation
Your ITSM lead and a Jira administrator list every service project, request type, workflow, queue, SLA, custom field, Assets object schema and automation rule in Jira Service Management. Automation rules and third-party apps sit outside Jira Cloud backups, so export their definitions by hand and record which ones trigger notifications, approvals or assignments. The step is complete when you have a signed-off inventory sheet that maps each item to a GLPI concept (ticket category, workflow, SLA, asset type) or marks it as retired.
Build a pilot GLPI instance
Your platform engineers deploy a pilot GLPI on your own infrastructure, using the documented prerequisites for the version you choose: PHP and a supported MariaDB or MySQL release, since only those two databases are supported. Point the web server document root at GLPI's public directory rather than the installation root, and configure URL rewriting to route requests through index.php. Confirm the version-specific PHP and database requirements against the current installation documentation before you provision. The step is complete when a test administrator can log in, create a ticket and see it on the dashboard, and the database and config directory are backed up.
Define the field mapping and configure GLPI
Using the inventory, your team writes a field mapping that links each Jira issue field, request type, status and SLA to its GLPI equivalent, and records where a concept has no direct match. Configure GLPI entities, categories, ticket statuses, SLAs and OLAs to match the mapping, and decide how authentication will work by reviewing the order GLPI tries its sources (internal database, LDAP, IMAP and external methods). Rebuild automation as GLPI business rules or workflow steps, and document any rule you choose not to rebuild. The step is complete when the mapping document is approved by the service owner and the pilot configuration matches it.
Run a test import of a representative project
Choose one representative Jira Service Management project with a mix of request types, comments and attachments, and export it through the Jira export options. Import the records into the pilot GLPI, then check counts, timestamps, requester and assignee identities, attachments and linked assets against the source. Repeat the import until the differences are explained and accepted. Assets are a separate extraction, so import them from their own CSV export and reconcile them against the inventory. The step is complete when a written reconciliation report lists every record count, every exception and the agreed fix.
Pilot the workflow with real agents
Ask a small group of agents to work the migrated project in the pilot for a fixed period you define in advance, covering normal requests, incidents, one change and an SLA breach scenario. Track where they cannot find a field, where a notification does not fire and where an approval step differs from Jira. Feed each finding back into the mapping and configuration and retest the affected items. The step is complete when the agents sign off that the core workflows operate and the open issues list contains only accepted gaps.
Run a parallel period with a defined cutover window
Migrate the full data set into production GLPI and keep Jira Service Management open for reading while both systems run. Decide in advance which system is authoritative for new work, how requesters are told where to submit, and who can reopen a Jira item during the overlap. Schedule a cutover window with a named owner, a freeze on new Jira items, a final delta import, and a rollback decision point. The step is complete when the final delta import reconciles against the source counts and the cutover is recorded as done in the change log.
Decommission Jira and keep a retained export archive
After the cutover is accepted, take a final full export of Jira Service Management, including the separate Assets export and any automation and app definitions recorded in step one, and store it in an encrypted location you control with a retention rule set by your records policy. Change Jira to read-only or retire the project, remove integrations, revoke service accounts, and update the service catalog and runbooks to point to GLPI. The step is complete when the archive has been verified by restoring a sample, the retention owner is named and the decommission is recorded.

What drives the cost and duration of a GLPI migration

This table compares the main cost and effort drivers for moving a Jira Service Management desk to GLPI, with the reason each one moves effort and how to keep it down. GLPI itself is free under GPL-3.0, so the real spend sits in hosting, implementation, optional support and staff time, which is why the rows focus there.

Driver	Why it moves cost or effort	How to keep it down
Size of the Assets estate	Each asset class needs a mapping to GLPI inventory or CMDB items, plus cleanup of duplicates and stale records before import	Export only active configuration items, agree the target item types first, and retire records that no longer map
Automation rules and apps to replace	Jira Cloud backups exclude automation rules and third-party apps, so each rule must be rebuilt by hand in GLPI rules, workflows or plugins	Inventory every rule and app from Jira, rank them by business use, and drop those nobody uses before rebuilding
SLA and approval complexity	Multi-level approvals, group-managed targets and conditional escalations take design and testing time in GLPI, including group-managed OLAs introduced in GLPI 12.0.0	Document current SLA logic in one table, simplify where policy allows, and test each path with sample tickets
Identity and monitoring integrations	GLPI authenticates against its database, LDAP, IMAP and other external methods tried in order, so directory and sign-in design affects rollout and support load	Confirm the directory source early, test LDAP bindings in a staging instance, and define which accounts stay local
Attachment volume	Large attachment sets increase export time, transfer size, storage sizing and the number of checks needed after import	Measure attachment totals per project, archive old closed tickets, and agree a retention rule before export
Number of request types and forms	Each request type needs its own form, category, routing and approval path, so catalog size scales the build directly	Consolidate similar request types, and reuse one form template with conditional fields where possible
Parallel run period	Running Jira and GLPI side by side doubles agent training, reporting checks and licence or hosting overlap for the period	Set a fixed cutover date, limit the parallel run to new requests only, and define exit criteria in writing
Hosting and infrastructure	Recurring cost for servers, PHP 8.3 or later, MariaDB 10.11 or later or MySQL 8.0 or later, backups and a web server, all run by the client	Size for current agent and asset counts, use the Docker option where it fits your platform team, and automate backups
Optional GLPI Network support	Under GLPI Network, self-hosted subscriptions start at 100 euros per month (Basic, up to 10 agents and 500 assets) and reach 4,500 euros per month (Enterprise), per the GLPI subscriptions page	Compare the agent and asset counts against each tier, and ask whether support is needed at go-live or only afterwards
Internal staff time	Administrators, service owners and agents spend time on data validation, process design, testing and training, which recurs as the process changes	Name one data owner per queue, reuse the test plan for later changes, and budget time for training before cutover

How to run Jira Service Management and GLPI in parallel and cut over

Run the two systems in parallel with a single rule: from a named cutover date, every new internal request, incident and change is created in GLPI, and Jira Service Management is limited to finishing work that was already open. Write that rule down, name the agents who own each queue, and publish the cutover date to requesters before the first GLPI ticket is created. Set an end date for JSM write access, after which the project closes JSM for new items and keeps it read-only for reference. Freezing the change calendar matters most here. Agree with the change manager that no new standard or normal changes are scheduled in JSM after the freeze, and that any change still in flight is either closed in JSM or re-raised in GLPI with its approvals copied across, so one change never has two live records.

Reopened and in-flight items need an explicit rule. A JSM ticket that a requester reopens after cutover should be answered in JSM only if it was resolved before the freeze, and otherwise moved to GLPI with a link back to the original key. Record the decision in a short register with the item, owner, target system and date, and review that register at a fixed interval until JSM has no open items. Confirm with your own team which Assets and CMDB records are authoritative during the overlap, because a configuration item edited in both places will diverge. Tell requesters about the new intake channels in the same message that announces cutover: the GLPI portal address, the email intake your team configures, and where urgent incidents go. Keep the old JSM address forwarding to a single message that explains the change, rather than leaving it silent.

After cutover, GLPI becomes a running platform, and its update discipline is a run-state responsibility. Before each upgrade, back up the database, the files and the config directory, including the glpi.key and glpicrypt.key files, because losing those keys can make stored encrypted data unreadable. The installation documentation describes replacing the application files and running php bin/console db:update. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so schedule time for plugin checks and test them on a staging copy first. Confirm the current PHP and database requirements for the version you plan to run, since the README and the installation docs list different minimums, and check the GLPI releases page for the release you target.

What usually goes wrong when moving an IT service desk to GLPI

Most failed moves from Jira Service Management to GLPI trace back to a handful of gaps: logic that never left Atlassian, data that lost its links, and cutover work nobody owned. Each card below names one of these gaps and a check you can run before and after the move.

Automation and approval logic is lost

Jira Cloud backups exclude automation rules, so routing, approval steps and escalation triggers do not come along with the tickets. GLPI has its own ticket rules and approval workflows, but they must be written again from a list of what Jira actually did. Export the automation rules from Jira as a reference, map each one to a GLPI rule or workflow, and test every rule with a sample ticket before go-live.

Asset relationships flatten on import

Assets objects and the links between them, such as a server supporting an application that depends on a database, are exported separately and often arrive as flat lists. GLPI represents these as itemtype relations, so a CSV import can keep the device records while dropping the connections. Confirm a sample of linked objects in GLPI against Jira before accepting the import.

Identities and group mappings do not match

GLPI tries authentication against the internal database, then LDAP directories, then IMAP, then other external methods such as REMOTE_USER, in that order. A user who exists in Atlassian with a federated login may fall through to a local account, or receive no group membership at all. Map each Jira group to a GLPI group and profile, then sign in as one user from each role to confirm access.

Attachments outrun the backup interval

Jira Cloud's backup manager requires 48 hours between backups when attachments are included, so a cutover that relies on a recent backup may still miss files uploaded in the final window. Plan a final attachment export close to the cutover, record its date, and compare file counts per project in GLPI against the export manifest.

Web server points at the wrong directory

The GLPI installation docs require the web server's document root to point to the public directory, not the installation root, with URL rewriting that routes requests through index.php. A root set to the installation folder exposes configuration and source files and breaks routing. Verify the document root on Apache, Nginx, lighttpd or IIS, and confirm that the config directory is not reachable from a browser.

Plugins stay suspended after upgrades

Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates. Teams that depend on a plugin for a form, SLA or inventory feature can find it silently off after the first upgrade. Keep a list of required plugins with their versions, reactivate them in a test copy first, and confirm each one works before the production update.

Cutover has no named owner

Migrations stall when no one owns the decision to freeze Jira, approve the data cut, and sign off the first week of GLPI tickets. Assign one accountable owner, a list of open items that must close before cutover, and a rollback point that keeps the Jira instance readable until agents confirm their queues. Record the sign-off in writing before Jira is set to read-only.

How the migration changes by starting point and team size

A small internal team with a few projects, standard request types and little automation usually has the shortest path. The main work is extracting work items, comments, users and project configuration, then recreating request categories, approval steps and a small set of SLAs in GLPI's ITIL modules. Because the data set is modest, teams often run one trial import into a non-production GLPI instance, check a sample of tickets against the source, and then do a single cutover.

Scope: Work items, comments, attachments and users, with request types rebuilt as GLPI ticket categories and templates.
Sequence: Stand up GLPI on your own infrastructure, load a test extract, validate, then cut over once.
Users: Confirm how agents and requesters will authenticate, since GLPI tries its internal database, LDAP and IMAP sources in order.
Rebuilt by hand: Simple SLAs, notification rules and the handful of automation rules you actually use.
Retention: Decide whether closed JSM tickets are imported or kept read-only in an archive.

Before you start, confirm with your team which JSM automation rules are business-critical, because the Cloud backup does not carry them.

Questions buyers ask before moving from Jira Service Management to GLPI

How much does moving from Jira Service Management to GLPI cost?

GLPI itself is free software under GPL-3.0, so the cost is in the work around it: hosting, the migration itself, the internal time to run the platform, and any optional vendor support. Hosting and infrastructure recur every year, while the export, mapping and cutover are largely one-time. The biggest drivers are the number of request types and workflows to rebuild, the volume and cleanliness of Assets data, and how many integrations depend on Jira. If you want a managed GLPI Network subscription from Teclib', the published rates 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, and the self-hosted subscription tiers start at 100 euros per month. Ask any vendor or partner for a written quote that separates one-time migration work from recurring hosting and support.

How long does a Jira Service Management to GLPI migration take?

No duration is fixed in advance, because the timeline follows the scope you agree. The main variables are how many request types, queues, approval paths and SLA definitions you need to rebuild in GLPI, how much Assets data must move, whether automation rules must be redesigned instead of copied, and how many user groups must be validated before cutover. A narrow scope covering incidents, service requests and a basic asset inventory moves faster than a full ITIL setup with change advisory boards and a CMDB. Ask for a phased plan with a pilot group, a parallel run period and a cutover date tied to a written scope.

What does our internal team need to provide during the move?

Your team needs to own the decisions that only your organization can make. That includes the process owners for incidents, problems, changes and requests, a clear list of which Jira projects and request types are in scope, and access to the Jira export and the Assets CSV export. Your team also decides on user authentication, since GLPI can check accounts against its internal database, an LDAP directory, an IMAP mail server or an external method such as REMOTE_USER, tried in that order. Plan for people to validate migrated tickets and asset records, and for an agent or two to test the rebuilt workflows before go-live.

Can we migrate from Jira Service Management to GLPI without a partner?

Yes, if your team has Linux, web server and database skills and time to test. GLPI is distributed under GPL-3.0, and its installation documentation covers the prerequisites, which include PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later for the current README, while the installation docs list older versions for GLPI 11.0. Many teams still bring in a partner for the parts that are hard to get right under pressure: mapping SLAs and approvals, validating data, hardening the server and documenting the result. DeployOpen plans, implements, integrates, hardens, backs up and documents self-hosted platforms in your own infrastructure under a written, fixed scope, so you can choose to do all, some or none of the work yourself.

Does GLPI cover change management and Assets the way Jira Service Management does?

GLPI covers ITIL incident, problem, change and service level management, along with asset inventory, configuration management, knowledge base and contract management. It is a reasonable fit for internal IT teams that need change records and a CMDB, but the exact workflow and approval behavior differs from Jira Service Management, so you should not assume a one-to-one copy. Jira's Assets object schemas, references and attributes need to be mapped to GLPI's asset types and relations, and you should confirm with GLPI or a partner how each Jira change workflow, approval step and asset relationship will be represented. Also note that Jira Cloud backups exclude Assets and automation rules, so those need their own export plan.

What do the Atlassian Data Center dates change for this move?

Atlassian ends sales of new Data Center subscriptions to new customers on March 30, 2026, sets March 30, 2028 as the last date for existing customers to buy licenses or expansions, and on March 28, 2029 Data Center licenses expire and become read-only. If you run Jira Service Management on Data Center, those dates set the outer limit for your decision, not the migration deadline. Working backward from March 28, 2029 gives you time to finish the scope, pilot, cutover and archive. Confirm the exact terms with Atlassian and your account team, since your contract and any expansion plans affect what you can buy.

What is the safest way to preserve our Jira data before cutover?

Start by treating the Jira Cloud backup as incomplete. Atlassian's backup manager includes work items, comments, users and groups, and project configuration, but excludes automation rules, third-party apps and Assets, and with attachments included Atlassian requires 48 hours between backups. Export Assets through the separate CSV export, record automation rules and app configuration by hand or from screenshots, and keep a read-only copy of the Jira data for the retention period your compliance team requires. Confirm with Atlassian which export formats and limits apply to your edition before the migration window opens.

What should we check on the GLPI server before going live?

Check that the web server document root points to GLPI's public directory rather than the installation root, that URL rewriting routes requests through index.php, and that the server runs a supported PHP and database version. Back up the database, the files and the config directory, including the glpi.key and glpicrypt.key files, before any update. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so test plugin behavior in a staging copy first. GLPI 12.0.0, released October 7, 2026, adds step-up authentication for certain administrative actions and an official Docker image, which you should evaluate against your security baseline.

How DeployOpen scopes and runs a GLPI migration from Jira Service Management

DeployOpen plans, implements, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For a move from Jira Service Management to GLPI, we start with a written scope that covers requests, incidents, changes and the Assets data that a Jira Cloud backup leaves out.

How we scope

Inventory which JSM projects, request types, queues and Assets object types are in use today
Agree in writing which request, incident and change records move, and which stay archived in JSM
Confirm where GLPI will run, how it connects to LDAP or SSO, and who owns the target environment

How we build

Extract Assets and automation rules separately, since Jira Cloud backups exclude them
Map JSM fields, statuses and request types onto GLPI tickets, categories and ITIL workflows
Test imports on a copy of the GLPI instance and reconcile record counts before cutover

How we hand over

Document the GLPI configuration, mapping decisions, import scripts and known gaps against JSM
Provide a runbook for the GLPI update procedure, including backups of the database and config keys
Walk service desk and administration staff through ticket handling, approvals and reporting

How we support

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
Ongoing support, upgrades and continuous testing are available as a retainer after handover
Ask for a written quote built from the agreed scope, since DeployOpen does not publish a price list

Migrate from Jira Service Management to GLPI