ITSM RFP questions to ask before you choose a GLPI or iTop partner
Your service desk, asset register or CMDB needs replacing or building, and you have a short list of partners to compare. Run the evaluation with the same set of ITSM RFP questions for every bidder, sent in writing, and score the answers against one sample scope so the comparison is fair. Ask each partner to explain why they recommend GLPI or iTop for your case, not only which one they know best. The platform decision and the delivery decision are separate, so ask about each on its own terms.
Send the questions as a numbered written request with a short description of your environment: user and device counts, the ITIL processes in scope, identity and monitoring systems, and the ticket and asset volumes you expect. Ask for written answers tied to that sample scope, including how the CMDB classes will be modeled, which discovery method populates them (the GLPI Agent or iTop data synchronization, for example), how inventory agents will be rolled out, how SLAs and approval chains will be configured, and how tickets and assets will be migrated with a reconciliation check at the end. Confirm current supported versions with the vendor, since database and PHP requirements differ between GLPI 11 and iTop 3.3.
Separate platform choice from delivery capacity by asking two distinct sets of questions. For platform choice, ask what the partner would not recommend and under which conditions. For delivery capacity, ask who will do the work, how many engineers with GLPI or iTop experience they can commit, how changes to the scope are priced, and what the support subscription covers compared with what remains your team's responsibility. Ask for the subscription terms in writing, including what is one-time and what recurs, and what a quote would include. Treat vague or verbal answers as a risk to plan for.
GLPI or iTop: which questions decide the platform
GLPI covers ticketing, asset management, contracts and a CMDB-style inventory in one GPL-3.0 application maintained by Teclib'. Ask the partner to show how each GLPI capability maps to your ITIL processes and where the built-in model stops fitting your asset classes. The answers should come from your requirements, not from a general preference for the tool.
- License and support model: Confirm the GPL-3.0 license terms that apply to your use and whether you need a Teclib' subscription. The GLPI Network subscriptions page lists self-hosted tiers and support levels, so ask which tier the design needs and what it includes.
- Inventory through GLPI Agent: Ask how the GLPI Agent is deployed on Windows, macOS and Linux, how network discovery is scoped, and how the partner will check that inventory matches procurement and monitoring data.
- Runtime requirements: Confirm the PHP and database versions the target release needs. The GLPI README lists PHP 8.3 or later with MariaDB 10.11 or later or MySQL 8.0 or later, while the installation docs list older minimums for GLPI 11.0, so ask which set governs the version you will deploy.
- Web server and update path: Ask how the document root is set to the public directory, how the config keys and encryption key files are backed up, and how plugins are reactivated after a major update.
- Authentication: Confirm how LDAP, IMAP and external authentication are ordered and tested against your directory.
Check that the partner names the exact GLPI release and runtime versions in writing before the design is approved.
iTop is an AGPL-3.0 ITSM suite built on PHP and MySQL or MariaDB, with a CMDB that is customized through its data model. Ask the partner to explain how the data model will reflect your configuration items and relationships, and how the team will support it after go-live. The reasons for choosing iTop should be tied to your CMDB and change requirements.
- AGPL-3.0 obligations: Ask how the partner will handle AGPL-3.0 obligations for any modifications or hosted services you run, and whether your legal team has reviewed them.
- Customizable CMDB: Ask how classes, attributes and relationships will be modeled, how data consistency audits will be scheduled, and how impact analysis will be validated against your real dependencies.
- Combodo support and extensions: Confirm the Combodo support, training and consultancy scope, and which extensions come from the iTop Hub. Ask which ones are maintained and who owns patching them.
- Runtime requirements: Confirm the target release supports PHP 8.2 to 8.4, the database version, GraphViz, and whether MariaDB is the chosen engine. The iTop requirements page prefers MariaDB and discourages MySQL 8 for performance reasons.
- Sizing: Ask which Combodo reference layout applies to your ticket volume and console users, and how that layout changes if the CMDB grows.
Check that the partner states the target release version and each runtime component in the design document.
The choice between the two platforms should follow from a written requirements list covering ITIL processes, CMDB classes, discovery, approvals, SLAs and integrations. A partner who recommends one platform without testing it against those requirements is offering a preference, and you should ask for the comparison in writing. The justification should also cover run costs, support options and the skills your team already has.
- Requirement-by-requirement comparison: Ask for a table that maps each requirement to GLPI, to iTop, or to both, with a note on any gap that needs custom work.
- Runtime fit: Compare each platform's PHP and database requirements with your current hosting standards and patch cycle.
- Operating model: Ask who will administer the CMDB and workflows after go-live, and what skills that person needs on each platform.
- Support and exit path: Ask which support subscriptions are available, what they cover, and how data would be exported if you change platform later.
- Risk of rejected options: Ask what the partner would need to see to choose the other platform, so the decision is open to evidence.
Ask for the comparison document before the design phase, and confirm that it cites the release versions it tested.
Which questions to ask about CMDB, inventory, SLAs, migration and support
Why should we choose GLPI or iTop instead of another ITSM tool?
The right answer depends on your process model and data model, so ask the partner to tie the choice to your requirements rather than to a preference. A good answer covers how each platform handles the ITIL processes in scope, how flexible the CMDB model is, how inventory is collected, and what licensing and support options apply. GLPI is GPL-3.0 licensed, combines ticketing, asset management, contracts and inventory through the GLPI Agent, and offers a managed GLPI Network service. iTop is AGPL-3.0 licensed and is built around a customizable CMDB with graphical impact analysis and change management. Ask the partner to show a proof of concept against two or three of your real service flows, and to confirm current versions with the vendors before the decision.
How should the CMDB be modeled and kept accurate after go-live?
A good answer starts with the classes you need (servers, applications, services, network devices, contracts, users), the relationships between them, and the owner of each attribute. The partner should explain how the model supports impact analysis, for example linking a business service to the applications and hosts it depends on. Ask how population is sourced: agent inventory, network discovery, CSV import, and procurement or monitoring feeds. Reconciliation rules must be written down, including which source wins when two disagree and how duplicates are merged. Ask for the schedule of data consistency audits and who receives their findings. iTop provides data consistency audits and CSV import as documented features, and GLPI assets documentation describes its asset types; confirm the exact model with the partner against your own data.
How are GLPI Agents deployed across Windows, macOS and Linux?
The partner should describe a staged rollout rather than a single push to every endpoint. A good answer covers the agent packaging for each operating system, the server or task settings that point agents to your GLPI instance, and the pilot group used to check inventory quality before wider deployment. GLPI Agent collects hardware and software inventory, can run network discovery and inventory, and can deploy packages; it runs on Windows, macOS and Linux and is the successor of FusionInventory Agent. Ask how agents are authenticated, how inventory frequency is set, how laptops that are off the network are handled, and how unknown devices found by discovery are triaged. Confirm the deployment tooling your endpoint management team already uses, since it determines the distribution method.
How are SLAs, OLAs, escalations and approvals configured?
Ask the partner to walk through a sample configuration for one priority level, including response targets, resolution targets, business calendars, and the escalation path when a target is at risk. A good answer separates customer-facing SLAs from internal OLAs with other teams, and explains how OLAs are linked to ticket categories. For approvals, expect a named chain for standard, normal and emergency changes, with the approver, the condition that triggers each step, and the record kept as evidence. The partner should show how approval decisions, timestamps and reasons are stored on the ticket. GLPI 12.0.0 lists group-managed OLAs among its features, and iTop documents customizable SLA management; confirm which of these your version and configuration provide before agreeing the design.
How are tickets and assets migrated from the current service desk?
A sound migration plan has five stages: source extraction, field mapping, a trial load, dry runs and cutover. Ask the partner how they will extract tickets, attachments, assets, contracts and users from the current tool, and how they will handle closed tickets that should not be migrated. The mapping document should show each source field, its target field, and the transformation rule. Ask for at least one dry run on a copy of production data, with a reconciliation report of record counts and sample checks. Cutover should include a freeze window, a rollback plan and a retention decision for the old system's data. Ask who signs off each stage. Duration depends on data volume, number of sources and the quality of the source data, so ask the partner to base any timeline on a data profile of your estate.
What does a GLPI or iTop support subscription actually cover?
Start by separating what the vendor provides from what the implementation partner provides. GLPI Network publishes self-hosted subscription levels, from a Basic tier limited to 10 agents and 500 assets at 100 euros per month to an Enterprise tier at 4,500 euros per month with level 3 support and marketplace plugins, according to the GLPI Network subscriptions page. Combodo sells commercial support, training and consultancy for iTop, and its Community, Atelier and Forge tiers are sized by agent count. Ask the partner what the vendor subscription includes, what they support directly, the response expectations written into the agreement, and how plugins and upgrades are covered. Confirm current prices and terms with each vendor, since they change.
How do we keep the platform upgraded without breaking plugins or data?
A good answer describes a repeatable upgrade procedure with a backup step, a test environment and a rollback path. For GLPI, the vendor's update guidance requires backing up the database, the application files and the config directory, including the key files, before running the database update command. Since GLPI 11.0, plugins are suspended after a new version is detected and must be reactivated after major updates, so ask how plugin compatibility is checked before each upgrade. For iTop, ask how extensions from the iTop Hub are tested against new releases. Also ask who monitors security releases, how fast they are applied, and whether upgrades are included in the support or retainer scope. Confirm the required PHP and database versions for each target release before scheduling.
Partner answers that should worry you
Most ITSM RFP responses sound confident at the first read. The answers below are where a partner tends to skip the hard work of requirements, data, rollout and evidence, and each one is easy to test with a specific follow-up question. Use them to decide which answers need a written reply before you shortlist anyone.
Platform chosen before requirements
A partner who names GLPI or iTop in the first paragraph, before reviewing your ITIL processes, CMDB classes, integrations and reporting needs, is selling a product rather than a fit. Ask which requirements drove the choice, which options were rejected and why. A credible answer names the processes in scope, the number of agents and users, and the hosting constraints, and it accepts that one platform may not fit every requirement.
CMDB promised without a data model
Any claim of a complete CMDB that does not start with a class model, relationship types and an owner for each class is a warning sign. Ask who approves a new configuration item, how relationships between services and hosts are maintained, and which team answers for data quality after go-live. In iTop, the model is customizable, so the partner should show the classes they propose and explain what each one is for.
Agent rollout without a pilot
Inventory agents that go to every endpoint on day one tend to surface unknown devices, duplicate records and users who object to software on their machines. Ask for a pilot group, a list of the platforms covered (Windows, macOS, Linux), how agent deployment is approved, and how endpoints that cannot run an agent are recorded. Also ask who reviews the discovery results before they reach the CMDB.
Migration described as a simple import
A proposal that says tickets and assets will be imported from the old tool without mapping, reconciliation or sign-off is underestimating the work. Ask how open tickets, closed history, attachments, asset states and contract links will be mapped, how duplicates will be merged, and how record counts will be reconciled between source and target. Ask who signs off each reconciliation step before the old system is retired.
Support without defined service levels
A support offer described only as 'full support' or 'unlimited help' hides what is covered. Ask for written response targets by severity, the hours covered, which components are in scope (the application, plugins, database, web server, agents), and whether upgrades and security patches are included. For GLPI, confirm whether the subscription covers the self-hosted tier you need, since plugins are suspended after a new version is detected and must be reactivated after major updates.
Certifications or partner status not documented
Claims of a vendor certification, partner tier or compliance certificate should be backed by a document you can check. Ask for the certificate number, issuing body, validity dates and the vendor's written confirmation of the partner relationship. DeployOpen prepares systems and evidence for assessments but does not issue certifications or attestations, and any partner should state the same boundary clearly.
How to score partner responses without a price comparison
Weight evidence of similar work, method, written scope and handover well above headline cost. A scoring matrix for an ITSM partner should give the most points to proof that the partner has configured a service desk and CMDB like yours: an iTop or GLPI deployment with a comparable number of agents, a comparable CMDB class model, and an inventory rollout across the same mix of Windows, macOS and Linux endpoints. Ask for the method as well: how the partner would model CMDB classes and relationships, how it would seed the database from procurement and discovery data, how it would set up SLA calendars, escalation rules and approval workflows, and how it would migrate open tickets and history. Ask for named roles and the handover plan, including the documentation and training the internal team receives. A cheap quote from a partner who cannot describe these steps will cost more later in rework.
Request every quote as a written, fixed-scope agreement with the same structure. Ask each bidder to state scope, deliverables, assumptions, exclusions and client responsibilities in the same format. Scope should list the ITIL processes included (incident, request, change, problem), the CMDB classes in the first release, the integrations with monitoring and identity, and the number of agents and assets covered. Assumptions should state what the partner expects from you, such as access to a test environment, a named process owner for approvals, and clean source data for migration. Exclusions should be explicit, for example whether mobile devices, third-party integrations or post-go-live reporting are in or out. Client responsibilities should name who provides hosting, certificates, service accounts and sign-off. When every bidder answers against the same list, the responses become comparable, and you can see where a lower number simply leaves work out. Confirm with each bidder which support subscription, if any, is priced separately and what it covers.
Scoring criteria for ITSM partner responses
This table lists the criteria to score each ITSM partner's written answers against, with what a strong answer shows, what a weak answer shows and the evidence to request. Use it to compare answers on substance rather than on how polished the proposal reads. A partner that can name its design decisions, show a sample configuration and explain its migration reconciliation will usually stand out from one that relies on general claims about GLPI or iTop.
| Criterion | Strong answer shows | Weak answer shows | Evidence to request |
|---|---|---|---|
| Platform rationale | Ties GLPI or iTop to the named ITIL processes, asset volume, team skills and licensing model, and names the trade-offs of the alternative | Recommends one platform without reference to the client's processes or data volumes | Written fit assessment, process scope list, and a comparison covering licensing and hosting options |
| CMDB design | Defines CI classes, relationships and ownership rules, and explains which classes come from discovery and which from manual or imported data | A generic list of classes with no owner, source or relationship model | Draft class model, relationship diagram, and a sample CI record with its data sources |
| Inventory deployment | Describes agent packaging, deployment method, network discovery scope, and how unknown or unmanaged assets are reported and reviewed | Says agents will be deployed without naming the platforms, deployment tool or exception handling | Deployment runbook, supported operating systems list, and a pilot report with coverage figures from the pilot |
| SLA and approval configuration | Shows how SLAs, OLAs and escalation rules map to service levels agreed with the business, and how approvals are tied to roles and change types | Describes SLAs as configurable without showing the calendar, priority matrix or approval chain | Sample SLA definitions, approval matrix, and a test case list showing expected ticket behavior |
| Migration method | Separates tickets, assets, contracts and users, sets reconciliation checks and a cutover plan with a rollback point | Promises a full data import with no mapping rules, validation or history treatment | Migration plan, field mapping workbook, reconciliation report template, and cutover checklist |
| Support scope | States what the subscription covers (vendor support, patches, upgrades, hosting, integrations) and what remains with the client or the partner | Bundles support, consulting and hosting into one unclear figure | Written support scope, responsibility matrix, and service hours and escalation path in the contract |
| Documentation and handover | Lists the configuration, runbooks, admin training and backup procedures delivered, with named owners after go-live | Offers documentation at the end without an outline or acceptance criteria | Documentation index, sample runbook, training outline, and acceptance criteria agreed before work starts |
Steps to run the ITSM partner evaluation
This sequence turns a vague search for an ITSM partner into a written, comparable set of answers, so the buyer can see who will build what, how it will be verified, and where the responsibilities end before any fixed scope is signed. Each step produces a document or check that the next step depends on.
Define the processes and CMDB classes in scope
Before contacting any partner, the buyer's service management owner lists the ITIL processes to be implemented first (typically incident, service request, change and problem) and the CMDB classes that matter to the business, such as servers, applications, network devices, user endpoints, contracts and business services. Name the owner of each class and the systems that will feed it. This step is done when the list fits on one page and the internal team agrees it. Without it, partners will quote against different assumptions and the comparison will not hold.
Send the questions in writing
Send the same written question set to every shortlisted partner, covering platform choice and reasons (GLPI or iTop), CMDB modeling and population, inventory agent deployment, SLA and approval configuration, ticket and asset migration, and what a support subscription includes. Ask each partner to answer in writing and to name the people who will do the work. This step is done when every partner has received identical questions and a response date has been agreed. Keep the questions and answers in the same document so later comparisons are easy to audit.
Confirm platform capabilities against vendor documentation
Do not accept a capability claim because a partner states it. For each feature a partner relies on, such as a specific CMDB relationship, an approval workflow, an SLA rule, an agent discovery method or a migration import path, ask for the vendor documentation page and the version it applies to, then check it yourself. Confirm supported database engines, PHP versions and hosting models against the current installation requirements for the chosen platform. This step is done when each critical capability has a documentation reference or is marked as an open question for the walkthrough.
Request a walkthrough on a sample environment
Ask each shortlisted partner to demonstrate the configuration on a sample environment built with your own process and class definitions, using anonymized or synthetic data. Ask them to show a ticket moving through an approval and an SLA clock, a CI linked to a service and an impact view, and an agent inventory record from a test device. Record what was shown, what required a workaround and what was not shown. This step is done when the buyer has notes against each in-scope process and class, signed off by the internal owner.
Compare written assumptions and exclusions
Ask each partner for a written list of assumptions (such as the number of endpoints, existing data quality, network access for agents and available integration endpoints) and exclusions (such as custom development, data cleansing, training or out-of-hours support). Put the lists side by side and resolve every difference with the partner in writing. A quote that looks lower often omits migration cleansing, testing or documentation, so the comparison must cover these items explicitly. This step is done when the assumptions and exclusions are identical in scope across the remaining partners, or the differences are priced or explained.
Check references and handover documents
Ask each remaining partner for references from comparable organizations, ideally in the same sector and with a similar scale of assets and users, and for sample handover documents such as an administration guide, a process configuration record, a backup and upgrade runbook and a support runbook. Speak with the references about the go-live period, the first upgrade and the response to incidents. Read the sample documents for completeness. This step is done when the buyer has spoken to at least one reference per partner and holds the sample documents for review. Do not treat a reference as verified until you have contacted it directly.
Agree a fixed scope in writing
Select one partner and agree the scope, deliverables, acceptance criteria and handover items in a written statement of work before any work starts. Include the platform and version, the in-scope processes and classes, the agent rollout approach, the migration sources and the support subscription terms, including what it covers and what it does not. Confirm who is responsible for the vendor license or subscription and who pays for each. This step is done when both parties have signed the scope and the acceptance criteria are measurable.
What buyers ask before hiring outside help for ITSM
The first question to answer is what drives the cost of an ITSM partner engagement, and the answer depends on scope more than on the software license. Open-source GLPI and iTop carry no license fee for the core product, so the spend goes to people: discovery of the current estate, CMDB modeling, process configuration, agent rollout, data migration, integration work and handover. The main cost drivers are the number of agents and assets, the number of integrations with monitoring and identity systems, the volume and cleanliness of tickets and assets to migrate, and how many ITIL processes (incident, request, change, problem) must be configured on day one. Ask each bidder to price these components separately so you can see which ones move when your estate is larger or messier than expected. The recurring costs are narrower and easier to compare. Teclib' publishes GLPI Network subscriptions, with public cloud at 19 euros per user per month, private cloud at 21 euros per user per month with a 25-user minimum, and self-hosted tiers from 100 euros per month (Basic, up to 10 agents and 500 assets) to 4,500 euros per month (Enterprise), according to the GLPI Network subscriptions page. For iTop, Combodo lists Community for up to 10 agents, Atelier for up to 50 agents and Forge for more than 50 agents. Confirm whether a vendor support subscription is included in a partner quote, which tier applies to your agent count, and whether the subscription covers upgrades, plugins and the level of support you need, because these terms vary and are not interchangeable. For hosting, Combodo suggests an all-in-one iTop server with 2 vCPU and 4 GB of memory for fewer than 200 tickets a month and under 20 console users, with separate web and database servers of up to 8 vCPU and 16 GB for larger installations, according to the iTop software requirements page. Ask the partner to show how they sized your environment against these figures, and whether the quote includes backups, the time to restore them and the internal effort your team must reserve for review, approvals and testing. Before you sign, confirm which of these activities your own staff can perform, such as agent deployment through your endpoint tooling and approval of CMDB classes, and which need an external specialist.
How DeployOpen scopes, delivers and supports ITSM work
DeployOpen is a Chainscore Labs company that plans, implements, customizes, integrates, hardens, documents and supports self-hosted open-source platforms inside your own infrastructure. For ITSM RFP questions, we start from a written scope that answers each evaluation question with a platform choice, a configuration plan and the evidence you would need to show a reviewer.
How we scope
- Agree in writing which ITIL processes, CMDB classes and approval paths the platform must cover before any build starts.
- Confirm the platform choice between GLPI and iTop against your hosting, database and agent constraints, with the reasons recorded.
- Define the migration sources, data volumes and cut-over approach for tickets and assets, so the quote follows from the written scope.
How we build
- Model the CMDB, SLA timers, escalation rules and approval workflows in the chosen platform to match the answers given in the RFP.
- Deploy inventory agents in a pilot group first, then document the rollout steps, exclusions and the data each agent reports.
- Test migrated tickets and assets against source records, and run data consistency checks before any cut-over is approved.
How we hand over
- Deliver configuration documentation covering the data model, SLA and approval settings, integrations and backup and update procedures.
- Provide runbooks for administrators covering agent deployment, plugin reactivation after upgrades and restore testing.
- Record the evidence your auditors or assessors will ask for, such as change approvals, incident timestamps and asset records, in a handover pack.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers, scoped separately from the initial build.
- Confirm with us which vendor subscription levels, if any, are needed for support on GLPI or iTop and which items the retainer covers.
- Review the configuration after each platform release, including security updates, before it is applied to production.
