CMMS Data Migration: The Step That Decides Whether Your New System Survives

When a CMMS implementation fails — and roughly seven in ten do, by the honest estimates — the software is rarely the cause. The cause is almost always the same: the data that got loaded into it. A new system running on dirty asset records, duplicated parts, and half-copied work-order history is just an expensive way to make worse decisions faster.

Data migration is the least glamorous and highest-stakes phase of any CMMS switch. Get it right and the new system starts useful on day one. Get it wrong and the maintenance team loses faith in the data within a month — and once that trust is gone, they are back on spreadsheets and WhatsApp inside a quarter, regardless of what the software can do.

Here is how to do it without that outcome.

Start From the Decision, Not the Data

Before touching a single record, decide what the CMMS actually has to do well on day one and what can wait. The migration scope follows from that. For most plants the day-one-critical data is, in order:

1. The asset register — every machine, its hierarchy (site → area → line → machine → component), criticality rating, and a clean naming convention. Without this, nothing else has a home.
2. The spare-parts register — every part, de-duplicated, with part number, description, manufacturer, min-max levels, and bin locations.
3. The bill of materials — which parts go on which asset. The link between assets and parts.
4. Open and in-progress work orders — anything not yet closed that the new system needs to carry.
5. PM schedules — the recurring preventive-maintenance templates that will auto-generate future work orders.

Everything else — closed work-order history, old purchase orders, legacy reports — is negotiable. Resist the urge to migrate everything "just in case." A migration that tries to move a decade of dirty history takes three times as long, costs three times as much, and ships a new system that feels exactly as cluttered as the old one.

The Asset Register: Where Most of the Value Is

This is the foundation, and it is almost always the messiest data in the building. Typical state of a legacy asset register: three different naming conventions used over the years, identical machines with different names, retired assets never removed, criticality either blank or set to "high" for everything, and a hierarchy that exists in one maintenance supervisor's head but nowhere in the data.

Cleanup is non-negotiable and is where the real work happens:

• Pick one naming convention and enforce it. Something like site-area-assettype-serial. Apply it to every record. (We wrote a whole piece on canonical spare-part naming; the same discipline applies to assets.)
• Build the hierarchy. Asset → parent asset, down to the component level where work orders are actually raised. A flat list of 3,000 assets is unusable; a five-level hierarchy of the same 3,000 is gold.
• Remove the dead. Retired, scrapped, and "we think it's in storage" assets get archived, not migrated. Carrying them pollutes every report forever.
• Deduplicate. Two records for the same pump collapse into one. Same for "Pump A," "PMP-001," and "the feed pump."
• Assign criticality honestly. Use the equipment criticality matrix. If everything is critical, nothing is.

Do this before migration, not after. Cleaning the asset register inside the live new system, while technicians are trying to raise work orders against it, is how data quality goes backwards.

The Parts Register and BOM: The Hidden Time Sink

Parts data is usually worse than asset data. The same seal bought under three supplier part numbers. Descriptions that say "BEARING" and nothing else. Min-max levels set to whatever someone typed in 2017 and never revisited. Bin locations that say "Shelf 2." Obsolete parts still on the books at full value.

The cleanup:

• Deduplicate by part number and by description. Same part under multiple SKUs collapses to one canonical SKU.
• Write descriptions a human can read. "SKF 6205-2RS DEEP GROOVE BALL BEARING," not "BEARING 6205." A technician searching the parts register at 2 a.m. needs the description to find the right thing.
• Purge obsolete stock. Parts with no movement in two years and no asset referencing them get flagged for disposal, not carried forward.
• Fix min-max levels. A min of 1 and max of 100 on a part that consumes at 2 per year is a shelf full of frozen cash.
• Build the BOM links. Which parts fit which assets. This is what makes a work order able to auto-reserve the right spare. Without BOM links, the parts register is a list; with them, it is a system.

This is tedious, unglamorous work. It is also the difference between a CMMS that finds parts in seconds and one where technicians phone the storeman.

Work-Order History: Migrate or Start Fresh?

The temptation is to migrate every closed work order for the last five years, so that MTBF and cost-per-asset reports have history from day one. The risk is that you also migrate the old system's data-quality sins: work orders with no asset, no labour hours, wrong status, free-text descriptions that can never be aggregated.

Three options, in increasing order of effort:

• Migrate nothing. Start the new system's history from go-live. Cleanest data, fastest migration, but reports take 6-12 months to become meaningful.
• Migrate summary history. Aggregate closed work orders into asset-level rollups (total count, total cost, MTBF) and load those as starting values. Reports are usable immediately; detail is lost.
• Migrate full history. Cleanest reports over time, but requires cleaning every legacy record — the slowest, most expensive path, and only worth it if the legacy data is good enough to be worth cleaning.

For most plants, summary history is the right trade. The fantasy of "we will clean all five years of history" is how migrations stall for eighteen months and then ship a half-cleaned dataset anyway.

The Phased Cutover

Big-bang cutovers — flip the switch on every site, every asset, every Monday morning — are the highest-risk way to go live. The alternative that actually works:

1. Pilot on one site or one line. Migrate that scope, run parallel (old system and new) for two to four weeks, validate that work orders, parts issues, and PM generation all behave correctly.
2. Fix what breaks. Every discrepancy found in pilot is a migration bug. Better to find them on one line than across the plant.
3. Roll out in waves. Site by site, or area by area, on a schedule that lets the implementation team keep up. Each wave is smaller, faster, and recoverable.
4. Decommission the old system only after the last wave is stable. Not the day after go-live. After a defined stability period.

Parallel running is expensive in effort but cheap in risk. The plants that skip it are the ones telling go-live war stories six months later.

Validation and the Parallel Run

During the parallel run, check three things every week:

• Asset and parts counts reconcile between old and new — same number of active assets, same parts value, no orphans.
• A day's work orders raised in the new system match what would have been raised in the old one — same assets, same PM triggers firing on schedule.
• Reports tie out. The new system's backlog count and cost-per-asset roughly match the old system's, within expected rounding. Big gaps mean a migration mapping is wrong.

If any of these drift, stop the wave and fix it before expanding. Drift compounds.

How OpexMX Handles It

OpexMX ships with a structured migration path: templates for the asset, parts, and BOM imports; a deduplication pass that flags likely duplicates for review rather than auto-merging; criticality-scoring built into the asset loader; and a parallel-run checklist that ties the new system's counts to the old one before any wave is expanded. The implementation team runs the first site with you, validates the reconciliation, and only then hands over the templates for the internal team to drive the remaining waves. The goal is a day-one-clean register, not a "we will fix it later" dataset that never gets fixed.

Planning a CMMS switch? We will scope your migration and run the first site with you →