Fix the Plant Data Before the Migration, Not During It
A migration moves your equipment and material masters into a new system. It does not repair them. The months before the mapping workshops are the one window where cleansing is calm, funded, and evidence-based.
Priyansh Srivastava
Co-founder & CEO, Raven
Early in every EAM migration there is a moment nobody puts on the project plan. The integrator's data template arrives, someone exports the equipment master and the material master to fill it, and for the first time in years a human being actually looks at the extract. Twenty years of drift stare back: descriptions in three conventions, duplicate codes, equipment with no BOM, hierarchy branches that stopped matching the plant two turnarounds ago. The migration did not create any of this. It just presented the invoice.
Plants are in this moment constantly now, with ERP deadlines and EAM consolidations pushing old systems toward new ones. The question that decides how much the migration actually improves things is not which system you are moving to. It is what you do with that extract in the months before cutover.
A migration moves data. It does not repair it.
The default path is politely called lift and shift: map the old fields to the new fields, transform the formats, load. It is the rational default for a systems project, because the migration team is accountable for cutover, not for whether the seal was catalogued twice in 2009. So the duplicates arrive in the new system with fresh numbers, the empty BOM tabs arrive empty, and the plant gets its old data back in a cleaner interface. The confusing part for leadership is that the project succeeded. Every milestone was met. The data is exactly as unreliable as before.
The new system can even make things look worse. Modern EAM data models validate more and mandate more, so junk that lived quietly in free text now either blocks a load or gets padded with placeholder values to pass validation. A placeholder passes the load check. It fails the planner who trusts it later.
Why cleansing during the migration fails
Every migration plan contains a data cleansing line, and it is usually the line that gets squeezed. The reasons are structural, not moral. The cleansing window lands in the exact months the plant's data owners are busiest with testing and training. The integrator's people are system experts, and cleansing keeps getting redefined as what system experts can do to an extract: fixing formats, filling mandatory fields, de-duplicating exact matches. That work is real, but it is not the work.
The real work needs evidence. Which of two duplicate codes survives, and what should the merged description say? What does this equipment's BOM actually contain? Is this hierarchy branch still what the plant looks like? None of those answers is in the extract. They are in the vendor documents, the datasheets, the drawings, and sometimes in the P&IDs. Cleansing inside the extract is proofreading a document against itself.
The order that works
Fix the data against the documents first, then migrate clean data. De-duplicate by maker part number, not by description similarity. Build the missing BOMs from the manuals and spares lists. Check the equipment hierarchy against the drawings. Do it in the calm months before the mapping workshops, so the migration team receives a master it can trust and the plant's engineers review evidence on their own schedule instead of under a cutover clock.
There is also a plainer argument for this order. A migration is the one moment an organization will actually fund data quality, because the cost of bad data is suddenly attached to a board-visible project. A plant that has wanted its catalogue cleaned for a decade should not let that budget window close on formatting fixes.
Start with an assessment, not a scope
Before anyone prices a cleansing project, measure the problem. A material master extract, a stock report, and a folder of vendor documents are enough to count the duplicates, the missing BOMs, the parts with no code, and the attribute gaps, with a value attached where stock is involved. That one report turns the migration steering-committee conversation from an argument about effort into a decision about numbers, and it sometimes shows the problem is smaller than feared. Either outcome is worth having before the mapping starts.
Where agents fit
The reason document-grounded cleansing used to lose to extract-grounded cleansing was never doubt about which is better. It was the reading: thousands of codes and a shelf of documents per unit, against a project deadline. That reading is what AI agents have changed, and it is the work Raven does. The agents read the spares lists, manuals, and drawings, check the extracts against them, and return the findings with the document evidence attached; your engineers confirm what changes. The output is load files your migration team consumes. Raven is not another system in the migration, and nothing migrates into it.
The honest sequencing advice
If your cutover is a year or more away, start the document-grounded cleanse now, unhurried, and hand the migration team a clean master. If cutover is closer than that, at minimum run the assessment, so you know exactly what you are carrying across and can fix the expensive parts first. The only genuinely bad option is the common one: discovering the state of your data in the integrator's template, with the clock already running.
About the author
Priyansh Srivastava is co-founder and CEO of Raven (YC S22). Raven reads a plant's own documents, builds a verified model of the plant from them, and checks the material master, BOMs, and inventory against it.
