DATA & MIGRATION
Most CMMS projects fail in the migration, not in the software. Ours is built so you see what a legacy file will do before anything is written.
HOW IMPORT WORKS
Staging judges. Applying writes. Nothing else touches your data.
Point the plant at a CSV of machines or parts. It reads every row and reports each one back as VALID, WARNING or ERROR with a message a human can act on, then leaves a report you can read. No machine and no part is created at this stage — not one.
Applying says in its body what may be done to a row the plant already recognises. Rows that were never valid are attempted and reported; rows already applied are skipped. A job whose rows are all dealt with becomes complete.
An interrupted import is resumed by looking at the rows, not by hoping a background job remembered where it was. Run it again and the already-applied rows are skipped, so a partial migration finishes instead of duplicating.
Staging and applying run inside the request within those bounds, which keeps the outcome immediate and the feedback honest. Larger legacy tables are migrated in slices, each with its own report.
NO DUPLICATES
Two mechanisms, because a legacy file may or may not carry identifiers.
A legacy system's own id is mapped to the entity it created, keyed by plant, source system, entity type and external id — because two legacy systems that both call a machine P-01 are two different machines.
When a file carries no external ids the plant proposes the asset tag for a machine or the part number for a part — and refuses to apply anything until a human names that column back. The mapping step is a dry run, not a guess.
A row with an external id reserves its identity before any entity is written. Only the run that reserved it creates the machine; the other finds the mapping, treats the row as existing and updates it. Both converge on one record.
The mapping table is append-only for every role including its owner, and a row that has been applied can never move back out of applied — the one transition a resumed run could otherwise abuse.
WHAT DOES NOT MOVE
Knowing this before you start is the difference between a migration and a mess.
An import never changes an asset's tag or a part's number — a file with a different tag is a different machine. It never changes an asset's site, lifecycle fields, stock policy or any monetary value. What moves is what a legacy export actually carries: names, makers, models, serial numbers, descriptions and units.
Import works. Export does not exist, and neither does a tenant export or deletion workflow. Both need a decision about what a plant is entitled to take out, and we would rather state the gap than show a button that does nothing. See the product status page.
Source data is classified by quality, and gaps stay visible. Nobody fabricates a failure cause or an asset mapping so that a report looks finished — a plausible-looking lie in your maintenance history is worse than an empty field.
THE ONBOARDING SEQUENCE
Ten steps, in this order, with a shadow week before anything is switched over.
Do not attempt to migrate every legacy field before the pilot. What matters first is the identity and history your team needs to do maintenance; everything else can follow, and the mappings and export evidence are kept.
MIGRATION QUESTIONS
The fastest way to answer "will our data fit" is to stage a real file and read the report together.
