How do you import COBie data into a CAFM or CMMS system?

Selecting a file and pressing "import" rarely produces a usable maintenance system. A successful COBie import rests on an agreed mapping between the delivered information and the receiving system's own data model, a controlled trial, a plan for records that already exist, and a decision about what happens to data that does not fit. Before handover, the owner needs to have decided how assets, locations, classifications and documents will be represented in its CAFM or CMMS.

Keep the file standard

NIBS, which maintains COBie, states plainly that custom data fields may not be added to its tables, and explains why. Because COBie is a standard schema, asset-management systems can carry pre-built mappings that import a standard deliverable without customisation, and extra columns break that. Additional properties belong in the Attribute table instead. For owners, the lesson is to keep deliverables standard and put project-specific requirements where the import tools expect to find them.

Get the destination ready

The version is the first thing to check. The receiving system may support a particular COBie version and format, and version 3 renamed and removed some tables and fields (the "Floor" table became "Level", for example), so a version 3 deliverable going into a tool built for version 2.4 may need a conversion step.

Next comes the field mapping: a written record of how each COBie field maps to a destination field, including any transformations such as concatenating names, converting units or translating classification codes. Alongside it sits the hierarchy mapping, which decides how COBie's facility, level and space structure, and its systems, will appear in the destination's location and asset hierarchy.

Some things will not fit neatly. Where a relationship cannot be represented directly, such as a component that belongs to several systems, the team should agree a usable alternative instead of letting the import drop it silently. Finally, identity rules settle which field becomes the asset's permanent identifier and how it will be matched against records already in the system.

Trial in a test environment

A representative subset should be imported into a test environment, never the live system, and checked against the following:

Every rejection or transformation should be recorded. Corrections belong in the authoritative handover data as well as in the destination system; otherwise the next import, or the next project, repeats the problem.

The live import then needs its own plan: the sequence, a rollback point, and how exceptions will be handled on the day. It should also be clear whether later updates, such as commissioning results and late serial numbers, will be imported as changes or entered by hand.

Work that falls between two contracts

Import work sits between the construction contract and the software contract, and is often in neither. It needs allocating explicitly:

Where the maintenance system is procured after the construction contract, make sure someone has been appointed, and paid, to do this work before handover.