Migrate from Freshservice to GLPI

Why teams moving from Freshservice to GLPI start with the XML export

Most teams leaving Freshservice do so because of a renewal, a per-agent licensing change, a data residency requirement or a wish to stop depending on one vendor's data model. The move is a data and configuration project, not a file copy: GLPI can hold the tickets and assets, but someone has to map them, import them and rebuild the operating rules that made the old service desk work. The starting point is the full XML export from Freshservice. A Freshservice account administrator opens Admin, Account, Export, and the archive arrives as XML at the registered agent email address. Confirm that the mailbox is reachable and that the export completes before any contract notice is served, because the export is the only complete copy of the history you will get in one file.

GLPI itself carries no license fee. It is free software under GPL-3.0, and the costs sit in the work around it: a PHP and MariaDB or MySQL host that you operate, the mapping of Freshservice fields to GLPI tickets, assets, users and knowledge base articles, the import and checks, and the rebuild of workflows, SLAs and the service catalog. GLPI does not read a Freshservice XML file directly, so the XML has to be parsed and transformed into GLPI-ready records, a step that is usually scripted and reviewed by a person. Ask any implementation partner to state in writing which export fields they will map, which they will drop, and how they will prove that ticket history and attachments survived the conversion. Your internal platform or IT staff usually own the hosting and the business rules, and an implementation partner often carries the mapping and import. Expect the effort to be driven by the number of asset types, custom fields and approval workflows, not by the size of the export file alone, and treat the rebuild of SLAs and the service catalog as the highest-risk part of the project.

Which Freshservice capabilities map to GLPI and which need rework

This table maps the main Freshservice service desk areas to their closest GLPI modules and marks each as clean, needs rework or gap. GLPI documents ITIL incident, problem, change and service level management, asset inventory, configuration management, knowledge base and contract management, but the exact behavior of workflows, approvals and portal forms varies by version, so confirm each row in the GLPI release you plan to run. GLPI 12.0.0 rewrote the knowledge base, so plan article migration and review separately.

Freshservice capability	GLPI equivalent	Migration note
Tickets and incident handling	Incident management (ITIL) with tickets, statuses and assignment	Clean for core ticket records. Confirm how imported conversation history, attachments and requester fields appear in your version.
Problem and change management	Problem and change modules linked to incidents	Needs rework. Map Freshservice problem and change types, statuses and linked items to GLPI fields, then test the links after import.
Asset inventory	Asset inventory and configuration management, populated by GLPI Agent	Needs rework. Freshservice asset records do not carry over automatically. Rebuild asset types and relationships, then run GLPI Agent to refresh hardware and software data.
Contracts and licenses	Contract management linked to assets and suppliers	Needs rework. Confirm that contract dates, costs and linked assets import cleanly, and rebuild renewal reminders.
Knowledge base	Knowledge base module	Gap risk. GLPI 12.0.0 rewrote the knowledge base, so confirm article structure, categories, visibility and attachments before migrating content.
SLAs and OLAs	Service level management with SLAs and, in newer versions, group-managed OLAs	Needs rework. Recreate SLA targets, calendars and escalation rules by hand, and confirm OLA behavior in your version.
Service catalog	Service catalog or request forms built from ticket templates	Gap. Expect to redesign catalog items, forms and fulfillment steps in GLPI rather than import them.
Approvals	Approval steps tied to tickets and changes	Needs rework. Rebuild approval chains and test who receives each request and in what order.
Automation and portal forms	Business rules, notifications and custom forms	Gap. Freshservice automations and portal forms must be rewritten, and GLPI plugins may be needed. Confirm each rule in a test instance.
Reporting	Built-in statistics and saved searches	Needs rework. Rebuild dashboards and recurring reports, and check that historical trend data is carried over before cutover.

What the Freshservice export carries and what you rebuild by hand

The Freshservice export is the raw material for the migration, but it is not a finished GLPI configuration. Each card below separates what the export is expected to hold, what you must confirm by opening it, and what has to be recreated in GLPI. Map fields from your own export sample before you write any import logic.

The XML account export

Freshservice account administrators start the full export from Admin, Account, Export, and the XML arrives at the registered agent email address. Treat that file as the single source for the migration and keep an untouched copy before any transformation. Confirm by opening it that the file is complete, readable and covers the modules you use, such as tickets, assets and knowledge articles. Plan the mapping from your own sample rather than from assumptions about element names.

Ticket and conversation history

Tickets, their status changes and their conversation threads are what auditors and agents ask for after cutover. Confirm that each ticket keeps its requester, dates, status history and internal and public notes in the export sample. Decide which closed tickets move into GLPI and which stay in an archive, since the import effort grows with volume. Recreate the ticket numbering scheme and any reference format your teams quote to customers.

Assets and their relationships

Asset records and the links between them, such as a laptop assigned to a user or a server supporting an application, drive change and incident impact analysis. Confirm that the export carries asset types, serial numbers, locations and assignments, and that relationships are present rather than flattened. In GLPI, rebuild the asset model in its own item types and deploy the GLPI Agent to refresh hardware and software inventory from the devices themselves, so migrated records are checked against live data.

Knowledge articles

Solution articles and their categories hold the answers your agents reuse. Confirm in the export that article titles, bodies, folders and publication status survive, and check embedded images and attachments, which often load separately. GLPI 12.0.0 includes a rewritten knowledge base, so plan the target structure and review access levels before importing, since article visibility by group must match your current rules.

Users, groups and authentication

Requesters, agents and groups are exported with their roles and contact data, but login credentials are not a reliable part of the migration. Confirm that the export lists every agent and group that owns tickets or assets. In GLPI, configure authentication in the order the user documentation describes: internal database, then LDAP directories, then IMAP mail servers, then external methods such as REMOTE_USER. Decide how SSO will be handled and test each login path before cutover.

Workflows, SLAs, notifications and integrations

Automations, SLA targets, approval steps, notification rules, email-to-ticket routing and third-party connectors usually do not travel in a data export, so none of them can be assumed to exist in GLPI after import. Inventory them in Freshservice first and note which ones you still use. Rebuild SLAs and OLAs in GLPI's service level modules, recreate notification templates and mailbox routing, and test each one against sample tickets. Confirm with your own Freshservice admin which integrations need replacements.

How a Freshservice to GLPI migration runs from inventory to decommission

This sequence moves IT service management from Freshservice to self-hosted GLPI in controlled stages, so each team's tickets, assets and processes are verified before the old desk is switched off and its records are archived.

Inventory workflows, SLAs, catalog and assets
Export the full service desk from Freshservice's Admin, Account, Export menu, which delivers XML to the registered agent email address, and list what it contains against what you run today. Record every automation rule, approval flow, SLA target, business hours calendar, service catalog item, asset type, and integration with monitoring, HR or directory tools. Mark each item as migrate as data, rebuild in GLPI, or retire. Owner: the ITSM process lead with a Freshservice administrator. Output: an inventory list with a disposition for each item, reviewed and signed off by the service owners.
Provision GLPI on your own infrastructure
Build the GLPI host in your own cloud account, data center or air-gapped network, following the GLPI prerequisites for the release you select. Confirm the PHP and database versions in the current prerequisites page (the README and the installation docs state different minimums for different releases, so check the version you choose), use MariaDB or MySQL only, and point the web server document root at GLPI's public directory with URL rewriting to index.php. Store the glpi.key and glpicrypt.key files with your backup set from day one. Output: a hardened, backed-up staging instance with a documented build record.
Run a pilot import for one team or asset class
Select one team or one asset class, such as laptops, and convert the Freshservice XML and any CSV extracts into GLPI's import formats with scripts you can rerun. Import into a staging instance only, then check ticket counts, requester links, assignee history, asset serial numbers and contract dates against the source. Rebuild the pilot team's SLA and approval flow in GLPI's ITIL modules and test each one with sample tickets. Output: tested import scripts and a pilot reconciliation report listing every mismatch and its fix.
Operate a parallel run with agreed ownership
Keep Freshservice open for new work while GLPI takes the pilot team's new tickets, and agree in writing which system owns each queue, category and asset class during the overlap. Route duplicate-risk items, such as monitoring alerts, to one system only. Review open tickets in both systems at a fixed cadence and log every discrepancy to closure. Output: a signed ownership matrix and a discrepancy log that shows no unresolved items for the pilot scope.
Cut over with a final delta export
Freeze new requests in Freshservice, run the full export again to capture changes since the first extract, and import the delta into GLPI. Reconcile record counts, open ticket states, knowledge base articles and asset assignments, then publish the new intake channel and update integrations to point at GLPI. Keep a rollback plan that defines the conditions for returning to Freshservice. Output: a cutover runbook with timed steps, the delta import log and a reconciliation report signed by the service owner.
Decommission and retain the Freshservice archive
After the agreed stabilization period, cancel the Freshservice subscription at the date your contract sets, and store the final XML export, the import scripts, the reconciliation reports and the cutover runbook in your records system with an owner, a location and a retention period set by your legal and compliance teams. Confirm the archive can be read without Freshservice access, and remove integration credentials. Output: a retention record that lists each archive item, where it is held, who can access it and when it will be reviewed for disposal.

How the migration changes by team size and starting point

A small IT team with a few hundred assets and mostly standard incident and request handling usually has a narrow migration. The export is small enough to review by hand, and most of the effort goes into mapping ticket statuses, requesters and a handful of asset types into GLPI's model. One or two people can often own the work, and the configuration tends to stay close to GLPI's defaults.

Scope: Core tickets, requesters, groups and a modest asset list, with few custom fields and little automation to rebuild.
Who does the work: Usually an administrator who also runs day-to-day support, so the cutover window needs to be planned around their availability.
Steps that grow: Asset import validation and agent rollout to workstations, since even a small fleet needs consistent inventory.
Steps that stay small: SLA and catalog rebuild, which may be a short list of agreed rules.
Lightweight cutover: A short parallel run and a documented freeze on the old tool.

Before you commit, measure the number of tickets, assets and active requesters in your XML export, and count the workflows you actually use. Confirm with your GLPI integrator which items need manual rebuilding.

Running Freshservice and GLPI in parallel without splitting ownership

Every ticket queue and asset record needs exactly one owner at any moment during the parallel run. Before the first GLPI import, name the system of record for each queue (for example, service requests from one department on GLPI while incidents stay on Freshservice) and write down a cutover date rule, such as which system takes all new requests created after a stated date. Agents should never answer the same requester from both tools. Reconcile open tickets at the start of the run and again before cutover: list every open Freshservice ticket, confirm whether it was migrated, closed, or intentionally left behind, and record the decision in a shared tracker that the service desk lead signs off. The same discipline applies to assets. A device that appears in both inventories with different owners, serial numbers or locations is the most common source of conflicting truth, so choose which tool is authoritative for each asset class before you begin.

The Freshservice XML export is a point-in-time copy. Any ticket edited, asset changed or requester updated in Freshservice after the export date is absent from GLPI until you capture it. Plan a delta step before cutover: either re-run the full export and compare record IDs and last-updated fields against what GLPI already holds, or limit changes in Freshservice to a freeze window so the final export is complete. Confirm with Freshservice support which fields the export carries for each record type before you rely on it for reconciliation. For hardware and software records, GLPI Agent can refresh asset data during the run, since it sends hardware and software inventory to GLPI on a schedule you configure. Treat agent results as the authority for technical attributes, but keep ownership fields such as assigned user and cost center under your reconciliation rules, because the agent cannot know them.

Set the cutover checklist before the parallel run starts and hold it to the same standard as the migration itself. The checklist should confirm that the final delta is loaded, that open ticket counts match the reconciliation tracker, that GLPI Agent has reported from the in-scope fleet, and that Freshservice automations and notification emails are disabled so they do not create or reopen tickets after the switch. Ask whoever runs the migration to document who can approve exceptions during the freeze, because unresolved exceptions are where two sources of truth tend to survive past the cutover date.

What drives cost and duration in a Freshservice to GLPI move

This table lists the work that most changes the cost and length of moving from Freshservice to GLPI, with the reason each item matters and how to keep it contained. Read it as a checklist for scoping: the largest drivers are usually the history you choose to carry over, the number of SLAs and approvals you rebuild, and the upkeep of a self-hosted GLPI instance. The GLPI software is free under GPL-3.0, so most of the spend is labor, hosting and support.

Driver	Why it matters	How to keep it down
Volume and age of ticket history	The XML export carries the full service desk, so older tickets, attachments and conversations add mapping and validation work before any cutover.	Decide which closed-ticket years to import, archive the rest as read-only exports, and sample-check imported conversations.
Number of asset types and relationships	Each asset class, its fields and links to users, contracts and locations must map to GLPI's asset and CMDB records before inventory data can be trusted.	Start with the asset types you report on, retire unused classes, and map relationships in one reviewed spreadsheet.
Custom fields and forms	Freshservice custom fields and request forms do not carry over automatically, so each one needs a GLPI equivalent or a documented decision to drop it.	Inventory every custom field and form, then rank them by how often agents or reports use them.
SLAs, OLAs and approval workflows	Priority matrices, escalation rules and approval chains are rebuilt in GLPI's ITIL and service level modules, and each rule needs testing.	Rebuild the most used SLAs first, then cut low-volume rules, and test each one against real sample tickets.
Service catalog and knowledge base	Catalog items, forms and articles must be recreated or reformatted, and the knowledge base may need restructuring in the GLPI version you deploy.	Publish the catalog items that account for most requests first and move articles in batches with an owner for each.
Integrations with monitoring, HR and identity	Alert feeds, joiner and leaver events and directory sync each need a connector, credentials and testing in GLPI.	List integrations by business impact and build only the ones needed on day one; confirm each connector with the vendor or community.
Authentication setup against LDAP or IMAP	GLPI tries the internal database, then LDAP directories, then IMAP mail servers, so the order and bind settings affect who can log in and with which role.	Test one directory group with a pilot account before enabling the whole user base, and document the authentication order.
Hosting, patching and plugin upkeep	GLPI needs its own PHP, database and web server tiers. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so each upgrade includes plugin checks.	Pin a release cadence, back up the database, files and config keys before each update, and budget plugin testing into every upgrade window.
Inventory agent rollout across endpoints	GLPI Agent must be packaged, deployed and verified on Windows, macOS and Linux devices, and gaps in coverage distort asset counts.	Roll out in rings by department, and compare agent-reported counts with the endpoint management source before retiring old records.
Training for agents and administrators	Agents need new ticket and asset screens, and administrators need to run configuration, updates and reports they previously left to the vendor.	Train by role, use a sandbox copy of the migrated data, and record short how-to guides for the top ten tasks.
Parallel-run length	Running Freshservice and GLPI side by side doubles data entry and reconciliation, and the overlap is often the longest unplanned cost.	Set a fixed parallel period with exit criteria, such as ticket volume matched and SLA reports validated, agreed before the cutover.
GLPI Network subscription, if chosen	GLPI Network public cloud is listed at 19 euros per user per month and private cloud at 21 euros per user per month with a 25-user minimum, and self-hosted tiers from 100 euros per month, per the GLPI Network subscriptions page. GLPI itself is free under GPL-3.0.	Compare the subscription tiers against your own support needs, and ask for a written scope before choosing paid support or hosting.

What usually goes wrong when moving service desk history to GLPI

Most failed Freshservice moves to GLPI do not fail in the import itself. They fail in what was never exported, what was duplicated, and what was switched on or backed up too late. Each card below names one of these failure modes and the check to run in your own environment before cutover.

Conversation history lost in export

The full XML export from Freshservice is only useful if the ticket conversations, notes, attachments and their timestamps arrive intact at the agent address you registered. Before any mapping work, open a sample of tickets in the XML and confirm that replies, private notes and status changes are present, not only the ticket header. Map each conversation element to a GLPI followup or task so authors and dates survive the move. Record which fields you could not map so the gap is documented rather than discovered later by an auditor or an agent.

Assets duplicated across sources

Assets often exist in Freshservice's asset list, in a discovery feed, and in a spreadsheet kept by the infrastructure team. Importing all three into GLPI creates duplicate computers, monitors and contracts that split the inventory and inflate license counts. Choose one authoritative source per asset class, then decide whether GLPI Agent will own hardware and software records going forward. Run a deduplication report on serial numbers and hostnames before the final load, and keep a list of the records you merged so the decision can be reviewed.

SLAs rebuilt without calendars

Freshservice SLA targets are measured against business hours and holidays that someone configured for your organization. If GLPI's SLM and calendars are recreated with default settings, response and resolution clocks will run at different times, and historical breach reports will change after cutover. Export the business hour definitions from Freshservice, rebuild the calendars in GLPI first, then assign them to each SLA. Replay a sample of closed tickets through the new SLAs and compare the breach outcomes with the figures your managers already trust.

Users and groups not matched to authentication

Freshservice users are identified by email address, but GLPI checks authentication sources in a fixed order: the internal database, then LDAP, then IMAP, then external methods such as REMOTE_USER. An imported agent with no matching directory account can end up with a local password or be locked out entirely. Decide which source authenticates agents and requesters, match identifiers to the directory before import, and test one login per role. Confirm group membership drives ticket visibility, because a wrong group mapping silently exposes or hides tickets.

Plugins left disabled after update

Custom forms, reporting and integration plugins often carry most of the workflow logic you migrated. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates. If the cutover window includes an upgrade, a team may find forms missing or approval steps skipped on day one. Inventory every active plugin, check each one for compatibility with the target release, and add reactivation and a functional test of each plugin to the cutover runbook.

Encryption keys not backed up

GLPI stores encrypted values and relies on the glpi.key and glpicrypt.key files in its config directory. Restoring the database and application files without those keys leaves stored credentials, such as passwords for LDAP bind accounts or API connections, unreadable. The update procedure requires backing up the database, files and config directory together. Store copies of both key files in your secrets vault or offline backup, test a restore into a staging instance, and confirm an integration still authenticates after the restore.

What running GLPI in your own infrastructure adds after the import

Once the data is in GLPI, your team owns the running application. The web server must point its document root at GLPI's public directory, not the installation root, and it needs URL rewriting so requests route through index.php. The installation docs cover Apache, Nginx, lighttpd and IIS. Confirm which of these your hosting standard uses, and test that files outside the public directory are not reachable before users log in to the imported ticket history.

The database must be MariaDB or MySQL. The current README lists MariaDB 10.11 or later or MySQL 8.0 or later, while the GLPI 11.0 installation docs list MySQL 8.0 or MariaDB 10.6 and state that only these two are supported. The PHP requirements also differ: the README asks for PHP 8.3 or later, and the 11.0 installation docs ask for PHP 8.2 or later. Before you choose versions, confirm the requirements for the exact release you deploy, since the release you pick determines which set applies.

Every update follows the same sequence in the GLPI update documentation. Back up the database, the application files and the config directory, including glpi.key and glpicrypt.key, because losing those keys can make stored credentials unreadable. Then replace the application files and run php bin/console db:update. Since GLPI 11.0, plugins are suspended when a new version is detected and must be reactivated after major updates, so schedule plugin testing as part of each upgrade window.

Freshservice to GLPI migration questions buyers ask before hiring help

How much does a Freshservice to GLPI migration cost?

The GLPI software itself has no license fee, since it is distributed under GPL-3.0, so the cost is the work and the infrastructure around it. The main components are the server and database hosting you pay for each year, the one-time migration work (export handling, data mapping, test loads and cutover), the rebuild of workflows, SLAs and the service catalog, and the time your own staff spend on reviews and training. Costs rise with the number of agents, assets, custom fields, approval flows and integrations you need to rebuild. If you want vendor support, GLPI Network public cloud costs 19 euros per user per month and private cloud 21 euros per user per month with a 25-user minimum, and self-hosted subscriptions start at 100 euros per month. Ask for a fixed-scope quote that lists each component separately, so you can see what is one-time and what recurs.

How long does a Freshservice to GLPI migration take?

The timeline depends on how much you are moving and how much of your process you want to redesign rather than copy. Scope drivers include the size of the ticket history, how many asset types and relationships must be recreated, how many SLAs and approval workflows exist, the number of integrations to rebuild, and how many rounds of user acceptance testing your team can do. A clean ticket and asset load is faster than rebuilding a custom service catalog. The written scope should state the phases, the deliverables for each phase and the dependencies on your team, such as access approvals and sign-off dates. Ask for the timeline to be tied to those milestones instead of a single end date, and confirm how a cutover window and a rollback plan are handled.

What does the migration need from our IT team?

Expect your team to provide decisions and access more than hands-on build work. You will need a named owner for process design, who signs off on how incidents, changes, problems and service requests map to GLPI's ITIL modules. You will also need an export of your Freshservice data, which an account administrator produces from the Admin area and receives as XML at the registered agent email address, plus access to your asset sources, such as directories and inventory tools, and to the hosting environment. Reviewers from service desk, asset management and security should check sample records and permissions before cutover. Ask the provider to list every decision and access request in the written scope, with the person responsible and the date it is needed.

Can our own staff migrate from Freshservice to GLPI without a partner?

Yes, a capable internal team can do it, provided it has someone with database, web server and GLPI administration experience and enough time to test properly. GLPI requires PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later according to the project's README, while the installation docs list PHP 8.2 or later and MySQL 8.0 or MariaDB 10.6 for GLPI 11.0, so confirm the version you target before building. Internal teams often underestimate the data mapping work, the rebuild of SLAs and the ongoing patching. The GLPI update procedure requires backing up the database, files and the config directory, including glpi.key and glpicrypt.key, and plugins are suspended after a new version is detected in GLPI 11.0 and later. Weigh these tasks against your team's capacity and decide which parts, if any, to hand off.

Can all Freshservice history be imported into GLPI?

Most ticket records, requesters, agents and asset data can be mapped, but some history may need a different approach, and you should confirm this during scoping. The Freshservice export arrives as XML, and GLPI has its own data model, so fields, statuses, attachments, conversation threads and custom fields will need to be matched or stored in a way GLPI can display. Automation rules, approval flows, and integrations usually have to be rebuilt rather than carried over. Ask the provider to produce a field-by-field mapping document, a list of data that will be archived instead of imported, and a reconciliation report that compares record counts and sample tickets after each test load. Decide in advance how long you must keep old history and whether an archive is an acceptable record.

What does GLPI Network add compared with self-hosting GLPI?

GLPI Network is a set of paid services from Teclib', the company that edits and maintains GLPI, and it covers hosting and support rather than the core software. The public cloud option costs 19 euros per user per month and the private cloud option costs 21 euros per user per month with a 25-user minimum, while self-hosted subscriptions start at 100 euros per month for the Basic tier with up to 10 agents and 500 assets. Higher self-hosted tiers include level 3 support and access to GLPI Network marketplace plugins. Self-hosting keeps the data and hosting under your control, but you then own patching, backups and upgrades. Compare these options against your data residency rules, your internal operations capacity and the support level you need, and ask for the terms in writing.

What should we ask for in a Freshservice to GLPI migration quote?

Ask for a written, fixed-scope quote that separates one-time work from recurring costs. It should name each deliverable, including the data export handling, the target GLPI version, the hosting design, the mapping document, the rebuild of workflows, SLAs and the service catalog, the test cycles, training and cutover support. It should list your responsibilities, the assumptions behind the estimate, what is excluded, and how change requests are priced if the scope grows. Request the security baseline, backup and restore procedure, and the plan for upgrades and plugin reactivation after major releases. Finally, confirm the acceptance criteria for each phase and the support terms after go-live, so you can compare quotes on the same basis.

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

DeployOpen plans and implements self-hosted GLPI inside your own infrastructure, then migrates the Freshservice export into it under a written scope. The work covers tickets, assets, knowledge base articles and the workflows, SLAs and service catalog that need to be rebuilt by hand.

How we scope

Engagements are fixed-scope, with deliverables and timelines agreed in writing before work starts
The written scope lists which Freshservice record types move: tickets, assets, contracts, knowledge base articles and requesters
Scope also names the GLPI modules to rebuild, including SLAs, approval workflows and service catalog entries
Ask for an explicit exclusion list covering attachments, custom fields and integrations that will not be carried over

How we build

Stand up a GLPI instance in your cloud account, data center or air-gapped network, with PHP and MariaDB or MySQL versions confirmed against current docs
Convert the XML account export into GLPI import formats, then test field mapping on a sample of tickets before full load
Rebuild SLAs, escalation rules, categories and the service catalog in GLPI, and record each decision for review
Configure GLPI Agent for hardware and software inventory where the scope includes asset discovery

How we hand over

Deliver reconciliation reports comparing record counts and sample ticket histories between Freshservice and GLPI
Document the data mapping, rebuilt workflows, SLA definitions and admin procedures in a handover pack
Walk your administrators through ticket, asset and knowledge base tasks in the new GLPI instance
Provide a cutover checklist covering DNS, authentication order and the read-only period for Freshservice

How we support

Ongoing support, upgrades and continuous testing are available as a retainer after handover
Plan GLPI upgrades with backups of the database, files and the config directory, including the key files, before each change
Confirm plugin compatibility and reactivation steps for each major GLPI release before applying it
Agree support levels, response expectations and the upgrade calendar in writing as part of the retainer