Start my assessment

Opteven: from GLPI to Jira Service Management, 500 tickets taken over with no service interruption.

Opteven replaced GLPI with Jira Service Management and Assets. BleuLemon ran the ITSM redesign: first release after 7 weeks, full production in under 4 months, 500 tickets taken over with no service interruption, service catalogue simplified. An application maintenance contract extended the engagement.

Banking, Finance & Insurance · ITSM redesign · Follow-on engagement: application maintenance contract

Key results.

7 weeksfrom the first line of scoping to the first release.
< 4 monthsto full production.
500 ticketsmigrated with no service interruption for the teams.
117 daysscoped in the initial plan, final consumption within the approved envelope.

An application maintenance contract (TMA) was signed after the release. Every figure on this page comes from an engagement document: scoping plan, acceptance report or activity record.

The context.

Opteven managed its IT services with GLPI. The tool worked, strictly speaking. It no longer carried the organisation: the service catalogue had stacked up over the years, requests came in through several doors, and the link between an incident and the hardware concerned still had to be pieced back together by hand.

The IT department was after two things at once: a service management platform maintained by the vendor, and a clean rewrite of the catalogue. The second point mattered as much as the first.

The real challenge.

01
No service outage

Support runs every day. A switchover that ties up the teams for a week costs more than the old tool.

02
A history to deal with, not to throw away

500 live tickets were waiting on a decision: migrate, archive, or deliberately drop.

03
A catalogue to simplify before reproducing it

Copying what already exists into a new tool means paying twice for the same disorder.

Changing ITSM platform is rarely the real issue. The real issue is what you do with inherited complexity.

The BleuLemon setup.

01
Scope

We began with the ways of working, not with the configuration: a review of the existing catalogue, interviews with the support teams, decisions on what deserved to be carried over. The scoping plan was approved at 117 days. The scope moved from 108 to 121 days as those decisions were made; final consumption stayed within the approved envelope, and we write it down because the opposite also happens.

02
Deploy

Configuration of Jira Service Management for the request and incident flows. Assets put in place to link every request to the hardware and applications concerned. The first release came after 7 weeks: not the whole scope, but the first genuinely usable flow, which gives the teams something concrete to criticise instead of a mock-up.

03
Drive adoption

The 500 tickets were migrated with no service interruption: agents carried on handling their requests during the switchover. The service catalogue was simplified, with a short tree so that the requester finds the right door without guessing. Full production followed, in under 4 months in total.

04
Keep it alive

Opteven signed an application maintenance contract after the release. The platform keeps evolving with the same consultants, which saves rewriting the context with every request.

Before, after.

TopicBeforeAfter
Service management platformGLPIJira Service Management
Link to hardware and applicationsPieced back together by handAssets, linked to the request
Service catalogueStacked up over the yearsSimplified, short tree
Request history500 live tickets in the old tool500 tickets taken over with no service interruption
Scoping envelope117 days approved, scope reassessed from 108 to 121 daysFinal consumption within the envelope
After the releaseNo follow-on contractApplication maintenance contract signed

Key takeaway. ITSM switchovers rarely fail on the technology. They fail on the catalogue no one dared to settle, and on the history no one wanted to look at. The value of structured support is not measured by how fast the first release arrives: it is measured by how solid what remains is once the project closes. Here, a readable catalogue, an inventory linked to the requests, and an application maintenance contract that carries the knowledge of the context forward.

BleuLemon, a French consultancy (Paris, Lyon) and Atlassian Platinum Solution Partner since 2008, holds the ITSM Specialized specialisation of the Atlassian partner programme.

Your service management tool works, but your catalogue has become unreadable and your history frightens you.

Let's talk specifics.

Frequently asked questions

A question that finds no answer here is dealt with in a thirty-minute conversation, about your actual context rather than a general case.

Talk to an expert
Can GLPI be replaced by Jira Service Management?

Yes, and Opteven did it. The difficulty does not come from the target tool but from the carry-over: service catalogue, permissions, ticket history and the link to the asset estate. We deal with these four subjects during scoping, before any configuration, otherwise the old disorder rebuilds itself in the new tool.

What happens to the ticket history during a switchover?

Three outcomes, to be settled during scoping: carried over into the new platform, archived outside the tool, or deliberately dropped. At Opteven, 500 tickets were carried over with no service interruption. For large Jira projects, our Aquarius solution extracts and archives a project as a browsable ZIP before migration.

How long does an ITSM deployment take?

It depends on the number of flows and the size of the catalogue. At Opteven, 7 weeks to the first release and under 4 months to full production. Our standard ITSM path runs in 5 stages over 90 days, from the assessment to the SLA review.

How do you measure adoption after the release?

With the support indicators, not with a self-reported satisfaction score. We track MTTR on incidents, the first-contact resolution rate on the portal, CSAT, compliance with the major SLOs, the backlog older than 14 days and the number of knowledge articles viewed per ticket.

Why an application maintenance contract after an ITSM project?

Because a service management platform moves every month: a new flow, a new service, a new team. Application maintenance (TMA) keeps the work in the hands of the consultants who built the configuration, with written service commitments. Opteven signed this contract after full production.

Going further: IT service management (ITSM / ESM)·Support, application maintenance and managed services·Change management·Aquarius·All case studies·The blog