Most GLPI implementation guides read like a features list. The reality is messier: you have legacy data in three spreadsheets, a team that has never used a ticketing system, and a go-live date that was set before anyone scoped the work. Here is what a GLPI implementation actually looks like when done properly, phase by phase.
Phase 1: discovery
Before touching GLPI, map the current state. What tools exist? Who handles tickets today -- is it email, phone calls, someone walking to the IT desk? Which teams need access, and what do they actually do versus what their job description says? Discovery typically takes 3-5 days for a mid-size organization and produces a gap analysis document: what you have now, what you need, and where GLPI fills the gaps.
Phase 2: design
This is where the real decisions happen. The design phase covers four critical structures:
- Entity tree -- how your organization maps into GLPI's multi-tenant hierarchy (by location, department, or business unit)
- Category tree -- the ticket categories users will actually select (keep this under 50; more on that later)
- SLA definitions -- response and resolution targets per priority level
- Profile matrix -- who can see what, who can edit what, who gets Super-Admin (as few people as possible)
Design outputs a configuration specification document. Every decision gets documented so nothing is left to "we'll figure it out later."
Phase 3: data migration
Starting with an empty GLPI instance means losing institutional knowledge. Asset inventories, user lists, historical tickets -- all of this can be imported. GLPI supports CSV imports natively. For more complex migrations from tools like OTRS, Jira Service Management, or ManageEngine, scripted imports via the GLPI API are the way to go. Budget 1-2 weeks for data cleanup and import validation.
Phase 4: configuration and testing
Build the system according to the design spec. Configure entities, categories, SLAs, business rules, notification templates, and user profiles. Then test it -- not with the project team, but with actual end users from each department. Give them realistic scenarios: submit a ticket, approve a request, check asset details. Their feedback at this stage prevents problems after go-live.
Phase 5: training and go-live
Training is not optional. End users need to know how to submit and track tickets. Technicians need to understand assignment, tasks, and follow-ups. Administrators need to manage categories, templates, and reports. Run separate sessions for each group. Go-live works best as a hard cutover on a Monday morning -- no "parallel operation" period where people can still use the old system.
Phase 6: post-launch support
The first 30 days after go-live reveal what the design phase missed. Expect category adjustments, business rule tweaks, and notification template changes. Plan for a review meeting at day 7, day 14, and day 30.
Timeline and what kills projects
A straightforward GLPI deployment takes 4-6 weeks. Complex environments with multiple entities, custom plugins, and integrations run 8-12 weeks. Three things consistently cause failures: skipping discovery (the system doesn't match reality), not involving end users until go-live (they reject it), and trying to replicate the old system exactly instead of improving processes.