A spreadsheet of maintenance records can open without errors and still leave out a plant, a work-order status or the files behind an inspection record. Before moving data from a computerized maintenance management system (CMMS), establish what the export includes and what remains unresolved. The aim is a traceable handoff, not a claim that every machine is in good condition.

Record the export boundary before comparing counts

Start a short export note alongside the untouched files. Record the system and version, report or query name, selected sites, date range and time zone, included statuses, selected columns and export timestamp. Note whether dates refer to creation, scheduled work, completion or last modification. Those are different boundaries.

Record separate counts for assets, work orders and task lines where the system exposes them. Compare counts using the same filters and a consistent cutoff; records may change between a live count and an export. If the report limits results or requires multiple pages, account for every intended batch. A convenient file size is not evidence of completeness.

For a vendor-specific example, the IBM Maximo file-export documentation describes parameters controlling selected columns, record limits, ordering and filters. Check the documentation for your installed configuration rather than assuming another CMMS uses the same options.

This dataset check complements a broader digital operations review, but its scope is narrower. An empty result means no records were returned under the observed settings. It does not establish that no maintenance occurred.

Check identifiers before joining the files

Preserve asset tags and work-order numbers as text. A CSV can contain 00412 correctly while a spreadsheet import converts it to 412. Configure the import deliberately and inspect a sample of leading-zero, long and alphanumeric identifiers. Keep any normalized working columns separate from the original values.

Confirm which fields actually identify a record. If an asset number is unique only within a site, use both site and asset number in the match. A compound key such as PLT-A::A-101 can make that relationship easier to inspect, but it is not automatically unique: check for duplicate source keys and document how blanks and separators are handled.

Do not assume every work order has one asset or that every system stores task lines the same way. Establish the relationships in your export first. In a dataset where one asset has several work orders and each work order can have several task lines, a joined report repeats asset details legitimately. Count distinct assets and work orders separately from output rows.

A worked example with one missing reference and one missing file

The following data is entirely hypothetical. The asset file contains three keys: PLT-A::A-101, PLT-A::A-102 and PLT-B::B-201. The work-order file contains four orders: WO-501 and WO-502 reference A-101, WO-503 references A-102, and WO-504 references PLT-A::C-900, which is absent from this asset extract. There are five task lines: one each for WO-501, WO-502 and WO-504, and two for WO-503.

For this particular example, an asset-led left join to the work-order/task data produces five rows: two for A-101, two for A-102 and one null-work-order row for B-201. WO-504 is not in that output because its asset key is missing. Keep its task in a separate unmatched-record report. Combining those reports gives six reporting rows, not six assets.

The reconciliation note therefore starts with three source assets, four source work orders and five source task lines. Three work orders and four task lines match an asset; one order and one task line remain unmatched. Attachment A-17 adds a separate file-delivery exception. None of these findings is resolved by deleting a row.

Verify attachment references against the delivered files

An attachment name or URL is not the same thing as a usable file. The IBM Maximo attachment documentation distinguishes document references and metadata from attachment content; it also describes inline retrieval in supported requests. That is a specific implementation, not a rule that every export always excludes files.

Create a manifest linking each intended attachment to its source record, filename or location, and verification result. Where access is authorized, confirm files exist in the delivered package and sample that they open as expected. Identify what was sampled rather than calling an unchecked package complete. Broken links, permission-denied files and missing items should remain explicit exceptions.

If you can read the authorized source file, capture a checksum for that version and compare it with the delivered copy. Do not assume the CMMS already stores source checksums. A matching SHA-256 digest supports byte identity between the compared files; hashing only the downloaded file creates a baseline, not proof that it matches an unseen source. Neither check establishes that the document is accurate or the machine is safe.

Keep an exception register without changing the source

Preserve raw exports and record the steps used to create working copies. For each discrepancy, note the affected key, check performed, expected and observed result, reviewer, current status and resolution evidence. Retain the earlier observation when an issue is resolved instead of silently erasing it.

• Unmatched keys: Check whether the asset was excluded by site, status or date scope before treating it as absent from the original system.
• Duplicate keys: Determine whether these are duplicate source records, several revisions or an incorrect uniqueness assumption.
• Dates and statuses: Review reopened, canceled and void orders against local definitions. A completion date may legitimately be blank for unfinished work.
• Attachment exceptions: Record missing, unreadable and inaccessible files separately from successful samples.

Keep this exercise read-only. Do not overwrite production records, import corrected guesses or disable access controls to make an export easier. The existing guidance on client-access ownership and continuity addresses the separate question of who can legitimately access systems during a handoff. Permission to read a file and evidence that it was transferred are not interchangeable.

Keep data verification separate from equipment condition and value

These checks can establish whether a specified export reconciles to its recorded scope, with known exceptions. They cannot certify all historical maintenance, validate an inspection’s conclusions or establish equipment condition. Even a perfectly matched dataset can contain incorrect source entries.

For an Indiana manufacturing owner preparing for a sale, maintenance evidence is one part of a wider operational review. The manufacturing-owner sale-preparation guide discusses that broader preparation. All Digital Update and Midwest Business Brokers share a publishing network; this is an affiliated resource, not an independent endorsement. A completed data check is not an appraisal, a legal finding or a promised sale price.

Common export questions

What should happen to a work order with no matching asset?

Keep it in the unmatched-record report. Investigate the key, filters and original record through authorized access. Record the explanation when supported; until then, mark the cause unresolved. Do not assign an asset merely to make the totals agree.

Why can file counts differ from spreadsheet rows?

Check query filters, batching, import settings and join behavior first. Properly quoted CSV fields can contain line breaks, so counting physical text lines is not a reliable record count. Use a parser configured for the export format, and distinguish parsed records from joined report rows. If a tool reports a size or row-limit warning, investigate it rather than assuming all records loaded.

Final handoff checklist

• Save the export scope, timestamp, status definitions and source counts.
• Preserve identifiers and untouched source files.
• Reconcile asset, work-order and task counts separately.
• Explain join expansion and retain unmatched records.
• Deliver an attachment manifest with honest sampling and access results.
• List unresolved exceptions, responsible reviewers and next checks.
• Keep production changes and import acceptance outside this read-only verification.