Skip to main content - The eBook-Shop with Checklists and Templates for Professionals
logo Template Operating Manual
Skip main navigation
Template Operations ManualData Migration ChecklistNonfunctional RequirementsApplication Interface (EAI) Checklist Server Upgrade / Migration ChecklistApplication Upgrade / Migration ChecklistApplication & Server Inventory TemplateRelease ChecklistOutage PlanningApplication RetirementApplication Health checkArchiving RequirementsDisaster Recovery (DR) Technology SelectionBackup OLA / SLADatabase OLA / SLADBA Job DescriptionDatabase Health CheckStandby Database
The author of this template bears following credentials:
OCP 10g Logo
OCP 10g Logo
Logo ITIL green
Application SupportData MigrationOLA / SLA Operations Level AgreementSystem DocumentationProject ManagementQuality AssuranceCompliance and StandardsDatabase AdministrationStart-up PhaseAchieving Operational ReadinessStabilized Operations

Application & Server Inventory Template


This document assists in first step of gathering and classifying information about servers, applications and software.
It is simple and you will achieve usable results within a few days of active asking and searching.
It is indeed very important to have the list of all applications and servers, as those lists are needed for multiple purposes:
In addition to (nearly) static system documentations you do need to produce "records" - evidence that required activities have been executed.
  • Document last Restore- and Recovery Test for each system
  • Quarterly or yearly review of Support Contracts
  • Capacity Planning -
  • Last Review of the Operations Manual
Just copy the list (without all attributes) and fill in date, result and the link to document showing evidence (and required follow-up actions) for each server or application, and save it as static document.
Without having a central complete list of all servers and applications it is just not possible to document that restore tests or capacity planning for all systems have been executed and that ALL systems do have a person responsible for IS/IT aspects assigned.

Example Usage of this Template

This template was used to document a small IT department with 70 applications, 40 databases, 50 units of hardware and 35 different software licenses. This was achieved within 3 days by one consultant experienced in IT Operations.
Customer's staff effort:
1 Day - Data Centre Staff: Customer's Data Centre administrator checked in the data centre each piece of hardware, and the consultant immediately entered those data into the spreadsheet (including Rack-ID and position within the rack). If not knowing out of mind what's running on that server, customers administrator logged in to that server and checked what's running.
1 Day Interviews with different administrators responsible for different applications.


The structured information in different work sheets, linked by unique ID's provides different views:
  • Who is owner in business and who is responsible in IT for each application
  • Which applications are affected if database (x)or server (y) fails?
  • Which servers are not utilized (don't show any application or database) ?

Worksheet: "1_Application_List_and_Environment_Mapping": Application Meta-Data and Environment Mapping

  • List of all applications and attributes on application level.
  • Mapping of Application-Environments to Servers.

Worksheet "2_DHS_Hardware": DHS - Definitive Hardware Store

  • List of hardware with classification attributes, location information and mapping to applications.
  • Information about Vendor's Hardware Support Contracts and Support Hours

Worksheet: "3_DSL_Definitive_Software_Library"

List of all Software including tools with Version Information, License related information and where this software is stored.

Worksheet "4_Interfaces"

A list of all interfaces providing a unique ID for each interface, and which applications are connected.

Frequently Asked Questions (FAQ)

Question: We are intending to implement a CMDB, why should I use this template?

This template does not replace a database-based CMDB (Configuration Management Database), but it will help to bridge the time until the implementation including configuration / customization of such a CMDB is finished.
And already selecting a CMDB application suitable for you and defining the requirements will be a serious task!
The more you know about your meta data, the more successful and faster you will manage this future project!
If you do the simple step of documenting your applications and servers using this template first, your future CMDB-project will benefit from this activity.
  • You "learn" a lot about your application meta data
  • You learn which attributes you will need in your future CMDB. (Usually missing attributes or even missing functionality are identified during keying in the data, after the CMDB vendor's configuration consultant left and project and budget are closed.)
  • You will most likely like the mapping between Applications and Servers, detailed for Development, Test and Production Environments and you will not forget this functionality as requirement for the future CMDB.
  • When starting the CMDB project you will be in the position of a demanding customer who knows what he needs.
And until that (CMDB-project) will be completed, you do have something to use!
The additional effort for keying data again into new CMDB is negligible compared to the effort and time duration to collect those data and the benefit of faster and complete configuration of your CMDB.

Question: Should we list small applications developed by individuals themselves (without IS/IT involvement) and used by only a few persons?

Answer: Ask yourself the question: What is the impact if this application would stop to work?
If there is impact, e.g. just that the manual workaround requires more time (which will result in additional costs or work not done), then it must be listed.
Such applications need to comply to general rules (Testing, Backup, Restore-Tests, system documentation, ....)

Question: Should we list applications running on desktops and not on servers in the data centre?

Answer: Definitely! - See previous answer. One important purpose of having a COMPLETE list is to identify if they are managed according at least to good practice.

Question: Should we list Free ware / Open Source Software in the Software-List?

Answer: Definitely!
  • There needs to exist a person who is responsible to read regularly bug and security information published.
  • If security alerts are published, someone needs to be able to identify which systems might be affected.
  • The license conditions need to be reviewed regularly (best by legal department) - Sometimes companies who produced open source software are purchased by other commercial companies which terminates the old agreements.