Every failed GLPI implementation follows a pattern. The technology works fine -- the problems are almost always decisions made (or not made) during setup. Here are seven mistakes that come up repeatedly, with specific guidance on avoiding each one.
Mistake 1: replicating the old system
The most natural instinct when migrating to GLPI is to recreate exactly what you had before. If the old tool had 47 custom fields on the ticket form, the new one should too.
This is a trap. The old system's design reflects accumulated workarounds for limitations in the old tool. GLPI has different strengths. Start with "what do we actually need?" rather than "what did we have?"
Mistake 2: too many categories
A category tree with 200+ entries looks thorough on paper. In practice, users cannot find the right category, so they pick "Other" or "General" every time. The category data becomes useless for reporting.
Keep the top level to 8-12 categories. Use sub-categories sparingly -- two levels deep at most. If a category gets fewer than 5 tickets per month, merge it with something broader. The goal is categorization that is accurate because it is simple, not comprehensive because it is detailed.
Mistake 3: no data migration plan
Going live with an empty GLPI instance throws away institutional knowledge. Historical tickets show recurring problems. Asset inventories provide baselines. User data enables proper assignment from day one.
Plan the migration early. Decide which data to bring over (active tickets, last 12 months of history, current assets, all users) and which to archive. Use GLPI's CSV import or API for structured data. Validate before go-live.
Mistake 4: skipping user training
"It's intuitive" is not a training plan. GLPI's self-service portal is straightforward for submitting tickets, but technicians need to understand assignment, tasks, follow-ups, and SLA tracking. Administrators need to know business rules, templates, and reporting.
Run three separate sessions: end users (30 minutes), technicians (2 hours), administrators (half day). Record them for future hires.
Mistake 5: no SLA definitions at go-live
Without SLAs, there is no way to measure service quality. "We'll add SLAs later" usually means they never get added, or they get added months later with no historical data to compare against.
Define at least four SLA tiers (P1 through P4) before go-live, even if the targets are approximate. Having measurable targets from day one provides baseline data. Refine the targets after 90 days based on actual performance.
Mistake 6: everyone is Super-Admin
Giving every technician the Super-Admin profile eliminates permission-related support requests -- in the short term. In the long term, it means anyone can delete assets, modify business rules, change SLA definitions, or export all user data. One accidental bulk delete and you are restoring from backup.
Use the principle of least privilege. Most technicians need the Technician profile. A small number of people (2-3 per entity) need Admin. Super-Admin should be reserved for the GLPI system administrator only.
Mistake 7: no post-launch review
The first month of production use surfaces problems that testing did not catch. Categories that seemed logical turn out to confuse users. Business rules fire in unexpected combinations. Notification templates contain wrong information or go to wrong recipients.
Schedule review checkpoints: day 7 (quick pulse check -- are tickets flowing correctly?), day 14 (review category usage, SLA compliance, user feedback), day 30 (comprehensive review with adjustment plan). The organizations that skip these reviews end up with a system that technically works but that nobody trusts.