Migrate from ServiceNow to GLPI

Migrate from ServiceNow to GLPI: what the move involves and who does it

The migration is a mapping and rebuild project. Incident, problem, change and configuration item records, along with asset and CMDB data, move out of ServiceNow through exports and into GLPI. Workflows, service catalog items, approval paths, notifications and integrations do not move with the data and have to be rebuilt in GLPI's own model. Teams that come to this decision because of a renewal, a hosting or data residency requirement, or lock-in usually have a clear reason to leave, but the effort sits in the rebuild, not in the data copy. Start by inventorying what ServiceNow actually does for you today, since many of those behaviors were configured over years and are rarely written down. Internal platform or IT teams usually run the work, often with an implementation partner for the parts they have not done before. The internal team owns the business rules, the service catalog and the decisions about which legacy history is worth keeping. The partner or internal engineers typically handle the GLPI installation, data mapping scripts, import testing and integrations. Ask any partner for a written, fixed scope that lists the record types, the integrations and the custom workflows in play, and confirm who signs off on data quality before cutover.

GLPI is GPL-3.0 software maintained by Teclib', and it runs in your own infrastructure, so the data, the database and the backups stay under your control. That also means you own the operations: the web server, the PHP and database tiers, updates, backups and security patching. Confirm the supported PHP and MariaDB or MySQL versions for the GLPI release you choose against the installation documentation, and check which plugins your current process depends on, because plugins need to be reviewed and reactivated after major updates. Confirm the export limits of your ServiceNow edition and whether attachments need a separate extraction step. The main risks are incomplete history, mismatched CI relationships and users who lose access to workflows they relied on. Plan a parallel run, a reconciliation of record counts and a rollback path before the cutover date, and keep the ServiceNow instance read-accessible for a defined period. Effort depends mostly on how heavily the estate is customized and how clean the CMDB data is, so ask for an assessment of both before agreeing on a timeline.

Which ServiceNow capabilities map to GLPI, and which need rework

This table maps ServiceNow ITSM capabilities to their closest GLPI equivalents and marks each as clean, needs rework or gap. Read the status column first, then check the notes for what to confirm against GLPI's current documentation before you commit to a design. Most ITIL record types move across with reshaping, while workflows, catalog items and approvals usually need rebuilding.

Capability	GLPI equivalent	Status and what to confirm
Incidents	Incident management (ITIL)	Clean for core fields, categories and assignment. Confirm how your priority matrix, SLA clocks and escalation rules map to GLPI's ticket model.
Problems	Problem management (ITIL)	Needs rework. Relationships between problems, incidents and known errors must be re-linked after import. Confirm how GLPI links them in your version.
Changes	Change management (ITIL)	Needs rework. Change types, risk fields and CAB approval steps differ from ServiceNow. Rebuild the approval path and confirm the available change states.
Service levels (SLA and OLA)	Service level management (SLM), OLAs	Needs rework. Confirm SLA definitions, calendars and breach actions in GLPI's documentation, including group-managed OLAs in the 12.0.0 release notes.
Knowledge	Knowledge base	Needs rework. The 12.0.0 release notes describe a rewritten knowledge base. Confirm how articles, categories and visibility rules import from your ServiceNow knowledge tables.
Contracts	Contract management	Clean for basic contract records. Confirm how supplier, cost and renewal fields map from ServiceNow contract tables.
Asset inventory (hardware and software)	Asset inventory fed by GLPI Agent	Needs rework. Records migrate from exports, but ongoing collection moves to GLPI Agent. Confirm agent coverage for your operating systems.
CMDB configuration items	Configuration management with custom asset types	Gap for ServiceNow CI classes and relationship depth. Model the CI classes you need and confirm how relationships are represented before loading data.
Workflows and flows	Ticket templates, business rules and plugins	Gap. ServiceNow flow designer logic has no direct import. Rebuild each workflow by hand and confirm which automations GLPI supports natively.
Service catalog and approvals	Service catalog through forms and plugins	Gap for catalog items with approval chains. Rebuild each item and confirm how approvals are configured in your GLPI version.

Which ServiceNow data to extract, and how to confirm the export path

Migration starts with an inventory of what ServiceNow holds and which routes can pull it out. Each data family below needs its own export path, and the route available depends on your release, plan and configuration, so confirm each one with your ServiceNow administrator before planning the GLPI import.

Tickets and their history

Incidents, problems, changes and requests carry the state history, work notes, assignment changes and approvals that auditors and managers ask about later. Export the record fields and the journal or activity entries as separate sets, because a standard list export often captures the current values and not the sequence. Ask your administrator whether work notes and comments come out in the same export, and map each ticket type to a GLPI ticket, problem or change before extraction starts.

Assets and configuration items

Hardware, software and CI records hold the inventory that GLPI will store as assets and configuration items. Confirm which CI classes are in use, because each class has its own table and fields, and a single list export will not capture inherited attributes unless the view includes them. Note every custom field, since these need a matching GLPI field or a documented decision to drop them.

Relationships between CIs

Dependencies between services, applications, servers and databases live in relationship records, not in the CI rows themselves. Losing them turns an impact map into a flat inventory. Ask whether relationships can be exported as their own set with parent and child identifiers, and plan how those identifiers will be matched to GLPI items during import.

Users, groups and approval chains

Users, groups, roles and group membership determine who can see and act on each ticket in GLPI. Export them separately from tickets, and confirm which fields hold department, location and manager data. Passwords and session data are not part of a safe export, so GLPI accounts will be created through its own authentication sources.

Attachments and knowledge articles

Attachments and knowledge articles are often stored outside the main record tables, and standard list exports may leave them behind or return only links. Plan a separate extraction for files, confirm the file size and count limits your instance enforces, and check whether knowledge articles keep their attachments and version history. Rewrite internal links to articles so they resolve in GLPI.

Contracts and integrations to rebuild

Contracts and licenses feed GLPI's contract management, so export vendor, term and cost fields with their asset links. Integrations do not move with data: sign-in, email intake, monitoring feeds and discovery sources must be rebuilt. GLPI checks authentication sources in this order: the internal database, LDAP directories, IMAP mail servers, then external methods such as REMOTE_USER. Plan that order before cutover.

What has to be rebuilt by hand in GLPI, not imported

ServiceNow workflows, business rules, UI policies, service catalog items, approval chains and SLA definitions are configuration logic, and they usually do not transfer as data. Exporting records gives you incidents, changes, configuration items and their history, but the behavior that routed and governed those records lives in ServiceNow's configuration. In GLPI you design that behavior again: ticket templates and forms, automatic actions and rules that assign or escalate tickets, approval steps on change requests, and service level definitions with their calendars and escalation targets. Treat each one as a design item with a named business owner who signs off how the new behavior should work. Do not assume a like-for-like rebuild. Some ServiceNow constructs have no direct GLPI counterpart, so the design review should record each gap and the agreed workaround before configuration starts.

Start by deciding what to carry over. Review the custom fields, categories and CI classes in your ServiceNow instance and sort them into three groups: those that are still used and need a GLPI home, those that can be merged into standard GLPI item types or dropdowns, and those that exist only for retired processes and should be left behind. GLPI's configuration management and custom asset definitions cover many CI classes, but each class you keep needs its attributes, relationships and lifecycle states mapped deliberately. Keep the list short. Every extra custom type multiplies the rules, reports and training you must maintain. Ask your GLPI implementation partner to confirm which of your classes map to standard item types before any data load.

Plan plugins as part of the upgrade process, not as an afterthought. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates. Any plugin that adds asset types, reports, integrations or forms therefore needs a compatibility check against the target GLPI version and a reactivation step in your runbook, with a test run on a copy of the database. The GLPI update procedure also requires backing up the database, the files and the config directory, including glpi.key and glpicrypt.key, before replacing application files and running php bin/console db:update. Losing those key files can make encrypted stored data unreadable, so store copies separately. Confirm the plugin list, its maintainers and its support status for your target release before you commit to a go-live date.

The migration sequence: inventory, pilot, parallel run, cutover and decommission

This sequence moves ServiceNow ITSM records, assets and CMDB data into GLPI in controlled stages, so each count, relationship and configuration is checked before ServiceNow access is retired.

Inventory records, configuration and integrations
Your team lists every ServiceNow table in scope (incidents, problems, changes, configuration items, assets, contracts, knowledge articles and service catalog items), with record counts, date ranges and the fields that actually carry data. Alongside the data, record each business rule, workflow, approval, SLA definition, notification, inbound and outbound integration, and any Discovery or MID Server feed. Confirm with your ServiceNow administrators which export method each table needs, since list exports have default record limits and attachments require a separate extraction. The output is a signed inventory workbook that maps each source table to a GLPI itemtype, flags fields with no destination, and names an owner for every integration that must be rebuilt or retired.
Pilot the import in a non-production GLPI
Install a non-production GLPI from the current release line on a documented stack. Check the GLPI prerequisites for the PHP and MariaDB or MySQL versions that match your chosen release, since the README and installation docs state different minimums for different versions. Point the web server's document root at GLPI's public directory, enable URL rewriting to index.php, and confirm the login path with the authentication order you intend to use in production. Load a representative sample of each exported table through GLPI's import tooling or a scripted load, then review how statuses, requesters, assignees, dates and categories landed. The output is a pilot report listing every mapping defect found, the fix applied to the mapping, and a sign-off from the process owners for incidents, changes and configuration items.
Run the full import in parallel and reconcile
Run the complete import against a second non-production copy and keep ServiceNow as the system of record while the business works in both tools for the agreed period. Reconcile record counts per table, open versus closed states, date fields, and attachment completeness against the inventory. Verify configuration item relationships separately, because relationship loss is the most common silent error: check parent-child links, hosted-on and depends-on pairs, and owner assignments on a sample drawn from each CI class. Log every discrepancy with a root cause and a fix. The output is a reconciliation pack showing each count and relationship check with a pass or a documented exception, approved by the service owner before cutover is scheduled.
Freeze the window and back up before cutover
Agree a change freeze with the business so no new ServiceNow records are created during the final delta load, and communicate the window to requesters and approvers. Immediately before the final import, take a backup of the GLPI database, the files directory and the config directory, including the glpi.key and glpicrypt.key files, since losing those keys can make encrypted data unreadable. Store the backup offsite and test a restore on a separate host. Then run the final delta load, repeat the reconciliation checks, and switch intake channels (email gateway, forms, integrations) to GLPI. The output is a cutover record with the backup location and restore test result, the reconciliation results from the final run, and a named rollback decision owner.
Decommission ServiceNow access after retention
Once the rollback window closes and the business confirms that GLPI is the working system, set ServiceNow to read-only for the migrated scope and remove integrations, MID Server connections and service accounts that still point at it. Retention rules for records, audit trails and attachments should be settled with legal, compliance and records management before the subscription is closed, and any archive copies should be stored under the same access controls as production data. Schedule post-cutover reviews of GLPI upgrades, including plugin reactivation after major updates, so the platform stays supported. The output is a decommission checklist signed by the service owner, an archive manifest describing what was kept, where, and for how long, and a recorded date after which ServiceNow access ends.

What drives the cost and duration of the move, and how to keep each down

This table lists the main factors that raise or lower the cost and calendar time of moving from ServiceNow ITSM to GLPI, with the reason each one matters and how to reduce it. Read it before requesting a quote, because the same scope items appear in any written proposal. The main takeaway is that most of the effort sits in data reconciliation, process redesign and staff time, not in installing GLPI.

Driver	Why it moves cost or effort	How to keep it down
Active record types and history depth	Each record type needs its own field mapping and validation, and years of closed incidents, changes and approvals multiply the reconciliation work.	Migrate open records and a defined look-back period, and archive older history in read-only form outside GLPI.
Custom tables and workflows to redesign	ServiceNow tables and flows built for your organization have no direct GLPI equivalent and must be rebuilt as GLPI item types, rules and workflows.	Inventory custom tables and flows first, then retire the ones nobody uses before any design work starts.
CMDB size and relationship complexity	Configuration items and their relationships must be modeled as GLPI assets and links, and dense dependency graphs take longer to validate.	Limit the first load to business-critical CI classes and relationships, and agree the CI class list in writing.
Integrations and identity sources	Each connected monitoring tool, directory or email flow needs a new connector, and GLPI authenticates against its database, LDAP, IMAP or external methods in that order.	List every integration and identity source, then decide which ones GLPI must replace on day one.
Attachment volume	Attachments are not included in standard list exports, so they need a separate extraction and storage plan, and volume drives transfer and storage time.	Agree a retention rule for attachments and move only the ones tied to open or regulated records.
Business processes to re-approve	Change approval paths, SLAs and catalog items must be re-approved by owners before they are rebuilt, and every rework cycle adds time.	Bring approvers into the design sessions early and approve a reduced set of standard change types.
Hosting and sizing for GLPI	GLPI needs PHP and MySQL or MariaDB with a web server, and sizing depends on user count, asset volume and backup targets, which you must confirm for your own environment.	Confirm supported versions in the GLPI installation documentation and size against measured asset and agent counts.
Internal staff time for reconciliation and training	Your staff must validate migrated data, approve mappings and learn the new interface, and this time is usually the largest unbudgeted cost.	Name a data owner per record type and schedule training after the reconciliation sign-off, not before.

What usually goes wrong in a ServiceNow to GLPI move, and how to prevent it

Most failed ServiceNow to GLPI moves fail in the data mapping and cutover phases, not in the software install. The cards below follow a typical project from extraction through mapping, rebuild and go-live, and name the check that catches each problem before users depend on it.

CMDB relationships lost in mapping

ServiceNow stores configuration items as classes linked by relationships, such as a service that depends on a server that runs an application. A flat export of CI rows keeps the names but drops those links, and GLPI does not reconstruct them automatically. During the mapping phase, list every relationship type the business uses for impact analysis and decide which ones GLPI will hold as links between items. Then test a known outage path in a staging instance before cutover.

Duplicate or orphaned records after partial imports

Re-running an import after a timeout or an export limit is hit often creates a second copy of incidents, assets or users, and some records end up with no parent. Set a stable external ID, such as the ServiceNow sys_id, in a custom field on every imported record during the load phase. Before each rerun, query for that field and reconcile counts by table rather than trusting that the import finished cleanly.

Unclear ownership of rebuilt approvals

Change approval chains in ServiceNow often reflect informal decisions that nobody wrote down, and rebuilding them in GLPI can leave no one accountable for the result. Before building any approval step in GLPI, have the change manager name an owner for each approval group and the criteria for each risk level. Walk the rebuilt flow with those owners in the design review, and record sign-off in the project file.

Identity mismatches between directory and GLPI

GLPI tries authentication sources in order: the internal database, then LDAP, then IMAP, then external methods such as REMOTE_USER. If the directory user IDs differ from the usernames held in old ServiceNow records, requesters and assignees will not match, and incidents may appear under the wrong person or with no owner. Compare a sample of active accounts between the directory and the ServiceNow user table during the mapping phase, and confirm the login attribute GLPI will use before loading any tickets.

Plugin and upgrade breakage after a version change

GLPI plugins are suspended after a new version is detected and must be reactivated after major updates, so a team that installs a plugin on an older release can lose a custom form or integration on the first upgrade. Record every plugin and customization in the build inventory, and test each one on the version you plan to run at go-live. Confirm the exact release line with the vendor before you choose it, since the newest major version may not match your plugins yet.

Incomplete backup before cutover

The GLPI update procedure requires a backup of the database, the application files and the config directory, including the glpi.key and glpicrypt.key files. Without those keys, encrypted fields and stored credentials may not be readable after a restore, even when the database is intact. Before cutover, restore the full backup set to a separate server, log in, and check that encrypted fields decrypt. Keep the ServiceNow export and its extraction logs in the same retained archive.

How the move differs by starting point and organization size

A small IT team with a single ServiceNow instance and a short service catalog usually has the smallest migration. The record volume is modest, the number of workflows is limited and the people who know the old setup can answer questions quickly. Extraction is mostly a matter of exporting incidents, requests, changes and configuration items in batches that stay within ServiceNow's export limits, then loading them into a GLPI instance built for the team. The rebuild effort concentrates on a handful of approval paths and catalog items, which are often simpler to recreate in GLPI than to port one for one.

Scope: Confirm which record types are live and which are historical. Many teams move only open items and a defined period of closed history.
Extraction: Plan one export pass per table, then reconcile record counts against the source before anything is loaded.
Rebuild: List the approval steps and catalog items that people actually use, and drop the rest.
First decision: Settle the GLPI data model for locations, users and groups before importing, since changing it later means reloading.

Before starting, ask the team which five ServiceNow screens they use every day, because those define the minimum GLPI setup that has to work on cutover.

Questions buyers ask before moving from ServiceNow to GLPI

What drives the cost of moving from ServiceNow to GLPI?

The main cost drivers are the volume and messiness of the data, the number of custom workflows and catalog items to rebuild, the number of integrations that feed or read from ServiceNow, and the size of the user base being trained. GLPI itself has no license fee under GPL-3.0, so the spend moves to hosting, implementation, optional support and the staff who run the platform. Ask any implementation partner for a quote built from a written scope that lists each of these components separately, with what is one-time (extraction, mapping, rebuild, training) and what recurs (hosting, patching, support, staff time).

How long does a ServiceNow to GLPI migration usually take?

Duration depends mostly on the scope you agree, not on GLPI's install time. The timeline is set by how many record types you move, how much history you keep, how many workflows and catalog items must be rebuilt by hand, how many integrations need replacing, and how many approval rounds the mapping needs from your service owners. Parallel running and cutover add time at the end. No fixed duration applies to every estate, so ask for a schedule tied to milestones in the written scope and confirm which dependencies sit with your team.

What does the migration need from our own team?

Your team supplies knowledge that no export contains. Service owners must confirm how incidents, problems and changes are classified, which configuration items matter, and which SLAs and approval paths are actually enforced. Someone must own the ServiceNow data extraction, another person the CMDB clean-up decisions, and an administrator the target GLPI environment. Plan time for review cycles on the mapping and for user acceptance testing before cutover. Ask the implementation partner to list these named roles and hours in the scope document.

Can an internal IT team migrate from ServiceNow to GLPI alone?

A capable internal team can run the migration alone if it has time, GLPI administration experience and someone who understands the ServiceNow data model well. The risk lies in the parts with the least tooling: rebuilding workflows, catalog items and approval logic, and reconciling CMDB relationships. Teams that choose to self-deliver usually still need to read the GLPI update and installation documentation carefully, since GLPI requires PHP 8.3 or later and MariaDB 10.11 or later or MySQL 8.0 or later for the current version. Consider a fixed-scope engagement for the hard parts while keeping day-to-day ownership in-house.

How do we handle attachments and ticket history during the move?

Records and attachments are extracted separately, so plan for both. ServiceNow list exports cover structured fields, but attachments generally need a separate extraction, and historical comments, work notes and audit trails need their own decision. Decide which history must be preserved for audit or legal reasons and which can be archived read-only in the old system, then map and test a sample before the full load. Keep the original ServiceNow data under retention rules until the new GLPI records are verified. Confirm the exact extraction method for your ServiceNow release with your administrator.

What do GLPI Network support and hosted options cost?

The GLPI Network subscriptions page publishes these prices: public cloud at 19 euros per user per month and private cloud at 21 euros per user per month with a 25-user minimum. Self-hosted subscriptions start at 100 euros per month for the Basic tier, which covers up to 10 agents and 500 assets, and reach 4,500 euros per month for Enterprise, which includes level 3 support and GLPI Network marketplace plugins. The GLPI project site also offers a 45-day free trial of its cloud service. Confirm current prices and tier limits on the subscriptions page before budgeting, because published prices can change.

How do the parallel run and cutover work?

A parallel run keeps ServiceNow and GLPI both available for a defined period, with new records entered in one system as the agreed primary and reconciled against the other. Cutover is the point where GLPI becomes the only system of record, the ServiceNow integrations are switched off, and the final delta load is applied. Agree the entry criteria, the reconciliation checks, the rollback plan and the freeze window for changes before the run starts. Put these into the written scope so that sign-off is clear to both your service owners and any implementation partner.

How DeployOpen scopes, runs and supports a ServiceNow to GLPI migration

DeployOpen plans and implements self-hosted GLPI inside the client's own infrastructure, including its cloud accounts, data centers or air-gapped networks. Each migration starts with a written scope that sets out which ServiceNow records, assets and CMDB data move, and what is rebuilt by hand.

How we scope

Inventory which ServiceNow tables, assets and CMDB classes are in use and which are retired.
Agree in writing which incident, problem, change and configuration item records move to GLPI.
Confirm the export route, attachment handling and the list of workflows and catalog items to rebuild.

How we build

Install GLPI on the client's infrastructure with the PHP and MariaDB or MySQL versions confirmed for the chosen release.
Map ServiceNow fields to GLPI item types and test imports on a copy before any production load.
Rebuild approval flows, SLAs and service catalog entries as GLPI configuration, and test each one against sample tickets.

How we hand over

Document the field mappings, import scripts, configuration and any rebuilt workflows for your team.
Walk through a cutover checklist covering data reconciliation, user authentication and agent deployment.
Provide written runbooks for backups of the database, files and the glpi.key and glpicrypt.key files.

How we support

Engagements are fixed-scope, with scope, deliverables and timelines agreed before work starts.
Ongoing support, upgrades and continuous testing are available as a retainer after handover.
Ask Teclib' directly about optional GLPI Network support, since it is separate from DeployOpen services.

Migrate from ServiceNow to GLPI