iTop: a CMDB-first ITSM where the data model is the product

CMDB first, helpdesk second

iTop stands for IT Operations Portal, and the order of the words matters for how the product is built. It is described as a complete open source and web-based IT service management platform, and the piece that anchors it is a fully customizable CMDB. The rest of the feature list hangs off that: HelpDesk and incident management, service and contract management, change management, configurable SLA management, graphical impact analysis, a CSV import tool for any data, a consistency audit to check data quality, and data synchronization for data federation. The word ITIL compliant in the description explains the shape of the object model, because a service desk that follows ITIL has contracts, SLAs, changes and incidents as first class things rather than as fields on a ticket. The audience is an IT department or service provider that manages a catalogue of infrastructure. A single developer looking for a ticket form does not need this product.

The repository layout is the architecture

The tree explains the design better than the feature list does. There is a datamodels/ directory, which is where the object model lives, and core/ which holds the framework, with application/ for the business layer, pages/ for the web UI, templates/ and css/ and js/ for presentation, and portal/ for the end-user self-service area. There are separate directories for the concerns a CMDB platform has to keep apart: synchro/ for the data synchronization the documentation calls data federation, webservices/ for the integration API, validation/ for consistency checks, extensions/ for the extension mechanism, and addons/ for bundled or third-party add-ons. Dictionaries/ holds the translations, log/ the audit trail, conf/ the configuration, and lib/ the shared libraries. The build lives in .make/, which holds the dependency tooling, and the tree also carries a Jenkinsfile for continuous integration, a composer.json and composer.lock for the PHP dependencies, a package.json for the front end, and a web.config for the IIS deployment path. This is a classic PHP monolith with a strong separation between the data model and everything that draws a screen.

Extensions and the packaged dependency stack

The project is described as easily customizable and extensible thanks to a high number of add-ons and web services, and the ecosystem has a distribution point of its own: iTop Hub is the store where you discover and install extensions. The tree confirms the mechanism is first class rather than a plugin bolted on afterwards, with a dedicated extensions/ directory and a composer.readme for the packaged dependencies. The front-end stack is visible in package.json, and it is worth looking at because it dates the project. The build is a mix of Bulma for layout, jQuery with jquery-ui and jquery-migrate, DataTables with several plug-ins for the grids, Selectize and Tom Select for inputs, Tippy and Toastify for interface feedback, CKEditor5 through a custom Combodo build for rich text, D3 and C3 for the charts, Ace for code editing, and Popper and Turbo for interaction. The two npm scripts, postinstall and postupdate, both call rmUnnecessaryFolders.php and then restoreFolderBrowsingProtection.php, which is a detail that tells you the front end is compiled into the PHP tree rather than served separately.

The audit and the import tool are what make a CMDB usable

Every CMDB degrades, and the interesting question is which features help you keep one. iTop answers with a consistency audit to check data quality and a CSV import tool for any data, plus mass import tools described in the introduction as a way to become more efficient. In practice this pairing is what separates iTop from a ticketing system with an asset table bolted on. The import path is how a domain gets populated in the first place, because nobody types in two thousand servers, and the audit path is how the result stays honest, because imported data is wrong in ways nobody notices until an impact analysis depends on it. The consistency checks also sit inside the validation/ directory in the tree, which suggests the rules are part of the model rather than a report you run by hand. Graphical impact analysis is the payoff: if a server or an application is linked to the services that depend on it, you can see the blast radius of a change before you approve it, and that only works if the data is both complete and trustworthy.

Installation, upgrades and where the documentation actually lives

The installation story is deliberately not in the README. Installation notes, requirements and the change log all live in the iTop Hub wiki, and the download is the GitHub release page, with the latest release listed as 3.3.0 from 2026-09-15. The repository itself is the source of truth for a self-hosted install: there is a setup/ directory, an install.txt and a readme.txt, a bootstrap.inc.php and an approot.inc.php at the root, an index.php entry point and a tests/ directory. The project also ships a versions history in .doc/itop-version-history.md, and developer documentation in .doc/developers.md, which is where the quality tools and how to run them are described. One structural fact deserves attention: the default branch is develop, with 3.3.0-beta1 published from it in July 2026. That means the branch head is where work in progress lives, and an installation should track a tagged release, not the default branch, or you are running code that has not been versioned.

The AGPL-3.0 licence is the constraint that shapes deployments

The repository is licensed under AGPL-3.0, and the file is license.txt at the root. For an internal IT tool that most organisations run unchanged, the practical question is usually whether modifying it and offering the modified service to users triggers the source disclosure obligation, which is a question for whoever handles that in your organisation rather than for this review. What is worth saying plainly is that the licence and the extension model interact. Because the product is designed to be extended through iTop Hub add-ons and the extension directory rather than by forking the core, there is a maintained path for the customisations most IT teams need, and a fork is not the default way to work. Combodo sponsors, leads and supports the development, which is the reason a commercial vendor backs an AGPL project, and iTop Hub is the distribution point for extensions, so a team should look at the extension catalogue before assuming it must build everything itself.

Helpdesk-first tools and CMDB-first tools solve different problems

The alternative is the other common ITSM starting point: a ticket system that treats requests, users and maybe assets as a support queue, with the inventory living in a spreadsheet or a separate asset tool. The difference in approach shows up the moment something goes wrong. In a helpdesk-first system, an incident is a record with a category, a priority and a resolution, and a support agent looks up the affected server manually. In a CMDB-first system such as iTop, the server is an object with a class, a set of attributes, relations to the services that use it, and links to the contract that covers it, so the impact analysis draws a graph instead of a list, the SLA is attached to the service rather than re-entered per ticket, and a change can be checked against the affected estate before approval. The cost of the CMDB-first approach is the modelling work up front, because that graph has to be built and kept current, and iTop's audit, import and synchronisation features exist precisely to absorb that cost. If your team has no shared inventory to model, the graph has nothing to draw and the simpler route is the right one.

Editorial conclusion

Adopt iTop if your IT organisation has a real estate of servers, applications and services that the helpdesk should know about, and you are willing to model that estate before migrating tickets into it. Do not adopt it as a lightweight ticket queue, since the CMDB and the class-based data model are the point rather than an optional module, and a team that only wants a mailbox will carry that cost. Before you evaluate, read license.txt, because the AGPL-3.0 terms reach into modified deployments, check the requirements page on itophub for the database and PHP versions your install needs, and note that the default branch is develop, so production tracks the tagged releases rather than the branch head.

Frequently asked questions

Official sources

1. Combodo/iTop on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases