Spreadsheet to CMMS: An Asset Import Checklist That Preserves Useful Data

Protect the source and choose the starting records

Keep an unchanged copy of the source files and record when they were taken. Identify the person responsible for deciding which records are authoritative. If several spreadsheets describe the same equipment, reconcile them before importing rather than hoping the destination will identify the intended version.

Separate active assets, active recurring work, parts, open jobs, and historical records. They may require different import templates or a deliberate archive strategy. Do not assume that one asset upload can also carry every attachment, prior work order, and inventory transaction.

Create a field-mapping sheet

For each source column, record the destination field, whether it is required, its format, and any transformation. Include stable asset identifiers, names, location, parent asset, model, serial number when relevant, and status. Treat units, date formats, leading zeros, and time zones as explicit decisions.

In a hypothetical building portfolio, the identifier B02-AHU-014 could distinguish one air-handling unit from similarly named equipment elsewhere. The format itself is not a universal standard; its usefulness comes from being unique, stable, and consistently used. Do not rely on a display name alone when it can change.

• Source column and destination field.
• Record owner and accepted values.
• Transformation rule and example.
• Required relationship or reference.
• Validation method after import.

Clean relationships as well as individual cells

Check duplicate identifiers, missing required values, inconsistent location names, and references to assets that do not exist. Agree on the hierarchy before migration. A parent-child relationship should describe the intended equipment structure rather than reproduce arbitrary spreadsheet indentation.

Keep a correction log instead of silently replacing uncertain information. A blank model number and a guessed model number are not equivalent. Preserve uncertainty in an appropriate field or issue list so someone can resolve it. Verify any controlled values against the actual import template.

Run a deliberately varied sample import

Choose a small sample that includes ordinary records and likely edge cases: a child asset, a long description, a leading-zero identifier, an optional blank, and a historical date. Import into the approved test area using the vendor's current template. Review the result in the application, not just in the import report.

Check whether the operation creates, updates, or duplicates records when rerun. Record the matching key and the recovery process before a larger upload. Where the vendor supports undoing an import, test the exact conditions; do not assume that a bulk import can always be reversed automatically.

Validate and document the changeover

Compare record counts, identifiers, hierarchy, dates, and sample field values between the source and destination. Check representative asset histories and attachments separately. Open any exported result in a readable format and confirm that relationships can be understood without the application's interface.

At changeover, identify which system receives new records and how changes made during migration will be handled. Retain the mapping sheet, corrections, import reports, exception log, and acceptance evidence. These artifacts make future troubleshooting and another migration easier.

If import capability affects your shortlist, compare the exact supported objects and plan limits. Request shortlist help with your current file types, approximate record groups, and the history you need to preserve.