Migrating from ServiceDesk Plus to GLPI: what the move involves
Moving from ManageEngine ServiceDesk Plus to GLPI is a data export, import and rebuild project, and it runs inside your own infrastructure. You take requests, assets and users out of ServiceDesk Plus, map them into GLPI, and then recreate the operating rules (categories, SLAs, workflows and notifications) by configuration rather than by copying code. This is the reason most renewal-driven moves are scoped as a fixed project with a written plan, not as a software upgrade. GLPI is distributed under GPL-3.0 with no license fee, so the cost you are replacing is the per-technician subscription and the people and servers that carry the new platform.
The work is usually shared across four roles. The IT service owner decides which categories, SLAs and approval paths survive the move. The asset manager owns the mapping of hardware, software and contract records, and decides which GLPI Agent inventories replace ManageEngine scans. A DBA or sysadmin prepares the GLPI host, the database (MariaDB or MySQL, as listed in the GLPI prerequisites) and the backup routine, which must cover the glpi.key and glpicrypt.key files named in the update documentation. An implementation partner, if you use one, plans the scope, runs the imports and tests the cutover. Confirm with the GLPI prerequisites and your own environment which PHP and database versions apply to the release you choose.
Effort depends mostly on how much history you keep, how many custom fields and workflows you have, and how clean your asset data is. Those are the drivers to measure first, using the query reports you can export from ServiceDesk Plus. Ask any partner for a written scope, deliverables and timeline before work starts, and ask which parts they will test with your own data. Risk is highest in the cutover window, when open tickets and new asset records must not be lost or duplicated, so plan a rollback path and agree on a parallel run before you turn ManageEngine off.
Which ServiceDesk Plus capabilities map to GLPI, and which need rework
This table compares common ServiceDesk Plus capabilities with what GLPI's published scope covers, and marks each as clean, needs rework or gap. Use it to scope the migration: clean rows move with data, rework rows need configuration or rebuilding, and gap rows need a decision before cutover. Confirm each row against your ServiceDesk Plus edition and your GLPI version before you commit.
| Capability | GLPI coverage | Status | Migration effort |
|---|---|---|---|
| Incident management | ITIL incident management is in GLPI's stated scope, so tickets and their history can be carried over as data | Clean | Export tickets to CSV, map status and priority values, and import with GLPI's spreadsheet import |
| Problem management | ITIL problem management is in GLPI's stated scope | Needs rework | Re-link problems to incidents and confirm how the relationship fields import |
| Change management | ITIL change management is in GLPI's stated scope | Needs rework | Re-create change approval steps and templates, since approval logic rarely exports as data |
| Service request catalog | Ticket types and forms exist, but ServiceDesk Plus request templates and custom forms usually need rebuilding in GLPI | Needs rework | Plan a rebuild of each request form and confirm field-level fit before cutover |
| Asset inventory | Asset inventory is in GLPI's stated scope, and asset records can be imported from CSV | Clean | Export asset query reports and map asset types, states and locations to GLPI equivalents |
| CMDB and configuration items | Configuration management is in GLPI's stated scope, but relationship depth may differ from ServiceDesk Plus | Needs rework | Confirm which CI types and relationships your reports use and rebuild the rest by hand |
| Contracts and licenses | Contract management is in GLPI's stated scope | Clean | Export contract records and link them to assets and suppliers after import |
| Knowledge base | A knowledge base is in GLPI's stated scope, and GLPI 12.0.0 rewrote it | Needs rework | Articles usually need export and reformatting, so confirm attachment and formatting handling |
| SLAs and escalations | SLA management is in GLPI's stated scope, but targets and escalation rules must be re-created | Needs rework | Document each SLA target and escalation rule, then rebuild and test them in GLPI |
| Workflows and automation | Exact ServiceDesk Plus workflow logic usually does not transfer, so GLPI rules must be designed anew | Gap | Treat each workflow as a new design item and confirm which triggers and actions GLPI supports |
| Users and groups | Users and groups import through spreadsheets, and GLPI supports LDAP and other external authentication | Clean | Export users from query reports, then connect directory authentication to avoid manual accounts |
| Asset discovery | GLPI Agent collects hardware and software inventory and performs network discovery and inventory | Needs rework | Deploy agents to each endpoint class and compare results with ServiceDesk Plus discovery before retiring it |
Which exports carry requests, assets and users out of ServiceDesk Plus
Leaving ServiceDesk Plus means pulling data out through the export paths the product offers, then accepting that some configuration will not travel. The cards below separate what each path carries from what must be rebuilt by hand in GLPI, so the migration scope is agreed before any data moves.
Query reports exported to CSV
Query reports are the most direct route for requests, assets and technician or requester records. Each report carries the fields you select, so build one report per object type and confirm that status, category, asset tag, owner and timestamps are included. Check the row counts against the source system before you import, because a report that silently truncates large result sets will look complete. Ask ManageEngine to confirm the export limits for your edition and version.
Custom tabular reports
Custom tabular reports let you shape columns that a standard query report may not expose, such as custom fields, linked assets or resolution notes. They are useful when GLPI needs a flattened structure for its spreadsheet import. Record which custom fields map to GLPI dropdowns or additional fields, because those mappings are not carried by the report itself. Test one object type end to end before you scale the approach.
Database access on on-premises installs
On-premises installations may allow read access to the underlying database, which gives the most complete view of records, relationships and history. Treat this as a high-sensitivity extract: it contains credentials, personal data and audit information. Agree who performs the extraction, where the copy is stored and how it is destroyed after the cutover. Confirm the schema with ManageEngine support, since table layouts change between releases.
Attachments and history left behind
Query reports and tabular exports generally return record fields, not the binary attachments stored with requests or assets. Plan a separate extraction for files such as screenshots, purchase invoices and signed approvals, and decide whether GLPI will hold them or whether they stay in an archive with a link from the ticket. Confirm with your own export tests whether comments and activity history come through, and record any gap in the migration scope.
Workflows, SLAs and notification rules
Workflow definitions, SLA rules, escalation timers, notification templates and automation are configuration rather than data, so reports will not return them. Export the configuration screens or document them from the admin console before you start. In GLPI, these are rebuilt as categories, SLAs, OLAs, business rules and notification settings. Treat this rebuild as the largest share of design effort, and budget review time with the people who own the approvals.
LDAP, email and monitoring connections
Directory sync, mailbox-to-ticket integration and monitoring alerts point at ServiceDesk Plus and do not move with the data. In GLPI, authentication order runs from the internal database to LDAP, then IMAP and other external methods, so the directory connection must be configured and tested before users can sign in. Rebuild the mailbox collector and each monitoring integration as a named connector with its own service account. Inventory every inbound and outbound integration first, because missing one usually surfaces after cutover.
The migration sequence from inventory to decommission
This sequence moves ServiceDesk Plus data and processes into GLPI in controlled stages, so each step produces a checked artifact before the next one starts. It ends with a documented decommission that keeps an archive of the old records for as long as your retention rules require.
Inventory request types, assets, users, SLAs and integrations
The ITSM lead and a service desk supervisor list every request type, category, template, workflow, SLA, asset class, user group and integration that ServiceDesk Plus uses today, and record how each is used and how often. Engineers confirm which integrations (directory sync, monitoring feeds, email intake, scan jobs) must be rebuilt in GLPI and which can be retired. The output is a field mapping sheet that pairs each ServiceDesk Plus field with its GLPI counterpart, marks gaps, and names an owner for every gap. The step is complete when the business owners have signed off the mapping.
Export source data through query reports
Administrators run the query reports for requests, assets and users in ServiceDesk Plus and export them to CSV, confirming with the vendor or your administrator which fields and attachments each export includes. On on-premises installs, the database team confirms whether direct reads are permitted and documents any extraction queries they use. Each export file is checksummed and stored in a restricted location. The output is a set of versioned export files with a record of row counts per object type.
Run a pilot import into a non-production GLPI
Engineers build a non-production GLPI instance on the target platform, following the installation prerequisites for the chosen PHP and database versions, and load a representative subset of the exports with GLPI's spreadsheet import. They compare imported counts, user links, asset relationships and category assignments against the source files and log every rejected row with its cause. Fixes go back into the mapping sheet and the import is repeated until results match. The output is a reconciled pilot report that the service desk lead accepts in writing.
Operate a parallel run
For a defined period agreed by the project sponsor, new requests are logged in both ServiceDesk Plus and GLPI, and GLPI Agent inventory runs against a pilot group of devices so its results can be compared with the ManageEngine scans. Technicians record any differences in routing, SLA timers or notifications, and the team fixes the GLPI workflows and notification rules that caused them. The output is a parallel run log with a list of open discrepancies and their resolution status. The step closes when no high-impact discrepancies remain open.
Cut over with a freeze window
The team announces a freeze window in which no new requests are created in ServiceDesk Plus, performs a final export and delta import, and then switches intake (email, portal links, integration endpoints) to GLPI. The cutover checklist covers the final reconciliation, DNS or mail routing changes, agent deployment to every in-scope device, user access tests and a rollback decision point with named owners. The output is a signed cutover checklist and a confirmed reconciliation of final record counts. Confirm the freeze length and rollback criteria with your change advisory board before scheduling.
Decommission and archive ServiceDesk Plus data
Once the cutover is stable, the team stops ServiceDesk Plus scheduled jobs, revokes its integrations and service accounts, and removes its scan schedules. Before shutdown, they create a read-only archive of the database and exported files, with checksums and an index of record types, and store it under the retention schedule set by your records, legal and security teams. Access to the archive is restricted and tested. The output is a decommission record and an archive inventory that auditors and compliance staff can review.
How the CSV import into GLPI works in practice
The import runs in dependency order, and that order matters more than the file format. Load reference data first: entities, locations, categories and user accounts. Tickets, computers and other assets refer to these records by name, so a ticket row that points to a category or requester that does not yet exist will fail or land in the wrong place. For each exported CSV from ServiceDesk Plus, map the columns to the matching GLPI itemtype using the spreadsheet import in your GLPI version. Confirm in that version which itemtypes the import supports, which field GLPI uses to match an existing record so you avoid duplicates (for example, name or serial number), and whether it can create missing reference values. Then run a small pilot file through every itemtype. Check accented characters, line breaks inside description fields and date formats, because encoding problems often appear only in names that contain non-ASCII characters.
Before any import, stand up GLPI on a supported stack. The GLPI installation prerequisites require the web server's document root to point to GLPI's public directory rather than the installation root, with URL rewriting that routes requests through index.php. The supported servers are Apache, Nginx, lighttpd or IIS. The GLPI README on the main branch lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, which matches the 12.0.0 line. The 11.0 installation docs list PHP 8.2 or later with MySQL 8.0 or MariaDB 10.6. Only MySQL and MariaDB are supported, so confirm your database engine and versions before you build the server. Confirm the exact import options, field mappings and matching behavior in the version you deploy, and test them there, since they can change between releases.
Replacing ManageEngine asset scans with GLPI Agent
GLPI Agent runs on Windows and sends hardware and software inventory to GLPI, which is the core of what most ServiceDesk Plus deployments use scans for. Before you switch off a ManageEngine scan for Windows machines, list the fields your team reads today: installed software, processor and memory, disk, serial number, logged-in user and assigned owner. Map each one to the GLPI asset type and field it will populate, and note any custom fields that were built in ServiceDesk Plus.
- Deployment method: Decide whether the agent is pushed through your existing software distribution tool, a group policy, or a script. Agent installs are usually a recurring operational task, not a one-time one.
- Inventory scope: Compare software lists for a sample of machines from each department. Differences often come from how each tool normalizes product names.
- Ownership data: Ownership and location usually live in GLPI, not in the agent output, so plan how users and departments will be linked.
- Scheduling: Set the inventory frequency so it matches your change windows and does not overload laptops on battery.
- Credentials: Confirm the account the agent uses for local and domain data, and document it for your security team.
Confirm with your ManageEngine administrator which Windows scan jobs and custom fields are active today, and whether any of them feed approvals or license reports.
GLPI Agent also runs on macOS, so Apple devices can report into GLPI on the same model as Windows machines. The practical differences are in how the agent is deployed and what it can read without extra permissions. Mac fleets are often managed through a separate mobile device or endpoint management product, which may already hold hardware and software records that you need to reconcile with the agent data.
- Permissions: macOS privacy controls can restrict what a background process reads. Test the agent on a sample of managed Macs before rolling it out widely.
- Management overlap: If an MDM platform already reports inventory, decide which source is authoritative for each field so the two do not conflict in GLPI.
- Software naming: Application bundle names differ from Windows package names, so expect duplicate or renamed entries during the parallel period.
- Laptop coverage: Machines that are off the network for long periods need a check-in schedule that suits remote staff.
- Ownership and lifecycle: Map purchase and warranty data from your procurement records to the GLPI asset entries.
Confirm with your endpoint team which macOS inventory sources exist today and which fields your ServiceDesk Plus reports depend on.
GLPI Agent runs on Linux as well, and it is often the most flexible option for servers and developer workstations. Inventory on Linux typically covers packages, kernel and distribution details, hardware and network interfaces. Because many Linux hosts are managed by configuration tools or image pipelines, the agent often sits alongside those systems rather than replacing them.
- Package sources: Confirm which package managers your estate uses, since software inventory depends on what the agent can query.
- Server roles: Tag production, test and development hosts in GLPI so reports and change records can filter by environment.
- Image and build pipelines: Install the agent in golden images or provisioning templates so new hosts register automatically.
- Container and cloud hosts: Decide whether ephemeral instances should be inventoried at all, or tracked through cloud or orchestration records instead.
- Service accounts: Review what privileges the agent needs and document them for your security review.
Confirm with your platform team which Linux hosts ServiceDesk Plus scans today and whether any of them are excluded because they are managed elsewhere.
Beyond endpoints, GLPI Agent performs network discovery and inventory and remote ESX inventory, and it can deploy packages. These functions are the ones most likely to differ from ManageEngine scan configuration, because discovery depends on which subnets, credentials and protocols you have set up. Treat each network range as a separate item to validate rather than assuming that discovery results match a previous scan report.
- Discovery ranges: List the subnets that ManageEngine scans today and confirm the same ranges are assigned to GLPI Agent.
- Credentials: Network devices and ESX hosts need credentials for remote inventory. Store them according to your secrets policy and rotate them on your normal schedule.
- Remote ESX inventory: Confirm which ESX hosts and clusters the agent should query and whether the inventory fields match what your team reads today.
- Package deployment: If you use ManageEngine to push software, do not switch that role off until a replacement deployment path has been tested.
- Scan frequency and load: Set discovery windows so they do not compete with backups or maintenance jobs.
Confirm with your network and virtualization teams which discovery ranges, ESX inventories and deployment jobs your ServiceDesk Plus instance runs today.
Running ManageEngine scans and GLPI Agent side by side for a period lets you compare results before you retire the old scans. During that time, both tools report on the same devices, so you need a clear rule for which record is authoritative for each field and how duplicates are merged. Without that rule, asset counts and software lists will drift, and reports used for licensing or audit evidence will disagree.
- Reconciliation key: Choose a stable identifier, such as serial number or asset tag, to match devices across both tools.
- Field ownership: Decide which system is the source of truth for each field and document it.
- Duplicate handling: Define how to merge or retire duplicate device records and who approves the change.
- Discrepancy log: Record each mismatch, its cause and the decision taken, so the audit trail is preserved.
- Exit criteria: Agree in writing what match level is needed before a ManageEngine scan is switched off.
Confirm with your asset owner which scan types and reports your licensing, audit and service desk processes rely on before you start the parallel period.
What drives the cost and duration of the move
This table lists the main factors that change the effort and cost of moving from ServiceDesk Plus to GLPI, with who pays for each and whether it is one-time or recurring. Use it to build a scope and to check that each quote covers the same drivers. The main takeaway is that data quality and request complexity usually matter more than the number of users.
| Driver | Why it changes cost or effort | Who is paid, one-time or recurring, and what to ask for |
|---|---|---|
| Request types, categories and custom fields | Each ServiceDesk Plus request template, category and custom field must be mapped to a GLPI ticket category, form or field, and some will need rebuilding rather than importing. | Internal staff define the mapping; a partner may build it. One-time. Ask for a field-by-field mapping document as a quote deliverable. |
| Depth of SLA and approval workflows | SLAs, escalation rules and approval chains are rebuilt in GLPI configuration, so complex rules take longer to design, test and sign off. | Partner or internal ITSM lead. One-time for build, with occasional recurring tuning. Ask which rules are in scope and how testing is counted. |
| Number of assets and endpoints for agent deployment | GLPI Agent must be deployed and verified on each endpoint, and network discovery scope must be set for servers and network devices. | Internal desktop team or partner, plus any software distribution tooling. One-time rollout, then recurring agent updates. Ask for the deployment method and verification approach. |
| Data quality in ServiceDesk Plus | Duplicate assets, stale users, inconsistent asset states and free-text fields need cleaning before CSV export and import, and errors discovered late cause re-imports. | Internal data owners do most of the cleanup. One-time. Ask whether the partner runs a pre-migration data audit and how exceptions are logged. |
| Integrations: LDAP, email and monitoring | Each directory, mail and monitoring connection must be reconfigured or rebuilt in GLPI, and GLPI authenticates against the database, LDAP and IMAP in order, so directory design affects the work. | Partner or identity team. One-time build, then recurring ownership of connectors. Ask for a list of integrations with the configured method for each. |
| Parallel run and cutover window | Running both systems for a period means dual data entry risk, reconciliation of tickets opened in each, and a planned freeze on changes during export. | Internal service desk and project management carry most of the effort. One-time. Ask how the partner defines reconciliation checks and rollback. |
| Hosting choices | A self-hosted GLPI needs a web server, PHP, a MySQL or MariaDB database, backups and patching, while the GLPI Network hosted option moves that work to Teclib' under a subscription. | Your infrastructure team or hosting provider for self-hosting (recurring operations). For the hosted option, the GLPI Network subscriptions page lists public cloud at 19 euros and private cloud at 21 euros per user per month, with a 25-user minimum for private cloud. Ask for the hosting model in writing. |
| Training volume | Technicians, requesters and administrators each need different training on GLPI ticket handling, asset screens and administration, and the number of people drives session count. | Internal trainers or partner. One-time for the initial round, then recurring for new starters. Ask for the training audience list and materials ownership. |
What usually goes wrong in a ServiceDesk Plus to GLPI move
Most failed moves from ServiceDesk Plus to GLPI come from data that never left the source, configuration that was rebuilt by guesswork, and operational habits that were not carried over. The cards below cover the six risks that appear most often in this kind of cutover and the check that prevents each one.
Lost history and attachments
Query report CSV exports carry the structured fields of requests, but attachments, long descriptions and some thread history often stay behind in ServiceDesk Plus. Before cutover, confirm which request fields and file attachments your reports actually return, and decide where archived attachments will live. Run a sample of closed tickets with long notes through the import and compare them field by field with the source before any bulk load.
Workflows and SLAs rebuilt incorrectly
Escalation rules, approval steps and SLA clocks in ServiceDesk Plus do not transfer as data, so they must be re-created in GLPI's rules and SLA configuration. Write down each business rule with its trigger, owner and target time, then build it in a test entity. Ask the service desk lead to walk through five real scenarios with the rebuilt rules before any ticket moves into production.
Duplicate or stale asset records
When GLPI Agent starts reporting from endpoints while ServiceDesk Plus scans still run, the same machine can appear twice, or an old record can stay active after a device is replaced. Agree on a single source of truth for each asset class, switch off the ManageEngine discovery schedule on a dated day, and reconcile serial numbers and hostnames between the two inventories. Check the duplicate list in GLPI after the first full inventory cycle.
Users mapped to the wrong authentication source
GLPI tries its internal database, then LDAP, then IMAP, then REMOTE_USER, in that order. A user who exists in the directory but was imported locally first can log in with a stale local account, or be unable to sign in at all. Map each user group to its intended source before migration, confirm that directory accounts match the imported usernames, and test one login for each role, including requesters, technicians and administrators.
Plugins suspended after updates
Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates. A team that installs a plugin for SLAs or inventory and then patches GLPI can find those features silently off. Record the active plugin list and versions in your runbook, schedule a reactivation check after every update, and test the plugin-dependent workflows on a staging copy first.
Missing encryption key backups
GLPI uses the keys glpi.key and glpicrypt.key to protect stored secrets. A database backup restored without these files leaves encrypted fields, such as credentials for LDAP or mail, unreadable. The update procedure requires backing up the config directory, so include it in every backup job and store a copy of the keys separately from the database. Test a restore on a separate server and confirm that the keys decrypt existing configuration.
How the move differs by starting point
If your ServiceDesk Plus runs on your own servers and your team can read its database, the export is usually a database extraction rather than a set of CSV files. A direct extraction can carry relationships between requests, assets, users and technicians more completely than report exports, which makes reconciliation simpler. The work shifts toward mapping the ServiceDesk Plus schema to GLPI's data model and validating the results on a copy of the data.
- Schema mapping: Your team or implementation partner maps tables for requests, assets, users and groups to GLPI objects, and records every field that has no equivalent.
- Read-only access: Extract from a copy or a read-only replica so the live service desk keeps running during the work.
- Relationship checks: Confirm that requests still point to the right requesters, assets and groups after import.
- Attachments and history: Decide early whether attachments and ticket history are moved, summarized or archived in a read-only location.
- Vendor confirmation: Ask ManageEngine which tables and fields are supported for extraction in your installed version before you rely on them.
Confirm your database version and licensing terms for direct access with the vendor and your own change board before you start.
If you use the cloud edition, you usually have no database access, so your data leaves through query reports exported to CSV and any export features the vendor makes available to you. This path is workable but more manual. Each report must be defined, run and checked, and fields that the report tool does not expose will need to be rebuilt from other sources or accepted as lost.
- Report inventory: List every report you need for requests, assets, users and approvals, then test each export on a small date range.
- Field gaps: Expect that some attachments, long descriptions or audit details will not appear in standard reports, and plan how to handle them.
- Import limits: Check how GLPI's spreadsheet import handles your largest CSV files and split them if needed.
- Asset data source: Cloud customers often rely on the vendor's agents, so the inventory will need a fresh GLPI Agent rollout rather than a copy.
- Contract questions: Ask the vendor what export options your subscription includes and whether any tier limits them.
Check which reports your edition can run and export before you commit to a timeline, because the report list drives the entire data scope.
A small team with a modest request history can often move in a single pass. The data volume is low enough that an import can be checked by hand, and many open requests can simply be closed in ServiceDesk Plus and recreated in GLPI. The main effort is not the data but the configuration, because a small team still needs working categories, roles and a clear way to submit and track tickets from day one.
- Open versus closed: Migrate open and recently closed requests, and keep older history in a read-only export for reference.
- Simple configuration: Rebuild a short list of categories and roles rather than every legacy template.
- Hand checks: Review a sample of imported requests against the originals to confirm titles, requesters and status.
- Asset scope: Install GLPI Agent on the devices your team actually manages, starting with servers and laptops.
- Short cutover: A brief freeze window with a clear rollback plan is often enough, since the old system can be kept read-only for a while.
Confirm with the team which open requests must move and who signs off on the cutover date before you start the import.
A large estate with many assets, multi-level approvals and linked change records changes the nature of the project. Workflows, SLAs and approval chains usually need to be rebuilt deliberately in GLPI, and the asset inventory must be reconciled against what the ServiceDesk Plus discovery already knows. Expect separate tracks for data, configuration, agent rollout and testing, with formal sign-off at each stage.
- Workflow rebuild: Document each approval path, routing rule and SLA from ServiceDesk Plus, then rebuild and test them in GLPI, which covers ITIL incident, problem, change and service level management.
- Agent rollout: Plan GLPI Agent deployment in waves by site and device type, and reconcile the results against your existing inventory.
- Parallel running: Consider running both systems for a period, with clear ownership of which system is authoritative for each request type.
- Formal cutover: Agree written go and rollback criteria, a freeze window and named owners for each system.
- Evidence: Keep migration logs, reconciliation reports and approval records, since auditors may ask for them.
Confirm your scope, deliverables and timeline in writing with any implementation partner before work begins, because the workflow inventory determines most of the effort.
Questions buyers ask before moving from ServiceDesk Plus to GLPI
How much effort and cost does moving from ServiceDesk Plus to GLPI involve?
The move has two cost groups: one-time work and recurring running costs. One-time work covers exporting data, mapping fields, rebuilding categories, SLAs and workflows, replacing asset scans with GLPI Agent, testing and cutover. Recurring costs cover servers, database and web tier operations, backups, GLPI upgrades and any support contract. GLPI itself carries no license fee under GPL-3.0. The biggest drivers are the number of asset records, how many custom workflows and approval rules you run in ServiceDesk Plus, the depth of your integrations, and how much history you must carry over. Ask any provider for a fixed-scope quote that lists each of these items separately, with the hosting and operations costs shown on their own line.
How long does a ServiceDesk Plus to GLPI migration take?
The timeline depends on what you are moving and how much of your configuration must be rebuilt by hand. The main variables are the volume of requests and assets to export, the number of categories, SLAs, templates and workflows to recreate, the number of asset discovery sources to reconfigure with GLPI Agent, and how many parallel test cycles your change process requires. A parallel run before cutover adds time but lowers risk. Confirm the schedule with the people who will do the work, and agree on the cutover window and the rollback plan in writing before any data is loaded.
What does the internal team need to provide during the migration?
Your team needs to own the decisions that a migration cannot make for you. That includes naming a business owner for the service catalog, confirming which categories, priorities and SLA targets still apply, approving the data you will keep and the data you will archive, and providing test users for each role. Your team also needs administrator access to ServiceDesk Plus for exports, access to the directory service for user accounts, and an environment to host GLPI with the PHP and database versions the GLPI installation docs require. Agree on these responsibilities before the project starts so that the schedule does not depend on decisions made during testing.
Can we migrate from ServiceDesk Plus to GLPI without an outside partner?
Yes, a capable internal team can do it, provided they have experience with GLPI administration, database work and the directory and agent deployment your estate uses. The work that most often slows internal teams down is re-creating workflows and SLAs, validating exported data, and running parallel tests while still supporting live tickets. An outside partner can take on specific parts of the work, such as the export and import scripts, the configuration rebuild or the operational handover, under a written scope. DeployOpen implements, customizes, hardens, backs up, upgrades and documents self-hosted platforms in your own infrastructure, and most engagements are fixed-scope. Compare internal effort with a written scope before choosing a path.
Does GLPI cover SLAs and workflows the way ServiceDesk Plus does?
GLPI covers ITIL incident, problem, change and service level management, so the core concepts map across. It includes SLA and OLA management, and GLPI 12.0.0 added group-managed OLAs. However, the exact rules, escalation steps, approval chains and automation in ServiceDesk Plus usually do not transfer automatically, so they must be rebuilt and tested in GLPI. Make a list of every SLA, escalation, business rule and approval your team relies on, then check each one against GLPI's ticket and rules configuration. Anything that cannot be matched should be recorded as a gap with an agreed workaround, not discovered after cutover.
Does GLPI Network hosting change the cost picture?
It can. According to the GLPI Network subscriptions page, GLPI Network public cloud costs 19 euros per user per month and private cloud costs 21 euros per user per month, with a 25-user minimum. Self-hosted subscriptions for GLPI Network start at 100 euros per month for the Basic tier, which covers up to 10 agents and 500 assets. Those figures are list prices from that page and may change, so confirm them directly. If you run GLPI yourself, you avoid the per-user subscription but take on hosting, patching, backups and upgrades. Compare the subscription against the internal staff time and infrastructure you would otherwise spend, using the same user count and asset count for both options.
What happens to historical tickets and assets after cutover?
Historical data is usually carried over in one of three ways: fully imported with its original dates and ownership, imported as read-only archive records, or kept in an archive of exported CSV files for reference. Open tickets and active assets normally move into GLPI, while closed tickets older than your retention rule can be archived. Test the import first, check that dates, requesters, assignees and asset relationships match the source, and keep the exported files as a snapshot. Confirm the retention period with your compliance owner before deciding which records move.
What to keep from ServiceDesk Plus before you switch off
Decide what happens to the ServiceDesk Plus data you will not carry into GLPI before the cutover date, not after. The archive decision is an organizational one: keep exports, saved reports and a read-only copy of request history for audit and reference, or accept that history is gone once the instance is shut down. Confirm the retention period for ticket history, approvals, asset records and user activity with your own records policy and with whoever owns compliance or legal hold for IT records. Those owners, not the migration team, should sign off on what must be retained and for how long.
Record the result in a migration register so that every object type has one of three outcomes: migrated to GLPI, archived, or discarded with approval. For requests, that means noting which fields were imported (requester, technician, category, status, dates) and which were not, since comments, attachments and free-text descriptions often need separate handling in a CSV export. For assets, note whether the record was re-created through GLPI Agent inventory or kept only as an archive. The register is the document an auditor or a future administrator will ask for, so store it alongside the archived exports in a location with its own access control.
Confirm two practical points early. First, check whether the ServiceDesk Plus database or the exported files will still be readable after decommissioning, including the reporting tool you used to produce them. Second, decide who can request access to the archive after cutover, how long the instance stays available in read-only mode, and when it is finally removed. These are decisions to confirm with your IT leadership, security team and records owner before any shutdown is scheduled.
How DeployOpen scopes and runs the GLPI migration
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. The cards below describe how a ServiceDesk Plus to GLPI move is scoped in writing, priced from that scope and kept running after cutover.
Fixed scope in writing
Most engagements are fixed-scope, so the migration starts with a written statement of which data classes move (requests, assets, users, categories, SLAs and workflows), which are rebuilt by hand, and which are retired. Deliverables and timelines are agreed before work starts. Check that the scope names the ServiceDesk Plus edition and version you run, because export options and the number of data sets you must reconcile depend on them.
Quote follows from scope
DeployOpen does not publish a price list. A quote follows from the written scope, so the size of the data set, the number of workflows and SLAs to rebuild, the number of agents to deploy and the integrations with directory or monitoring tools all shape the figure. Ask for the quote to split one-time migration work from recurring hosting, GLPI maintenance and any GLPI Network subscription you choose.
Infrastructure and hardening
DeployOpen builds the GLPI stack inside your cloud account, data center or air-gapped network, including the web server document root, PHP and MariaDB or MySQL versions and the database backup routine. Hardening covers account access and the configuration keys that must be preserved, such as glpi.key and glpicrypt.key. Confirm which hosting model your security team accepts before the scope is written.
Data mapping and reconciliation
Each exported CSV from ServiceDesk Plus is mapped to GLPI's spreadsheet import, with user identities matched to the directory your organization uses. Reconciliation counts records before and after import and samples closed requests and asset tags for accuracy. Agree in the scope who signs off on the reconciliation report, because that sign-off decides when the old system can be made read-only.
Cutover, documentation and handover
The cutover plan covers the freeze window for new requests, the final export, the GLPI Agent rollout to endpoints and the rollback path if reconciliation fails. Documentation records the configuration, runbooks for updates (including reactivating plugins after major upgrades) and the operating procedure for the team that inherits GLPI. Handover is a named deliverable in the written scope.
Retainers after go-live
Ongoing support, upgrades and continuous testing run under a retainer agreed separately from the migration. Decide early whether your team will own routine GLPI updates or whether a retainer covers them, since each new GLPI release changes the update path. Ask for the retainer scope in writing so that upgrades, backups checks and support hours are defined before the old ServiceDesk Plus licenses lapse.
