Origins – IT documentation as structured data
i-doit emerged from the need to turn IT documentation into structured, queryable data. Rather than relying on free‑form notes, the tool emphasized a CMDB model where assets, services, and relationships are tracked in a consistent way. This approach made documentation more reliable for day‑to‑day operations, because teams could reference a structured source of truth instead of scattered wiki pages or spreadsheets.
Early adoption – Asset and relationship mapping
As i-doit matured, its strength became the ability to map relationships between hardware, software, and services. That capability is vital in CMDB usage: it lets operators see how systems connect and which dependencies exist between assets. This made it useful not only for documentation but also for understanding the impact of changes or failures. Early adopters used it to maintain inventories, record physical assets, and document service dependencies.
Web-based management – A central UI for documentation
A key milestone in i-doit’s evolution was the development of a robust web UI that allowed teams to document systems collaboratively. This central interface made it easier to update asset records, track lifecycle status, and maintain accurate documentation across teams. The web UI also allowed i-doit to serve as a shared knowledge base for infrastructure, helping bridge the gap between operations, service management, and documentation workflows.
Integration with ITSM practices
As CMDB tools became more integrated into IT service management workflows, i-doit positioned itself as a complementary platform. Teams used i-doit alongside ITSM processes such as change management, incident tracking, and asset lifecycle management. The CMDB data provided context for ITSM tasks, improving visibility into how changes affected downstream systems and helping reduce operational risk.
Deployment flexibility – Self-hosted architecture
i-doit is designed for self-hosting, typically deployed on standard web infrastructure. This meant organizations could host the system in their own environment, align it with internal security policies, and control the data lifecycle. The ability to deploy on common web stacks also reduced barriers for adoption, since many IT teams already managed web servers, PHP runtimes, and database systems.
Community and editions – Differentiation over time
Over time, i-doit offered multiple editions to serve different needs. The Community Edition allowed open-source adoption and community contributions, while commercial editions introduced additional features for larger organizations. This model helped sustain ongoing development while keeping a self-hosted path available for organizations that prioritized transparency and internal control.
Operational maturity – CMDB as a governance tool
As organizations relied more heavily on CMDB data, i-doit’s role in governance became more important. Accurate asset relationships, lifecycle states, and ownership details became central to compliance and audit workflows. i-doit’s focus on documentation quality and structured records helped teams improve consistency and reduce errors when managing large inventories of assets and services.
Today – A focused CMDB and documentation platform
Today, i-doit is best understood as a dedicated IT documentation and CMDB platform. It continues to serve organizations that need structured asset data and dependency mapping. Its history reflects a typical CMDB evolution: start with documentation, extend into structured relationships, and become a shared foundation for operations and governance. For teams that prioritize internal ownership of documentation and asset data, i-doit remains a practical and widely used option.