Systems and records
CMMS work order history: keeping it when you switch systems
By SourceX Editorial · Updated
Short answer
CMMS data migration keeps work order history only if four linked record sets move together: the asset hierarchy, work orders with labor and notes, failure and cause codes, and parts consumption. Export each with its IDs, map old codes to new ones while keeping the originals, and hold an untouched archive of anything the new CMMS cannot import.
Key takeaways
- Work order history is only useful when assets, work orders, failure codes and parts usage stay linked by ID.
- Failure codes rarely map one to one between systems, so keep the original code beside the mapped one and keep technician notes.
- Fiix, UpKeep, MaintainX and Limble are cloud products, so history leaves through vendor exports, reports or APIs that can depend on plan and role.
- Import what daily work needs into the new CMMS and keep the full history in a searchable archive keyed by asset ID.
- Cancel the old subscription only after counts by asset and year reconcile between the export and the old system.
Which records make up work order history?#
Work order history in a CMMS is four record sets that only make sense together: the assets, the work orders performed on them, the codes that explain each failure and the parts consumed fixing it. Move them separately and you keep a list of jobs; move them linked and you keep the maintenance record of the plant.
The supporting sets matter too. Preventive maintenance schedules show what was planned, meter readings show how hard an asset was running, and requests show how problems were first reported.
| Record set | Key fields | What it tells you later |
|---|---|---|
| Asset hierarchy | Asset ID, parent, location, make, model, serial, criticality | Which machine, where, and how important |
| Work orders | Work order ID, asset ID, type, priority, dates, status, technician, labor hours | What was done, how fast and by whom |
| Failure, cause and remedy codes | Problem, cause and action codes plus free-text notes | Why the asset failed and what fixed it |
| Parts and inventory transactions | Part number, quantity, work order ID, cost | What each repair consumed |
| Preventive maintenance schedules | Task lists, triggers, last completion | What was planned versus what broke |
| Meter readings | Asset ID, meter type, reading, date | Usage behind each failure |
| Requests, photos and attachments | Request ID, linked work order, file names | How problems were reported and evidenced |
Why failure codes are the hardest part to move#
Failure codes are the hardest part of a CMMS migration because every system, and often every site, codes failures differently. One plant uses a short problem list, another uses separate problem, cause and remedy fields, and technicians at both write the real explanation in free-text notes.
Do not force old codes into the new list without a trace. Build a mapping table, keep the original code beside the mapped one in the archive, and keep the technician notes with every work order. Reliability analysis later depends on seeing what the technician actually wrote.
Expect gaps: closed work orders with no code at all, codes retired long ago and codes that meant different things at different sites. Document them rather than cleaning them away.
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Export routes for Fiix, UpKeep, MaintainX and Limble#
Fiix, UpKeep, MaintainX and Limble are all cloud products, so their history comes out through the vendor's own screens, reports, exports or API rather than a database you hold. Which routes you have can depend on your plan and user role, and details change, so check each vendor's current documentation and put your questions to support in writing.
Before exporting everything, run a trial on one well-documented asset family, such as the compressors or a single production line. Compare the files with what the CMMS shows on screen for a few busy assets: every work order, labor entry, part issued, note and photo. The gaps you find on that trial tell you which route to use for the full pull.
| Ask the vendor | Why it matters |
|---|---|
| Which objects can be exported, and in what format? | Work orders, assets, parts and codes may sit in separate exports |
| Do exports include closed and archived work orders across all years? | Default views often show recent or open work only |
| Are labor entries, parts used and notes included, or only headers? | History without detail loses most of its value |
| How are photos and attachments exported? | Files usually need a separate route from spreadsheets |
| Does our plan include API access, and what do the terms allow? | API exports tend to keep IDs and relationships best |
| What happens to our data after cancellation? | The contract sets how long you can still retrieve it |
Migration steps that protect history#
Protecting history in a CMMS switch is mostly a matter of sequence: freeze, export, map, import, reconcile, archive. Skipping the freeze is the classic mistake, because codes and asset IDs keep changing while the exports run.
- Freeze code lists and asset IDs in the old system before exports start.
- Export every record set with its IDs, including closed and archived work orders.
- Pull attachments and photos by work order or asset ID.
- Build mapping tables for assets, codes, parts and users, keeping the old values.
- Decide what the new CMMS imports and what stays in the archive only.
- Reconcile counts by asset and year between the export and the old system.
- Store the full export, mapping tables and a readme in company-owned storage.
- Cancel the old subscription only after reconciliation is signed off.
Illustrative: a plastics molder consolidating its CMMS#
Illustrative: a fictional custom injection molding company with several plants is moving every site onto one new CMMS. The new vendor offers to import assets and open work orders, and the maintenance lead is tempted to stop there.
The COO asks for the full history first. The exports show that one plant coded failures by problem and cause while another relied on free-text notes. The team keeps both as they are, adds a mapped code column, and links mold changeover work orders to the press asset IDs used in the new system.
The archive lets reliability engineers compare hydraulic failures on the same press models across plants. It also shows which preventive tasks were routinely deferred before breakdowns, a pattern the new system could not have revealed on its own for a long time.
What to do with history the new CMMS cannot import#
History the new CMMS cannot import should go into an archive that people can still query by asset. A reporting database or data warehouse works well, with asset IDs as the key, so a technician can look up a machine's past failures from the tag on the machine.
For the assets that matter most, add a readable asset history report in PDF. Maintenance teams reach for those during audits, warranty claims and insurance questions, and nobody needs special tools to open them.
Give the archive an owner, usually the maintenance or reliability lead, and record what it contains, which system produced it and when. An archive nobody owns tends to be deleted in the next storage cleanup.
How SourceX looks at maintenance histories#
SourceX looks at CMMS history as one of the clearest records of physical-world problem solving: an asset, a symptom, a diagnosis, the parts used and whether the fix held. Work orders with notes and failure codes rate well on domain expertise and human-generated signal under the SourceX Enterprise Data Value Framework.
Through the SourceX five-step transaction, a fit check starts with metadata only. Rights review checks CMMS vendor terms and any customer or equipment maker agreements, Preparation removes technician names and site details where needed, and the manufacturer approves each step, with a SourceX Evidence Packet recording provenance and permitted use.
Frequently asked questions
Should closed work orders be imported into the new CMMS?
Import enough to support daily work, such as recent history on critical assets, and archive the rest. Bulk-importing years of closed work often brings over broken codes and clutter. A searchable archive keyed by asset ID gives technicians the history without polluting the new system.
Do we need to migrate preventive maintenance schedules?
Yes, but rebuild them deliberately. Bring over task lists and last completion dates, then review each schedule against the failure history in your archive. A migration is a good moment to drop tasks that never prevented anything and add ones the failures point to.
Are work order photos worth the effort?
Usually. Photos show the condition of a seal, a leak or a wiring fault in a way codes cannot. Keep them linked by work order and asset ID; a folder of unlabeled images is close to useless a year after the migration.
Who owns the data in a cloud CMMS?
Your subscription agreement decides. Vendors commonly treat records you enter as your data, but terms on export, API use and retrieval after cancellation vary. Read them before you set the migration timeline, not after the renewal date has passed.
Should sensor and meter data go into the CMMS archive?
Manual and periodic meter readings belong with the CMMS history. High-frequency sensor data from historians is a separate archive with its own size decisions, so link the two through asset IDs rather than merging them.
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.