What a GLPI migration involves
A GLPI migration usually starts with one of four triggers: leaving another ITSM tool, replacing a set of spreadsheets that track tickets or assets, consolidating several GLPI instances into one, or rebuilding an older GLPI on a currently supported stack. Each trigger brings a different source system and a different level of data cleanup, so the first task is to name the source, the data that must survive the move and the date by which the old system stops being the record. For an older GLPI, check the PHP and MariaDB or MySQL versions against the current prerequisites before you plan the data work, because a rebuild on a supported stack changes what the target can accept.
The data types that move are tickets, assets, users, groups, entities, knowledge base articles and contracts. Importing them is the mechanical part. Mapping is the hard part: deciding which source statuses become GLPI statuses, which source fields become dropdowns or custom fields, how departments become entities, how people and their group memberships are matched to user records, and which assets are duplicates. Ticket history, attachments and linked assets depend on each other, so a mapping error in users or entities shows up later as broken ownership on thousands of tickets. Settle the mapping document, with one owner per data type, before any test import runs.
The FusionInventory to GLPI Agent move belongs in the same project because the inventory data feeding your asset records changes source as well. Plan the agent rollout so that old FusionInventory reports and new GLPI Agent reports do not create duplicate computers. Decide how existing asset records are matched to incoming agent data, and confirm with your agent documentation which agent versions and deployment methods your fleet supports before you switch collection off on any device.
In-house or partner? A team with an experienced GLPI administrator and reasonably clean source data can often do parts of the work itself, such as exporting data, cleaning obvious duplicates and building a first test import. Mapping, validation and cutover decisions usually benefit from an outside party who has run these migrations before, because the costly mistakes are in ownership, history and reconciliation rather than in the import commands. Ask any partner to show how they reconcile record counts and sample tickets between source and target before go-live.
What the work includes
Each workstream ends in a named deliverable that you keep. The scope, deliverables and timeline are agreed in writing before work starts, and every source system is confirmed against its export options before any import is promised.
Source data assessment
We inventory what the current service desk, spreadsheets or older GLPI hold: ticket history, asset records, users, attachments and knowledge articles. We check which export formats and API endpoints the source offers, since not every system can export full history or attachments. The deliverable is a source data assessment report with known gaps.
Target data model and mapping
We map source objects to GLPI entities, profiles, groups, ticket categories, asset types and statuses. Decisions such as how old statuses translate and which entity owns imported assets are recorded before any data moves. The deliverable is a signed mapping specification that your business owners review.
Import tooling and scripts
We build or adapt the scripts that read the source, transform records and load them into GLPI through its supported interfaces. Each run is repeatable, logs rejected rows and keeps source identifiers so re-runs do not duplicate tickets. The deliverable is versioned import code with a run guide.
User and authentication mapping
We match source accounts to GLPI users, decide which users are created locally and which authenticate through LDAP, IMAP or another external method, and assign profiles from group membership. Ticket requesters and assignees must resolve to the right accounts after import. The deliverable is a user mapping table and an authentication plan.
Knowledge base content conversion
We convert articles, procedures and attachments into GLPI knowledge base entries, fix broken internal links and map article visibility to profiles and groups. Formatting loss from the source format is documented, and articles that need manual rewriting are listed. The deliverable is a converted content set with an exception list.
FusionInventory to GLPI Agent transition
We plan how existing FusionInventory Agent deployments are replaced by GLPI Agent, including the order of agent upgrades, inventory schedules and how duplicate computer records are merged. Machines that stop reporting during the transition are tracked. The deliverable is a transition plan and a device-by-device status list.
Validation and reconciliation
We compare record counts, sample tickets, asset totals and user access between source and target, and check that attachments open and links resolve. Discrepancies are classified and either fixed or accepted by a named owner. The deliverable is a reconciliation report with sign-off criteria.
Cutover runbook and rollback plan
We write the step-by-step cutover procedure, including the final incremental data load, freeze of the source system, DNS or URL changes, agent repointing and the go or no-go checks. The rollback plan states the point after which returning to the source is no longer clean. The deliverable is a runbook tested in a rehearsal on a staging copy.
Post-cutover hypercare
For an agreed period after go-live, we monitor import defects, user access issues, inventory gaps and scheduled jobs, and fix them within the agreed scope. Hypercare ends with a handover note and an open-issue register. The deliverable is the handover pack, and the length of hypercare is set in the written scope.
What drives cost and duration
This table lists the factors that change how much work a GLPI migration takes, why each one matters and how to keep it under control.
| Driver | Why it matters | How to reduce it |
|---|---|---|
| Source system and export quality | Clean CSV or API exports from the old tool cut mapping and cleanup time. Spreadsheets with merged cells, duplicate names or mixed date formats add manual correction work. | Ask for a full export sample early, agree on a field list, and fix obvious duplicates in the source before extraction. |
| Ticket and asset record counts | Import runtime, validation effort and reconciliation work scale with the number of tickets, assets and their relationships. | Agree which closed records are in scope. Archive or exclude old, low-value records instead of migrating everything by default. |
| Attachments and history depth | Attachments add storage, transfer time and failure risk. Each year of ticket history adds mapping rules for statuses and follow-up formats. | Decide a history cutoff with the business owners. Migrate recent attachments and keep older ones in a read-only archive if needed. |
| Entities and profiles to redesign | Each GLPI entity, profile and rights set has to match an existing team or access rule. Redesign work grows with the number of departments and exceptions. | Map the current organization chart to a small set of entities and profiles before any import script is written. |
| User count and directory structure | User records, group membership and authentication sources affect matching, duplicate handling and login testing. Nested or multi-domain directories add mapping rules. | Confirm whether users come from LDAP or Active Directory, and agree which groups drive profile assignment before the first test import. |
| Workflows, SLAs and business rules | Each approval path, escalation, SLA clock and business rule must be rebuilt in GLPI and tested against real ticket examples. | Document the top workflows in the current tool and cut rarely used paths from the first release. |
| Custom fields, forms and plugins | Custom fields and plugins that exist in the old tool must be reproduced or replaced. Plugin compatibility with the target GLPI version can change the work. GLPI suspends plugins after a new version is detected, and they must be reactivated after major updates. | Inventory every custom field and plugin, mark each as keep, replace or drop, and test plugin versions against the target GLPI release. |
| FusionInventory fleet size and platforms | Moving agents to GLPI Agent involves Windows, macOS and Linux endpoints, each with its own deployment and configuration path. Larger fleets need more rollout waves and verification. | Group endpoints by platform, pilot GLPI Agent on a small set first, and retire FusionInventory only after inventory results match. |
| Environments and cutover waves | Test, staging and production copies each need imports, validation and sign-off. More cutover waves, such as by entity or by region, add coordination and rollback planning. | Keep one staging copy that mirrors production, rehearse the import at least once, and limit the first cutover to one or two entities. |
Project phases and outputs
The sequence moves from inventory and design to a tested import, a rehearsed cutover and a supported go-live, with each phase closing on a named deliverable.
Inventory the source systems
We catalog every source of tickets, assets, users, contracts and knowledge articles, including the old service desk, spreadsheets and any FusionInventory installations. You receive a source inventory listing record types, volumes, owners, custom fields and known data quality issues, which you sign off before design starts.
Design the target model and field mapping
We design how entities, profiles, categories, statuses, assets, users and groups map from each source into GLPI, and decide what is migrated, archived or left behind. You receive a signed mapping specification with transformation rules and open decisions, which becomes the reference for every later test.
Build the import tooling on a non-production GLPI
We build import scripts or connectors against a separate GLPI instance installed on infrastructure you control, so no production data is touched. You receive versioned import code, a run guide and a log format that records every rejected or transformed record with its reason.
Run trial migrations and reconcile the results
Each trial imports a full or representative extract, then compares record counts by type and checks a sample of tickets, assets and users field by field against the source. Trials are repeated, with mapping or tooling fixes between runs, until counts and sampled records reconcile. You receive a reconciliation report per run showing differences and their resolution.
Pilot the GLPI Agent transition
We move a limited set of machines from FusionInventory to GLPI Agent, confirm inventory arrives in GLPI with the expected fields and that old and new agents do not duplicate assets. You receive a pilot result listing machines moved, inventory differences and the rollout steps for the remaining fleet.
Rehearse the cutover
We run the full production sequence on a copy of production data: freeze windows, final extract, import, reconciliation, DNS or mail collector changes and rollback. You receive a timed runbook with named owners and a rehearsal log that records any step that did not behave as written.
Cut over to production and support hypercare
We execute the rehearsed runbook on production, reconcile the final import, switch users and agents to GLPI, and then provide hypercare for the agreed period to resolve issues. You receive a signed cutover record with final reconciliation results, a handover pack and the list of open items handed to your team.
What usually goes wrong
Most GLPI migrations fail in a small number of predictable places, usually in the data movement and the cutover rather than the application install. Each pattern below lists the prevention step and the evidence that shows it was handled.
Lost or mismatched encryption keys
GLPI encrypts stored secrets with glpi.key and glpicrypt.key in its config directory. If the database is moved without the matching key files, encrypted fields such as stored credentials cannot be read after restore. Prevention: copy both keys with the database and files, and check the restored instance against a known encrypted value. Evidence: a signed record of the key checksums before and after the move, and a test login to a system with a stored credential.
Flattened or misassigned ticket history
Imports often collapse follow-ups, tasks and status changes into one description field, or attach tickets to the wrong requester or technician because identifiers did not match. Prevention: map each source field to a GLPI object before importing and decide how closed history is kept. Evidence: a sample of tickets from each category compared line by line against the source, with requester and assignee confirmed.
Duplicate users across sources
GLPI checks authentication against the internal database, LDAP, IMAP and other methods in order, so an imported local account can coexist with the same person arriving through directory sync. This produces two identities, split ticket ownership and mismatched profiles. Prevention: agree the authoritative source for each user and match on a stable identifier before import. Evidence: a duplicate report run after import with zero open conflicts.
Entities and profiles copied unreviewed
Copying the old tool's entity tree and profile rights preserves its historical shortcuts, such as broad technician rights or obsolete departments. Prevention: redesign entities and profiles from current responsibilities, then map old roles onto them. Evidence: an approved role matrix listing who can see and change each entity, with a test account for each profile confirming access.
Broken asset relations
Assets, their models, locations, contracts and linked tickets depend on consistent dropdown values and identifiers. Imports that create duplicate models or drop links leave inventory that looks complete but cannot answer questions. Prevention: load dropdowns first, then assets, then relations, and reconcile counts at each step. Evidence: a count comparison per asset type and a sample of linked records traced in both systems.
Agents still reporting to the old server
Machines running FusionInventory agents keep sending inventory to the old endpoint after cutover unless their configuration is changed. The new server then shows stale data and the old one keeps receiving updates. Prevention: plan the move to GLPI Agent as its own workstream with a target endpoint and rollout waves. Evidence: a report of agents by last contact time showing the old endpoint has no sessions after the cutover date.
Plugins left inactive after updates
Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates. A migrated instance can look healthy while plugin-driven forms, rules or collectors are silently off. Prevention: list every plugin with its target version and compatibility before cutover, then reactivate and test each one. Evidence: a signed plugin register with status and test result per plugin.
PHP and database prerequisites missed
The current GLPI README lists PHP 8.3 or later and MariaDB 10.11 or later, or MySQL 8.0 or later, while the GLPI 11.0 installation docs list older minimums. Teams that build the new server from an older template discover the gap during db:update. Prevention: check the target versions against the release you are installing before provisioning. Evidence: a recorded version check on the staging server, including the PHP modules and database version.
Email collectors and cron jobs not moved
Email collectors that create tickets from mailboxes and the GLPI cron tasks for notifications, alerts and cleanup run on the server, not in the application. If they stay pointed at the old host, tickets stop arriving or duplicate. Prevention: inventory every collector and scheduled task, disable them on the old system, and enable them on the new one in a planned order. Evidence: a test email per collector producing exactly one ticket, and cron run logs from the new server.
What stays in-house and what goes to a partner
This table compares the migration work areas your team should keep control of with those a partner usually carries, along with the skills each side needs.
| Work area | Usually kept in-house | Usually outsourced | Skills needed |
|---|---|---|---|
| Business rule decisions | Which tickets, statuses, categories and SLA terms map to GLPI and which are retired | Documenting current rules and proposing a GLPI mapping for your review | Service desk process ownership and GLPI administration |
| Data ownership sign-off | Naming an owner for each source dataset and approving what is imported, archived or dropped | Preparing an inventory of source datasets with record counts and sensitive fields flagged | Data governance and knowledge of business records |
| History retention | Deciding how many years of tickets, attachments and asset history to keep | Estimating the size and import effort of each retention option | Records management and legal or audit awareness |
| Source exports | Granting read access to the source tool and confirming export scope | Writing export queries or scripts and checking exports for completeness | Source system administration and database access |
| Target design | Approving entities, profiles, locations, asset types and custom fields in your GLPI | Drafting the target data model and the field-level mapping document | GLPI administration and data modeling |
| Import tooling | Reviewing the code or import method and running it under change control | Building and testing the import scripts or GLPI Agent migration steps | Scripting (typically PHP or Python), GLPI API and database access |
| Trial runs and rehearsal | Attending sign-off sessions and checking sample records in the test instance | Running repeated trial imports and a full rehearsal on a copy of production data | Linux or Windows server administration and GLPI administration |
| Reconciliation | Confirming counts and spot-checking records that matter to operations | Producing reconciliation reports comparing source and target counts, totals and key fields | Database access and reporting skills |
| Directory and user mapping | Naming a directory service owner who confirms user, group and profile assignments | Mapping imported users to LDAP or Active Directory accounts and testing sign-in | Directory service administration (LDAP or Active Directory) |
| Agent deployment | Approving the rollout schedule and handling endpoint access and change windows | Preparing GLPI Agent packages and migration steps from FusionInventory | Windows, macOS or Linux endpoint administration |
| Cutover approval | Making the go or no-go decision and signing off the reconciliation results | Preparing the cutover runbook, rollback steps and timing plan | Change management and incident coordination |
| Post-cutover support | Owning daily operations, user communication and final decisions on data fixes | Providing agreed support for defects found after go-live, if included in the scope | GLPI administration and service desk operations |
How the work differs by starting point
Moving from a commercial ITSM product is usually a question of what the source can export. Where it offers an API or scheduled report exports, most of the effort goes into mapping its ticket states, categories and custom fields onto GLPI's model, not into extraction.
- Mapping: Map ticket statuses, priorities and categories to GLPI equivalents, and decide which source fields become GLPI custom fields, dropdowns or notes.
- Tooling: Choose between API extraction and report files. Reports often drop attachments, relations or history, so confirm which of these the export carries.
- Validation: Compare record counts per status and per requester, then sample tickets end to end, including attachments and follow-up threads.
- Confirm first: Ask the source owner for the export formats available, the API rate limits, the data retention period and any fields that are calculated rather than stored.
- Scope driver: The number of custom fields and workflow states in the source usually moves effort more than ticket volume does.
Spreadsheets have no system history, so the migration creates the first record of each asset, user and ticket. The work is mainly cleansing and deciding what history is worth carrying forward at all.
- Mapping: Define the GLPI item types for each sheet tab, and resolve duplicates such as the same laptop listed twice or one owner spelled three ways.
- Tooling: Use staged CSV imports with a validation pass, rather than loading files directly, so errors can be fixed in the sheet and reloaded.
- Validation: Reconcile counts against the sheet owner's control totals, and have a named person sign off on a sample of assets and locations.
- Confirm first: Ask how many sheets exist, how many have consistent column headers, and whether any values are maintained by formulas that will not survive the export.
- Scope driver: Data quality is the main cost. Agree in writing who performs the cleansing, because the client team usually holds the knowledge needed to resolve conflicts.
Merging several GLPI instances into one means deciding how the old instances become entities, profiles and groups in the target. Identifiers, users and configuration must be reconciled, because records from different instances can collide.
- Mapping: Decide which source instance maps to which entity tree, and how users who exist in several instances are merged into one account with the right profile per entity.
- Tooling: Export from each source database with a consistent ID strategy, then remap foreign keys during import so tickets keep their links to assets and users.
- Validation: Check that each entity holds only its own assets and tickets, and that visibility rules return the expected results for test users in every profile.
- Confirm first: Ask each instance owner for its version, plugin list, custom dropdowns and any duplicated asset tags across sites.
- Scope driver: Overlapping users and duplicate configuration, not raw data volume, usually decide how much rework is needed.
When the source is an older GLPI, the data move and the version upgrade can be combined or kept separate. Doing both at once gives one cutover, but it makes faults harder to trace, so the sequence is a design decision.
- Mapping: Compare the schema and dropdown structure of the old version with the target. Changes between major versions can affect plugin data and custom fields.
- Tooling: Upgrade a copy of the database in steps through each supported version, running the database update command at each stage, before importing anything into the new instance.
- Validation: Confirm that the upgraded copy works before any data is moved, then repeat the record checks on the migrated data after cutover.
- Confirm first: Ask for the current version, the PHP and database versions in use, and whether plugins are still maintained for the target release.
- Scope driver: Plugin compatibility and the number of version steps between the source and target decide whether the work can be done in one pass.
Moving a large fleet from FusionInventory to GLPI Agent is mainly an inventory continuity exercise. The aim is that each asset keeps one history in GLPI, with no duplicate records created when agents report under new settings.
- Mapping: Match devices by a stable identifier such as serial number or hardware UUID, and decide how the old FusionInventory assets are linked or archived.
- Tooling: Roll out GLPI Agent in rings, starting with a pilot group, and stop the old agent per ring so the same device does not report twice.
- Validation: Compare the asset count and key fields per site before and after each ring, and check for duplicate records created by changed hostnames.
- Confirm first: Ask how many endpoints run FusionInventory, which operating systems they use, and whether network discovery or remote ESX inventory is in use.
- Scope driver: Fleet size and the number of distinct operating systems and locations shape the rollout waves more than the database does.
Running the migration in a container or on servers with no internet access changes how tools and packages reach the target. Every import script, dependency and image must be staged inside the network before work begins.
- Mapping: The mapping is the same as in other starting points, but any reference data that normally comes from online sources must be copied in advance.
- Tooling: Pull the GLPI image or package and migration tools into an internal registry or artifact store, and pin versions so the target matches the tested build.
- Validation: Run the migration on an isolated staging environment built the same way as production, and record any step that depends on external access.
- Confirm first: Ask whether the container platform is already operated by the client, which registry and storage the environment uses, and how data is transferred in and out.
- Scope driver: Transfer approvals and the number of artifacts to stage, rather than the migration logic, often set the timeline.
What you need to provide
Most of the schedule risk in a GLPI migration sits in inputs that arrive late, so the client should start gathering them before any mapping work begins. First, before the discovery workshops: read access or full exports from the source system (another service desk or an older GLPI), a representative sample of records for each type (tickets, assets, users, knowledge base articles, contracts), and an owner who can answer questions about each entity and profile. Decide now what history must be kept and how long closed tickets must stay readable, because that choice changes the import scope and the storage sizing.
Before the mapping workshops: provide the directory or LDAP connection details with a service account that can read users and groups, and confirm how existing identities should match to GLPI accounts. Provide a list of FusionInventory agent endpoints with their operating systems, so the team can plan the move to GLPI Agent. Name a decision owner for each entity and each profile, since these owners resolve mapping conflicts such as duplicate categories or legacy statuses that have no direct equivalent.
Before the first test import: provide a non-production server or container host that matches the planned GLPI version, along with database and web server access for the migration team. The GLPI installation docs list supported PHP and MySQL or MariaDB versions for each release, so confirm these against your target before provisioning. Keeping this environment separate from production lets imports be repeated until the mapping is stable.
Before cutover: agree a cutover window that allows a final export, import, validation pass and rollback, and name the people who will sign off validation results for tickets, assets, users and the knowledge base. Sign-off should be written and tied to the validation checks, so the decision to switch is not left to an informal review on the day.
Frequently asked questions
Can our own team run a GLPI migration without an outside partner?
Often yes, if you have a staging server, someone who can administer the web, PHP and database stack, and time for testing. The work moves through five stages: export from the source, data mapping, import, validation and cutover. Most teams underestimate validation. Ticket, asset and user counts must be reconciled, and business users should check their own open work. Confirm the PHP and MariaDB or MySQL versions your target release needs before you start. Name one owner for mapping decisions, because choices about statuses, categories and ownership are business decisions as much as technical ones.
What drives the cost and duration of a GLPI migration project?
Source complexity is the main driver. Cost rises with the number of source systems, the volume of history that must survive, the state of the source data, and the number of asset types and custom fields that need mapping. Attachments and audit history add import and test time. Plugins and any intermediate upgrades change the plan. Costs split into scoping and mapping, import tooling, validation, cutover support and internal staff time. Ask for a quote that shows each phase, which costs are one-time, which recur, and which data volume assumptions it depends on.
Can tickets, attachments and full history move into GLPI intact?
Most of it usually can, but confirm your import path first. Core ticket fields, follow-ups, tasks, assigned groups and linked assets map well when the source exposes them through an export or API. Attachments usually need to be exported as files and linked again. Original timestamps and authors may need special handling, because GLPI records its own history. Some source fields will have no equivalent in GLPI. Agree in writing which fields are migrated, which are archived as read-only attachments and which are dropped. Confirm import options with the source vendor where needed.
How do FusionInventory agents move over to GLPI Agent?
The move is mainly a deployment change. GLPI Agent is the successor of FusionInventory Agent. You install it on each endpoint, point it at your GLPI server, and retire the old agent once inventory arrives reliably. GLPI Agent also covers network discovery, package deployment and remote ESX inventory, so decide which tasks you will use before rollout. Roll out in waves, stop old and new agents from reporting in parallel, and check that asset matching updates existing computer records without creating duplicates. Confirm configuration settings and compatibility with your target GLPI version in the agent documentation.
Can a GLPI migration happen without downtime for users?
Only if your source system supports a delta import at cutover. The usual pattern is a full trial import on a staging copy, timed so you know how long it takes, followed by a short write freeze on the source while the final changes are imported. Keep the old tool readable for a defined period so users can look up history. The length of the freeze depends on your data volume, the source export options and how well the trial runs went. Do not plan for zero downtime until those points are confirmed in your environment.
What happens to plugins and encryption keys during a GLPI migration?
Back up glpi.key and glpicrypt.key before any other step. Losing them can leave encrypted data unreadable. Since GLPI 11.0, plugins are suspended when a new version is detected, so each plugin must be checked for compatibility and reactivated after a major update. Build the plugin list during scoping and drop any you no longer need. Back up the database, files and config directory together, and test a restore on staging. Choose the target release, such as GLPI 11.0.11 or GLPI 12.0.0, only after each plugin publisher confirms support for it.
How DeployOpen delivers GLPI migrations
DeployOpen scopes GLPI migration from another service desk or an older GLPI as a written, fixed-scope engagement, then maps, imports, validates and cuts over the data inside infrastructure you control. Ongoing support is available as a retainer once the new instance is live.
How we scope
- Inventory the source tool, its ticket types, asset classes, users, groups and knowledge base articles before agreeing on the target design.
- Agree in writing which records, attachments, history and FusionInventory machines move, and which are archived or retired.
- Confirm the target GLPI version, PHP and database prerequisites, and whether the source is a spreadsheet, another ITSM tool or an older GLPI.
How we build
- Write a field-by-field data mapping for tickets, assets, users, entities and knowledge base content, then review it with your service desk owners.
- Build import tooling and run repeated test loads on a staging copy, logging rejected rows and reasons for each batch.
- Plan the FusionInventory to GLPI Agent move as a separate track, with agent deployment and inventory comparison checks before cutover.
How we hand over
- Validate record counts, field values, attachments and user access against the agreed mapping, and document every exception that remains.
- Deliver a cutover runbook covering the freeze window, final delta load, DNS or URL changes, rollback steps and sign-off points.
- Hand over mapping documentation, import scripts, validation reports and admin notes so your team can repeat or audit the migration.
How we support
- Confirm after go-live which support tasks are covered by the fixed-scope agreement and which move to a retainer.
- Keep backup and restore points for the migrated database and config directory, including the encryption key files, during the stabilization period.
- Offer ongoing support, upgrades and testing as a retainer, with the scope and response expectations written down before work starts.
