Migrate from TOPdesk to GLPI

Migrate from TOPdesk to GLPI: what moves cleanly and what does not

A move from TOPdesk to GLPI is a data and process project with a clear sequence: secure a complete data copy, map each TOPdesk object to a GLPI object, import in controlled batches, then validate and cut over. It is usually run by the IT service owner, who holds the process decisions, with an implementation partner handling the mapping scripts, imports and testing. GLPI covers incidents, problems, changes, assets, knowledge base and contracts under GPL-3.0, so most of the work is mapping and import rather than building new capability. Effort depends on data volume, how many custom workflows and forms TOPdesk carries, and how many integrations feed or read from the desk. Confirm the current stable release with the GLPI project before planning, because the latest published major version is GLPI 12.0.0, released on October 7, 2026, and point releases may have landed since. Pin the target version early, since the import mapping and any plugins depend on it.

Start with the data you can actually get out. TOPdesk exports depend on what your contract and support channel allow, so ask TOPdesk Support, in writing, for a full data copy from backup and confirm its format, its date range, and whether attachments are included as separate files. Plan for the post-termination backup window now: find out how long TOPdesk keeps your data after the subscription ends and whether that date falls before your cutover, because a missed window can leave gaps you cannot fill later. Attachments usually need a separate download pass and a file-name mapping, so reserve time for that. Keep a dated inventory of what you received, including record counts per object type, so the reconciliation after import has a baseline.

Map before you import. Decide how TOPdesk incidents and changes become GLPI tickets, how operational and strategic problems map to GLPI problems, how persons and their locations map to GLPI users, groups and entities, and how assets and their relationships map to GLPI asset types. Use the spreadsheet import for small, flat object sets and the GLPI API for relationships, attachments and anything that needs repeatable scripting. Test with a copy of a representative subset first, and keep the mapping file under version control. Expect the parts that do not move cleanly: TOPdesk-specific workflow states, custom fields and approval chains need a decision each, either rebuilt in GLPI or retired. Record every decision so the process owner can sign off on what was dropped.

Which TOPdesk capabilities map to GLPI, and where rework is needed

This table maps the main TOPdesk capability areas to their closest GLPI equivalent and flags where migration is clean and where it needs rework, configuration or process change. Confirm every row against your own TOPdesk configuration, because customized forms, call types, operator groups and approval chains vary widely between organizations. Treat the rework column as the place to budget design time before data moves.

TOPdesk capability	GLPI equivalent	Migration notes: clean, needs rework or gap
Incidents and service requests	Tickets with incident and request types, categories and SLAs	Needs rework: map TOPdesk call types and request forms to GLPI categories and ticket templates. Confirm how your request catalog is structured.
Problem and change management	Problem and change objects with ITIL workflows and approval steps	Needs rework: TOPdesk-specific approval chains and change templates usually need rebuilding as GLPI validation rules. Confirm each approver path.
Assets and configuration records	Asset inventory and configuration items linked to tickets, plus GLPI Agent inventory	Clean for hardware and software types that match GLPI models. Needs rework for custom asset types, relations and fields. Confirm field lists before import.
Persons and locations	Users, groups, entities and locations, with LDAP or IMAP authentication	Needs rework: decide how TOPdesk branches and rooms map to GLPI entities and locations. Confirm how person records link to login accounts.
Knowledge base	Knowledge base articles, rewritten in GLPI 12.0.0	Clean for article text and categories. Needs rework for attached files, links and visibility rules. Confirm article ownership and review dates.
Contracts and service level agreements	Contract management and OLAs and SLAs with calendars	Needs rework: recreate SLA and OLA targets and business hour calendars. Group-managed OLAs need confirmation against your agreements.
Facility and shared service workflows	Generic ticket workflows with plugins or custom forms	Gap: GLPI does not cover facility or shared service processes out of the box. Expect plugin selection, configuration or process change. Confirm scope.
Reporting and dashboards	Built-in statistics and dashboards, with custom reports	Needs rework: rebuild each TOPdesk report and confirm the fields it reads. Compare totals against the source system before retiring TOPdesk.

How to get data and integrations out of TOPdesk

TOPdesk does not supply a self-service bulk export in the sources we can cite here, so the data copy starts with a written request to TOPdesk Support. The cards below cover each data class you need to move and the integrations that must be rebuilt on GLPI rather than copied.

Incidents and changes

Ask TOPdesk Support in writing for a copy of incident and change records, with their status history, linked objects and comments, and state that you need them in a structured format you can map. Confirm which formats the tenant can receive before you agree a timeline. Run a test extract of a small set of closed and open records and check that ticket numbers, timestamps, operator and group assignments, and resolution text survive. Map TOPdesk categories and impact or urgency values to GLPI ticket types, categories and priorities before any bulk import.

Assets and configuration items

Request the asset register and its relationships to persons, locations and contracts in the same written request, since GLPI imports link these objects together. Asset types, model names and serial numbers often differ between TOPdesk and GLPI's inventory model, so agree the mapping before extraction. Pair the import with GLPI Agent on endpoints if you want hardware and software inventory to refresh automatically after cutover, rather than copying stale records forward.

Persons, groups and locations

Persons, operator groups and the location hierarchy determine who sees which tickets in GLPI, so they need the most careful check. Ask TOPdesk Support for the person records with their login names, email addresses, department and location links. Note that user passwords cannot be exported from TOPdesk and that GLPI authenticates users from its internal database, LDAP or other external methods, so plan which accounts are created locally and which come from your directory.

Attachments

Attachments are typically stored separately from structured records, so a database extract may contain only file references. Ask TOPdesk Support in writing whether attachments are included in the backup copy or must be downloaded from the application, and confirm who performs that download. Verify a sample of attachments by opening them after import and check that the file names and links from incidents and changes still resolve in GLPI.

Knowledge base articles

Request knowledge base articles with their categories, visibility settings, authors and last-modified dates. GLPI 12.0.0 includes a rewritten knowledge base, so confirm how the target version handles article hierarchy, audience and media before you map TOPdesk content. Check that embedded images and internal links are rewritten, because they often break during transfer and are hard to spot in bulk.

Email, directory sync and monitoring feeds

Integrations are not part of a data copy. Inventory every inbound email address, LDAP or directory sync, monitoring alert feed and API consumer that creates or updates TOPdesk records, and rebuild each one against GLPI during the migration. Test that alerts create tickets with the correct category, that directory changes update persons and groups, and that no feed continues writing to TOPdesk after cutover.

The migration sequence from inventory to decommission

The sequence moves from a complete inventory of TOPdesk configuration and data to a signed archive and retired subscription, with each stage producing a document or dataset the next stage depends on. Start the data copy request in the first stage, because TOPdesk Support fulfils it and its timing sits outside your project plan.

Inventory TOPdesk configuration and data
Map everything that exists before any import: incidents, changes, problems, assets, persons and groups, operator roles, categories, custom fields, workflow and escalation rules, knowledge base articles, attachments and reports. Request the data copy from backup through TOPdesk Support at this stage, since the request depends on their team and its turnaround is outside your control. Ask them to confirm the export format, the scope of what is included, and whether attachments are delivered separately. The output is a field mapping sheet that pairs each TOPdesk field with a GLPI object, plus a list of data you will not migrate and why. The step is done when every TOPdesk object type has a named owner and a mapping row.
Pilot import into a staging GLPI
Install a staging GLPI instance separate from production, using the PHP and database versions that the installation prerequisites list for the release you choose. Import a representative slice of incidents, changes, assets and persons, including records with attachments and linked objects. Use spreadsheet import for flat objects and the API for linked records and attachments. Compare record counts, then check sample tickets side by side with TOPdesk for dates, status, assignee, categories and asset links. The output is a reconciled pilot dataset and a discrepancy log signed off by the process owner. The step is done when each discrepancy is either fixed in the mapping or accepted in writing.
Run TOPdesk and GLPI in parallel
Keep TOPdesk as the system of record while a small group of operators works through test tickets in the staging GLPI. Repeat full imports against the corrected mapping until counts and sampled records reconcile. Validate the connected services as well: inbound email intake, authentication (GLPI tries the internal database, then LDAP, then IMAP and other external methods in that order), and any monitoring or asset discovery feeds. Train agents on GLPI forms, approvals and SLA handling. The output is a list of open items at cutover, each with an owner and a severity. The step is done when no open item blocks normal ticket handling and the business owner has reviewed the list.
Cut over to production GLPI
Freeze new entries in TOPdesk, run the final import from the agreed export, and reconcile counts and attachments against the frozen source. Resolve the blocking open items and record the non-blocking ones with owners. Switch email routing, portal links and integration endpoints to GLPI, then announce the change to users and agents. Store the GLPI config directory keys, including glpi.key and glpicrypt.key, in your secrets backup from the first production day, because losing them makes encrypted data unreadable. The output is a cutover record with reconciliation results and an open-items list accepted by the business owner. The step is done when agents create and close tickets in production without falling back to TOPdesk.
Archive TOPdesk data and decommission
Before ending the TOPdesk subscription, ask TOPdesk to confirm in writing the post-termination backup window and how long your data stays available afterward. Make your own archive copy in a readable format, such as exported files with checksums, and store it under your retention policy. Remove TOPdesk integrations, revoke operator and API access, and confirm that nothing still writes to the old instance. The output is a signed archive record that names the scope, the date, the custodian and the storage location, together with a decommission record. The step is done when the archive has been tested by opening sample records and the access revocation is confirmed.

What drives the cost and duration of the migration

This table lists the factors that change how much work a TOPdesk to GLPI move takes and what it costs, with a practical way to keep each one under control. Use it to scope a quote, since most of the effort sits in data quality, custom objects and identity integration rather than in the software itself. One-time work (mapping, import, testing, training) and recurring work (hosting, backups, upgrades, support) are separated in the rows below.

Driver	Why it changes cost or effort	How to keep it down
Record volume and attachment size	Incidents, changes, persons and assets all need export, transformation and import time. Attachments must be downloaded separately from TOPdesk, so large attachment sets add transfer and storage work.	Confirm record counts and total attachment size with TOPdesk Support early. Archive closed records you do not need to carry over.
Custom fields and workflows	Each custom field, status or workflow that has no direct GLPI equivalent needs a mapping decision, a configuration change and testing.	Inventory every custom field and workflow before scoping. Retire unused ones instead of rebuilding them.
Number of integrations	Links to monitoring, directory, email, HR or purchasing systems must be rebuilt against GLPI's API or plugins, and each one needs its own test cycle.	List every integration with its owner and data flow. Confirm which ones GLPI covers natively and which need plugins or custom code.
Quality of existing data	Duplicate persons, stale assets and inconsistent categories slow mapping and create rework during import and validation.	Clean duplicates and decommission stale assets in TOPdesk before the export. Agree on a single category list.
Number of sites and business units	Each site, location and business unit adds entity, location and access rules to design and verify, and may need separate approval.	Design the entity and location structure once, with the business owners, before any import.
GLPI infrastructure sizing and hosting	Server, database, PHP and web server tiers must be sized, built, hardened and backed up. Hosting choice (your data center, a cloud account or a GLPI Network subscription) drives both setup and ongoing cost.	Agree the hosting model and sizing inputs in the written scope. Ask for an itemized quote covering each tier and its backups.
Identity integration (LDAP or external authentication)	GLPI tries the internal database, LDAP directories, IMAP and other external methods in order. Linking directory accounts, groups and profiles needs design and testing, and mistakes lock users out.	Decide the authentication order and group-to-profile mapping before go-live. Test with a pilot group first.
Training and change management	Agents, requesters and approvers must learn new screens, workflows and reporting. This is one-time effort, but its quality affects support load after go-live.	Plan role-based training and keep the TOPdesk to GLPI terminology map in the knowledge base.
Team GLPI experience	Teams without GLPI administration experience need more time for configuration, plugin choices, update procedures and troubleshooting, which can extend the project.	Ask whether the provider will train your administrators as part of the scope, and name a internal owner for the platform after go-live.
Recurring operating costs	Hosting, backups, GLPI updates (including reactivating plugins after major versions), security patching and support continue after go-live. Optional GLPI Network subscriptions are priced per user per month, public cloud at 19 euros and private cloud at 21 euros with a 25-user minimum, according to the GLPI Network subscriptions page.	Compare self-hosted running costs with the optional GLPI Network tiers in the same quote. Ask which recurring items are included in any retainer.

Planning around TOPdesk's post-termination backup window

Confirm in writing, with TOPdesk Support and in your contract, how long your data stays available after termination and when the final backup copy is taken. This page does not state that window, and it may differ by contract, hosting region or plan. Ask TOPdesk to name the last date on which you can request a data copy, what the copy contains, and whether attachments are included. Treat the answer as the deadline that governs your whole project, and record who at TOPdesk gave it and when.

Do not wait for the final copy to start the migration. Request a data copy early, then run at least one complete trial import into a GLPI test instance and reconcile the results before your notice periods end. Reconciliation means comparing record counts for incidents, changes, assets and persons, spot-checking linked objects, and confirming that attachments open correctly. Each gap you find in the trial is a gap you can still raise with TOPdesk while the export channel remains open.

Once you receive the final copy, verify it before you rely on it. Record checksums, store the original files in a write-protected archive with the export date and the TOPdesk request reference, and keep a copy outside the production GLPI environment. Also keep the mapping files and import logs, since they explain how each TOPdesk field became a GLPI object. Ask your records or legal team which retention period applies to this archive, because that obligation can outlast the subscription.

What usually goes wrong and how to prevent it

Most failed TOPdesk to GLPI moves are not caused by GLPI itself. They come from timing, incomplete exports, and data that was never reconciled. Each card below names one risk, why it matters for this migration, and the check that catches it before cutover.

Data copy requested too late

TOPdesk's post-termination backup window limits how long you can ask for a data copy after the subscription ends. Requesting the copy only at exit leaves little room to fix mapping errors. Ask TOPdesk Support early for a full backup copy while the subscription is still active, and confirm in writing the format, delivery method and the deadline for the copy. Then run a trial import against that copy in a staging GLPI instance, so mapping problems surface while the source system is still available.

Attachments lost or unlinked

Incidents, changes and assets often carry files that are stored separately from the records they belong to. If the import moves the record but not the file, users see empty references and auditors see gaps in evidence. Before importing, confirm with TOPdesk Support how attachments are packaged and how each one links to its parent record. After import, sample a set of tickets with attachments and open each file from the GLPI side, comparing names, sizes and checksums with the source.

Duplicate persons and assets

Running an import into a GLPI instance that already holds users, computers or inventory from GLPI Agent or LDAP can create second copies of the same person or device. Duplicates split ticket history and distort license and asset counts. Decide which system is the master for persons and assets before the import, match on a stable key such as employee number or serial number, and run a duplicate report in GLPI after each import batch. Clean duplicates before users start working in the new system.

Categories and statuses that do not map

TOPdesk's operator groups, categories, statuses and impact or urgency values rarely match GLPI's ticket types, categories and status set one to one. Forcing them into the closest value silently changes SLA behavior and reporting history. Build a written mapping table for every status, category and priority, have the service owners sign it off, and reconcile counts per status and per category between the source export and GLPI after each import run.

Plugins suspended after a GLPI upgrade

Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates. Custom integrations or reporting plugins that your team adds during the migration can stop working on the first upgrade without an obvious error. Keep a list of every plugin with its version and owner, test each one on a staging copy of the database and files before any production update, and schedule reactivation as a named step in the change record.

Losing the encryption keys

GLPI stores encrypted values using the keys glpi.key and glpicrypt.key in the config directory. A database backup restored without these files leaves encrypted fields, such as stored credentials, unreadable. Back up the config directory with the database and application files on every backup cycle, store the copies separately from the database backups, and test a restore in a clean environment to confirm that encrypted data decrypts. Record who holds the key copies and how they are retrieved.

How the migration changes by organization type and starting point

A single IT service desk with a small asset base usually has the narrowest migration. The main work is mapping incidents, service requests, changes and a manageable set of persons and assets to GLPI's ticket, asset and user objects, and deciding which closed history is worth carrying over. Because the volume is modest, a spreadsheet import may cover most of the data, and the API is needed mainly for attachments or where records must keep links to one another.

Scope: Confirm whether changes and problems are actively used, since GLPI covers both, or whether the desk runs incidents only.
Data work: Decide how much closed history to import and whether attachments are needed for audit or only for reference.
Governance: A small team can often own the migration, but someone must still approve the cutover and the backup retention plan.
Assets: Check whether asset records were entered by hand in TOPdesk or come from an inventory tool, because that decides whether GLPI Agent is worth deploying.
Access: Confirm which agents need login rights and how they will authenticate.

Confirm first: the export path with TOPdesk Support, how far back the data must go, and who signs off on the cutover date.",

A regulated organization that must keep service desk data inside its own environment has a migration driven by data handling as much as by object mapping. The source export, the staging area and the GLPI database all become places where personal data and security records sit, so each one needs access control, encryption and a disposal plan. The export itself depends on TOPdesk Support, so the request should be made in writing with the data scope defined.

Data work: Agree a retention and minimization rule before export, so only the records the organization is entitled to keep are copied.
Hosting: Confirm where the GLPI database, backups and the glpi.key and glpicrypt.key files will live, and who holds them.
Governance: Record each step in a migration log that an auditor can read, and keep the evidence of deletion of staging copies.
Access: Decide how GLPI authenticates users, whether against an internal directory or LDAP, and review admin roles.
Compliance: DeployOpen prepares systems and evidence for assessments, but independent auditors issue any attestation.

Confirm first: the data classification of the TOPdesk records, the approved hosting location and the sign-off chain for the export request.

Questions buyers ask before moving from TOPdesk to GLPI

How much does a TOPdesk to GLPI migration cost?

The total depends on the scope of the data, the hosting you choose and how much of the work your own team carries. GLPI itself has no license fee for the self-hosted edition. The recurring and one-time costs are the servers or virtual machines, the database, backup storage, staff time for upgrades and plugin checks, and the migration work itself. Migration cost is driven by how many incidents, changes, assets and persons you need to map, how much attachment history you keep, how many custom fields TOPdesk uses, and whether you run an import through spreadsheets or the API. DeployOpen does not publish prices. A fixed-scope written proposal lists deliverables, assumptions and fees before work starts, so ask for that document and compare it with your own internal effort estimate.

How long does a TOPdesk to GLPI migration take?

The timeline is set by data volume, mapping complexity and how quickly TOPdesk Support returns your data copy. Requesting a copy from backup is an external dependency, so start that request early. Other drivers are the number of object types you map, the amount of attachment handling, the number of test imports you need before the mapping is accepted, user acceptance testing, and training for agents. A migration with a small, clean dataset and a short list of custom fields moves faster than one with years of history and many workflows. No duration is promised here. Ask for a timeline in the written scope, with milestones tied to data delivery and sign-off.

What does the migration require from our team?

Your team needs to make decisions and provide access. The main contributors are a process owner who approves how incidents, changes, problems and assets map to GLPI objects, a TOPdesk administrator who can request the data copy and explain custom fields, and someone who owns the target platform, including servers, database, web server and the network path to users. Your service desk leads should review sample imports and confirm status and category mapping. Security or compliance staff should approve data handling and retention rules. Expect your team to keep handling live tickets during the project, so agree a freeze or cutover window in advance.

Can an internal IT team migrate from TOPdesk to GLPI without a partner?

A capable internal team can do it, provided it has someone comfortable with Linux web servers, PHP, MariaDB or MySQL, and GLPI's data model. GLPI's documented requirements include PHP 8.2 or later for GLPI 11.0 and PHP 8.3 or later on the main branch, with MariaDB or MySQL and a web server whose document root points to the public directory. The harder parts are interpreting TOPdesk exports, designing the object mapping, handling attachments and validating the result. Teams without that experience often underestimate the mapping and testing effort. A partner can take on a fixed-scope part of the work, such as hardening, the import pipeline or documentation, while your staff keep ownership of the business rules.

What happens to attachments and ticket history during the move?

Attachments and history need explicit handling because TOPdesk's export and GLPI's import paths do not carry them automatically in every case. Confirm with TOPdesk Support exactly what the data copy contains and in which format, then decide which attachments you keep and where they are stored on the GLPI side. Historical timestamps, authors and status changes are often reduced to ticket notes or followups in the target, so the mapping should say what is preserved and what becomes a summary. Keep the original data copy under your retention policy, and record which records were migrated, which were skipped and why. Ask any provider to show a reconciliation report with record counts per object type.

How do we run TOPdesk and GLPI in parallel during the transition?

Run them in parallel only for a defined period, with a clear rule for which system is the record of truth. Most teams keep TOPdesk read-only for reference while agents work in GLPI, and they route new requests to GLPI only after the cutover date. Plan how integrations, email intake and monitoring alerts switch over, because duplicate ticket creation is a common failure. Keep a delta import plan if you need to move records created after the first copy, and confirm TOPdesk's post-termination backup window before you set the end date for TOPdesk access. Document the cutover checklist and the rollback steps.

What ongoing work does GLPI need after go-live?

GLPI needs regular, planned maintenance that TOPdesk's subscription otherwise covers. The official update procedure requires backing up the database, the files and the config directory, including the glpi.key and glpicrypt.key files, then replacing the application files and running php bin/console db:update. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so check each plugin before and after an upgrade. Recurring tasks include:

Testing backups and restores on a schedule
Reviewing PHP, database and web server support against the release requirements
Checking plugin compatibility before each upgrade
Reviewing user sessions, authentication sources and administrative access

Ask any partner whether these tasks are in a retainer, and ask for the upgrade runbook in writing.

How DeployOpen scopes, runs and supports the migration

DeployOpen plans and implements self-hosted GLPI inside your own infrastructure, then maps TOPdesk incidents, changes, assets and persons to GLPI objects with your team. The work is agreed in writing before it starts, so the export, mapping and import steps are visible to your data owners from the first week.

How we scope

Inventory which TOPdesk objects, attachments and history your teams need in GLPI and which can stay in archive.
Agree in writing how the TOPdesk data copy is requested, received and checked before any import starts.
Record the target hosting, PHP and database versions, and the backup and retention rules for the GLPI instance.
Confirm the post-termination backup window with TOPdesk Support and set the cutover date against it.

How we build

Install GLPI on your servers or cloud accounts, with the web server pointed at its public directory and URL rewriting in place.
Write the field mapping for incidents, changes, assets and persons, and test it on a sample export before the full load.
Run imports through spreadsheet import or the API, and reconcile record counts and attachments after each run.
Configure authentication against your directory and set up GLPI Agent where hardware and software inventory is needed.

How we hand over

Deliver the mapping document, import logs and reconciliation results so your data owners can sign off each object type.
Document the update procedure, including backups of the database, files and the glpi.key and glpicrypt.key files.
Train administrators on GLPI configuration, roles and plugin handling so the team can operate the instance alone.
Hand over the runbook, access records and the list of open decisions for your own change board to track.

How we support

Fixed-scope engagements end at agreed deliverables, with any further work quoted from a new written scope.
Ongoing support, upgrades and continuous testing are available as a retainer after the cutover period.
Confirm with your team which GLPI release line you will run before planning upgrades, since release dates change.
Ask any implementation partner for a written support scope that covers upgrades, backups and incident response.

Migrate from TOPdesk to GLPI