Can we migrate off our old CMMS without losing work-order history?

Yes. The history lives in the data, not the software. As long as the records can be exported — even from a database with no modern export, a stack of spreadsheets, or scanned paper — the work orders, asset histories, and PM schedules can be pulled out, cleaned, and mapped into a new system. The decades of knowledge come with you.

What if our system has no export or API?

Older systems often don't. The data can usually still be reached directly in the underlying database, through reports, or — for paper and scanned binders — by extracting the records into structured form. A missing export button is a slowdown, not a dead end.

How do you handle messy or inconsistent asset data?

Carefully, and with a person checking the result. Inconsistent asset names, duplicate records, and gaps are the norm in a 20-year-old system. The migration includes cleaning and de-duplicating the data and mapping it to a consistent asset hierarchy — and you review the result before it becomes your new system of record.

Will we have to run both systems at once?

Usually for a short, deliberate overlap. A parallel run lets you confirm the new system holds the right history and that PMs fire correctly before you retire the old one. The goal is a clean cutover you trust, not a leap of faith.

Moving off a legacy CMMS without losing 20 years of work-order history

Somewhere in most facilities is a maintenance system that everyone has quietly given up on. Maybe it's a CMMS that was modern when it was installed — Maximo, MP2, Mainsaver, Maintenance Connection — and has since calcified into something nobody wants to touch. Maybe it was never really a system at all: a tab-per-asset spreadsheet, an Access database one person built and then retired, a filing cabinet of work orders and binders of equipment manuals.

Either way, the same thing keeps it in place: the history. Twenty years of work orders, the asset records, the PM schedules, the notes a technician left in 2014 that explain why a pump is plumbed the way it is. Moving off the old system means moving all of that — and the fear of losing it is exactly why the move never happens. So the workarounds pile up instead.

It doesn't have to be that way. Replacing a maintenance system is mostly a data problem, and data problems are solvable. Here's how to think about it.

The history lives in the data, not the software

The single most useful thing to understand is that your decades of knowledge are not trapped in the application. They're in the records underneath it — and records can be moved.

That's true even when it doesn't feel true:

No export button? Older systems often have none. But the data is almost always reachable directly in the underlying database (SQL Server, Oracle, even an old Access or FoxPro file), or through the system's own reports.
Spreadsheets and binders? A patchwork of spreadsheets is just data in an awkward shape. Scanned documents and paper work orders can be extracted into structured records — tedious, but entirely doable.
A proprietary format that "won't budge"? Attachments and manuals stored as blobs inside the database can usually be pulled out and re-linked to the right asset.

A missing export path is a slowdown, not a dead end. It changes how long the migration takes, not whether it's possible.

What actually has to come across

Not everything in an old CMMS is worth keeping, and trying to move all of it verbatim is how migrations stall. It helps to be deliberate about the records that carry real value:

The asset register — every piece of equipment, its location, and where it sits in the hierarchy (site → area → line → unit → component).
Work-order history — what failed, what was done, by whom, and when. This is the record that makes failure analysis and budgeting possible later.
PM schedules and their triggers — time-based and meter-based preventive maintenance, including the meter readings the triggers depend on.
Parts and inventory — the catalogue, stock levels, and which parts go with which assets.
Attachments — manuals, drawings, photos, inspection certificates. Often the most painful to move, and often the most missed when they're left behind.

Everything else — dead users, obsolete config, half-finished modules nobody used — is a good thing to leave in the past.

The part nobody warns you about: the data is messy

A 20-year-old system reflects 20 years of different people entering data different ways. Expect:

The same asset named three ways (PUMP-01, Pump 1, P1 Boiler Feed).
Duplicate and orphaned records — work orders pointing at assets that no longer exist, assets with no location.
Free-text where there should be codes — failure causes, work types, and priorities entered as prose, so they can't be counted.
Gaps — PMs that were "managed in someone's head" and never lived in the system at all.

This is normal. It's also the real work of a migration. Pulling the records out is the easy part; cleaning and reconciling them — de-duplicating assets, standardising names, mapping messy free-text into consistent codes, filling the gaps you can and flagging the ones you can't — is where the time goes. Done well, you don't just move the history; you come out the other side with cleaner data than you've had in years.

A sane order of operations

A migration that people trust tends to follow the same arc:

Find where the data actually lives. The application, the database behind it, the reports, the spreadsheets on the side, the binders. Map the real sources, not the official ones.
Pull a representative extract. Get real records out early. You learn more from 500 actual work orders than from any amount of planning.
Design the target. Decide the asset hierarchy and the code lists (work types, failure codes, priorities) the new system will use.
Map and clean. Match old fields to new, de-duplicate, standardise, and transform the free-text. This is the heart of it.
Load into the new system and check. Counts, spot-checks, and a few "follow this asset's whole history" walkthroughs with the people who know it.
Run in parallel, briefly. Keep the old system readable for a short, deliberate overlap so you can confirm PMs fire correctly and the history is intact before you cut over for good.

The aim is a clean cutover you've earned confidence in — not a big-bang switch and a held breath.

Keep a person in the loop

It's tempting to treat a migration as a purely mechanical job — point a script at the old database, run it, done. The cleaning step is exactly where that goes wrong. Deciding that PUMP-01 and P1 Boiler Feed are the same asset, or that a decade of free-text failure notes maps onto a tidy set of failure codes, takes judgment. Tools can do the heavy lifting and propose the matches; a person who knows the plant should confirm them before they become your new system of record.

That's the principle we build everything around: the routine, high-volume part of the work gets handled for you, and a person stays in charge of the decisions that matter.

Where Honewright fits

Bringing an old maintenance system forward is one of the workflows we build for directly. We pull the records out of wherever they live — old software, spreadsheets, scanned documents — clean them up, fill the gaps, and map them into a modern system you can actually use. Your data stays yours, and stays in Canada.

If you've been putting off a migration because the history feels too risky to move, that's usually the sign it's worth a real conversation. Tell us what's eating your time and we'll tell you honestly what it would take.