How to Migrate CMMS Data Without Losing Your History

How to Migrate CMMS Data Without Losing Your History

Nobody stays on a CMMS they hate because they love it. They stay because the data is in there. Six years of work orders, the PM schedules someone spent a month building, the LOLER certificates attached to the right cranes. Moving all of that feels like a project with a hundred ways to go wrong, so the switch never happens and the team keeps paying for a system the technicians ignore.

Migration is a real project, but a small one. A single site with a couple of thousand assets and a decade of history is usually two to three weeks of elapsed time, most of it waiting on people rather than machines. This guide is the process I use when we migrate customers for them, written so you can run it yourself or know what to ask a vendor to do.

Six phases. Do them in order.

Want it as a working document? The Excel version has the full migration plan, a field-mapping template with 45 target fields already listed, and a reconciliation sheet for the staging check:

Phase 1: Inventory (what exists, not what's tidy)

The first mistake is starting in the old CMMS. Maintenance data never lives in one place. It lives in the CMMS, two spreadsheets that outgrew it, an Access database from 2011, a SharePoint list for the fire extinguishers, and a WhatsApp group where the real job requests arrive.

List every source. Then export everything from each one exactly as it is. CSV or Excel is fine. A database backup is fine. Do not clean anything yet, because you don't know what matters until you've seen it all.

Count what you have per source: assets, open work orders, closed work orders, PM schedules, parts, documents. These counts become your reconciliation baseline in Phase 4. Without them you can't prove nothing was lost.

Decide your history cut-off now. Most teams migrate the last 12 to 24 months of closed work orders and leave older ones in an archived export. Two exceptions: statutory inspection records (keep all of them, auditors ask), and the full history of any asset that's critical or under warranty dispute. Five years of "replaced bulb in corridor" adds nothing.

Phase 2: Map (source column → target field)

Every CMMS stores roughly the same things under different names. Your old system's "Equipment Tag" is the new system's "Asset ID". "Area" might be "Location". "Job type" might be "Work order type" with a different picklist.

Field mapping is one row per source column: where it comes from, where it goes, and what transformation happens on the way. The template in the download lists the target fields a modern CMMS expects across assets, work orders, PM schedules, parts and documents. Your job is to fill in the source column against each one.

Three kinds of row need a decision rather than a mapping:

• Source column with no target. The "Cost centre (old)" field nobody has updated since 2019. Drop it, merge it into a notes field, or create a custom field. Default to drop. You can always go back to the archived export.
• Target field with no source. Criticality, for instance, when nobody ever rated assets. Leave it blank and collect it during the pilot, or derive it from a rule (everything on Line 3 is High).
• The asset ID convention. Pick a scheme like SITE-CATEGORY-NNN, apply it to every asset, and keep the old ID in a "Legacy ID" field so the label already stuck on the machine still resolves to something. Get this wrong and every QR code on site points at nothing. If you're consolidating spreadsheets, the spreadsheet migration guide covers the naming patterns.

Phase 3: Clean (the part that decides whether the team trusts it)

A migrated system with 400 half-named duplicate assets fails on day one, because the first technician who searches for "pump" gets six results and goes back to the spreadsheet. Cleaning is what makes the new system believable.

Work through it in this order:

1. De-duplicate assets. The same compressor under two names, or the same ID used on two sites. Merge and keep the history against the survivor.
2. Normalise locations into one hierarchy. Site, then building or area, then room or line. "Bldg 2 / L3", "Building 2 Line 3" and "B2-L3" are one location.
3. Normalise picklists. Categories, priorities and statuses have to match the target system's lists exactly. Map "Urgent", "URGENT" and "P1!!" to one value.
4. Fix dates. One format, one timezone. Two-digit years and American versus British day-month order cause the worst silent errors: a PM due on 03/04 lands in the wrong month and nobody notices until it's overdue.
5. Resolve orphans. Work orders pointing at an asset that no longer exists. Either re-point them to the right asset or attach them to a "Disposed" placeholder so the history survives.

Resist the urge to clean everything. Clean what go-live needs: the fields in your mapping sheet, for the assets in scope. The rest can be tidied after the team is using the system.

Phase 4: Stage (import into a sandbox, then prove it)

Never import straight into production. Every CMMS worth switching to gives you a staging workspace or a sandbox. Import there first.

Then reconcile. Source count versus staged count, per entity. The numbers won't match, and that's fine as long as every gap has a written reason: duplicates removed, outside the history cut-off, orphaned and re-pointed. A gap with no reason is data you lost. The reconciliation sheet in the download is a table for exactly this.

Reconciliation proves the counts. It doesn't prove the content. So spot-check 20 assets end to end: fields, location, attachments, full work order history, next PM date. Pick them across sites and categories, and include the ugly ones.

Finish staging with the technician test. Give two technicians the new system and ask them to find their last five jobs without help. If they can, your naming and locations work. If they can't, go back to Phase 3.

Phase 5: Cut over (a date, not a feeling)

Set a cut-over date and tell everyone a week ahead. On that date the old system becomes read-only. Not switched off, read-only, so anyone who needs an old record can still look, but nothing new can go in.

The staging import is now days or weeks old, so run a delta load: re-export anything that changed since the staging export (new work orders, closed jobs, edited assets) and import just those. This is why staging in a sandbox matters: you've already proved the mapping works, so the delta is a small, low-risk repeat.

Re-point everything that touches the old system. QR labels and barcodes on machines need to resolve to the new asset record. Integrations, shared links in procedures, the bookmark on the workshop PC.

Keep the old system read-only for 90 days. Then take a final full export, archive it somewhere boring, and cancel the licence.

Phase 6: Verify (three checks in the first month)

Three checks in the first month tell you whether the migration took:

• Week 1: every real work order goes into the new system. No parallel spreadsheet, no "just for now". As long as the old place stays live, it stays authoritative.
• Week 2: review the first PM cycle. Did the right jobs fire on the right assets on the right dates? A wrong "last done" date in Phase 2 shows up here as a PM that's either overdue on day one or silently pushed a year out.
• Day 30: pull one audit-style report, say every statutory inspection due next quarter, and check it against the old system. If it matches, the compliance data survived and you can stop worrying.

Where migrations fail

Four failure modes account for nearly every bad migration I've seen:

Skipping the inventory. The old CMMS gets migrated beautifully and the spreadsheet that actually ran the site is discovered in week three.

Cleaning in production. Dirty data imported live, cleaned "as we go". The team's first impression is chaos, and first impressions decide adoption.

No reconciliation. Nobody counted, so nobody noticed the 340 work orders the export truncated. The gap surfaces during an audit.

Eternal parallel run. Old and new both live, waiting for confidence. Confidence never comes, because the old system keeps being where the real answers live.

If you're changing systems rather than just moving data, the CMMS selection guide covers evaluation, and the implementation checklist covers the six weeks after the migration. For larger operations, the safest sequence is to pilot one site first and migrate the rest once the pilot has proved the mapping. And if Phases 2 to 4 are the part putting you off, that's the part we do for you: mapping, cleaning, staging and reconciliation are included free with any annual plan, whether you're coming from SysAid, Fiix, UpKeep, Limble, MaintainX, Maintenance Connection, Access, SharePoint or a spreadsheet.

Shane Price

AssetOS

Writing about maintenance management, CMMS implementation, and the real challenges operations teams face.