The difference between a GLPI deployment the team actually uses and an installation that sits on the shelf comes down to planning before kickoff — not the technical quality of the deployment itself. This article is a six-step plan covering the decisions that determine whether GLPI is a live tool 12 months later or an abandoned URL.
Step 1: Define what GLPI is supposed to fix
Before any technical conversation, answer the "why are we doing this" question. Specifically, not in marketing terms:
- Current state: how many open IT requests sit in Outlook archives right now? (Real check — guesses don't count.)
- Top three problems we want to solve in the first 6 months (e.g. visibility on open tickets, asset register, incident audit for ISO 27001).
- Who is the business sponsor (not IT)? CFO, COO, CIO?
- What happens if GLPI doesn't deliver after 6 months? (Rollback plan, definition of "success" in KPIs.)
Without these answers, the project is defined by technology rather than by the business. That's the most common reason a deployment becomes shelfware.
Step 2: Project planning
A GLPI implementation in a mid-sized company (50 – 500 employees) takes 8 – 16 weeks. The plan covers:
- Scope: which GLPI modules ship in phase 1 (typically Tickets + Inventory; Projects, Problems, Changes go to phase 2).
- Timeline: weekly milestones, not monthly ones.
- Budget: licence is €0, but internal time + possible external services (40 – 80 hours of consulting is typical for a first deployment).
- Roles: project manager, "GLPI champion" inside the IT team (the person who'll own it post-go-live), business sponsor.
- Risk register: dependencies (LDAP integration, monitoring webhooks), prerequisites (support@ mailbox, SSL cert, backup process).
Step 3: Configure for the business processes
GLPI is highly configurable, which is a trap — without a plan, you can lose a week clicking through menus. Make these decisions in this order:
- Entity structure — one entity for the whole company, or split by department? (Entity-based RBAC hinges on this.)
- Ticket categories — top 10 categories based on analysis of the last 200 emails. No more.
- Asset types and their classification — see the asset taxonomy.
- Profiles and permissions — End-user, L1, L2, manager, admin. Nothing else in phase 1.
- SLA and notifications — start with one SLA (P1: 4h TTR, everything else: 2 days), add more after the first 2 months.
Step 4: Data migration
When transitioning from another tool (or from Excel) data migration is the riskiest step. Questions before importing:
- Which historical data is actually needed? (Tickets from the last 12 months yes, 5 years no.)
- What format is the source export — CSV path or via API?
- Will inventory go via Excel import, or will you let GLPI Agent rediscover everything? In most cases fresh agent rollout is cleaner than migrating a stale Excel.
- Mapping old categories to new ones — not 1:1, since the new ones are reorganised.
Plan trial imports into a staging GLPI instance before running the production import.
Step 5: Team training
Training happens in two waves:
- 2 weeks before go-live — IT team (2 hours for technicians, 1 hour for the manager). Goal: technicians can work tickets and don't bail at the first problem.
- First week after go-live — end users. A short 5-minute video instruction + an email with the portal link. No formal training for 200 people; 90% will figure it out.
The most successful training has one "GLPI champion" available for the first 2 weeks for quick questions. Without that, tickets drift back to email.
Step 6: Go-live and follow-through
Go-live should be staged, not big-bang:
- Week 1: pilot with a single department (typically finance or HR — smaller, structured, willing to cooperate).
- Weeks 2 – 3: feedback from the pilot, tune categories and templates.
- Week 4: full company rollout. The support@ email address keeps working but it auto-creates tickets in GLPI.
- Week 8: first retrospective — how many tickets, which categories, where the team gets stuck.
- Months 3 – 6: add more modules (Problems, Changes, Projects), more SLAs, more categories as needed.
Common implementation mistakes
For a concrete list of what typically goes wrong in year one, see common GLPI implementation mistakes. This guide doesn't cover them all — but the six steps above are the framework you can drop them into when they appear.
A GLPI implementation isn't a technical project with business consequences; it's a business project with technical execution. The six steps above reflect that ordering. Planning and training take longer than the install itself — and that's the right ratio.