Coactivity & SIMOPS: Detecting Conflicting Work on Equipment
How AI Migrates Your Lockout Procedures in Hours
10 November 2026Ask an EHS lead why the site still runs its lockout program on software nobody defends anymore, and you rarely hear an argument about the software. You hear a number. Eight hundred procedures. Two thousand. Whatever the library holds, that is what would have to move.
That number is the real switching cost. And it rests on one assumption worth questioning: that every procedure moves by hand, one at a time. Take that assumption away and most of the number goes with it.
Why do EHS teams stay on outdated lockout tagout software?
Because the procedure library is the program. Lose it, corrupt it, or stall halfway through moving it, and you have a compliance problem that lands on one person’s desk.
The volume is the first wall. Your library runs longer than your equipment list, because one machine often needs several procedures: a full isolation for one task, a narrower one for another, a different energy scope for a third. OSHA wants them documented and equipment-specific. Europe and the UK arrive at the same place through safe isolation and a safe system of work. Whatever your equipment count is, your procedure count is higher. That is what has to move.
And the per-procedure cost of doing it by hand is not controversial. CONFORMiT’s own published breakdown puts the pure data-entry step, loading one procedure into a system, at roughly half an hour. Treat that as a floor: it assumes a short procedure and a clean source. Re-keying scales with steps and isolation points rather than with procedure count, and every device has to exist in the new system before a procedure can point at it, so a forty-step procedure with a dozen energy points is nothing like a six-step one. Buyer’s guides elsewhere in the LOTO market put the full job at two to three hours per procedure once cleanup is counted.
Eight hundred procedures at half an hour each is ten weeks of one person’s full time, and that is the keying alone. At two to three hours each, it is most of a year. Run your own count through the same arithmetic and you understand why the project keeps slipping to next fiscal year.
The second wall is personal. When a procedure turns out to be wrong, the question goes to whoever owns the lockout program. Not the vendor, not IT. On a system where procedures are already hard to keep current, any change looks like a chance to introduce an error someone will ask about later. So nothing moves, even when the tool no longer fits how the plant works.
Meanwhile, staying is not free either. Three things happen while the decision waits:
- Time you are already spending. Hunting for the current version, chasing approvals, rebuilding the same status report by hand every month. This cost never lands on a budget line, which is why it never gets weighed against the cost of moving.
- The ground shifting under you. The LOTO software market is consolidating, and acquisitions have a way of putting customers on a platform they never evaluated. A migration you plan is a very different exercise from one you inherit.
- An aging on-premise footprint. End-of-life dates and patch availability are already on a calendar, and it is IT’s calendar, not yours. Wait long enough and the migration stops being a decision you make and becomes a deadline you are handed.
What does migrating a lockout/tagout procedure library actually involve?
Usually more than most people budget for, which is exactly why the project stalls.
A full migration means re-keying thousands of procedures, rebuilding the isolation device registry, re-mapping every piece of equipment and every energy point, and running every procedure back through its approval cycle. Most coordinators have already attempted some version of this. It is usually the attempt, not the idea, that convinced them it was impossible.
There are two ways it goes wrong.
It stalls. The work stretches over months, then years. The literature on lockout programs documents plenty of cases where the program exists on paper and is never applied on the floor. A migration that never finishes produces exactly that outcome.
The expensive part is more than the delay itself. It is also what the delay creates: two live systems, and therefore two sources of truth. Data duplicates, nothing is centralized, and procedural drift sets in, the procedure no longer matching the equipment it describes. Six months in, nobody can say with confidence which version is authoritative.
Which makes the timeline a safety question, not a project management one. Every week two libraries run side by side is a week where the procedure someone follows might not be the current one. Nobody can promise zero disruption on a live site. A window short enough that the old library never becomes a second source of truth is a fair thing to require.
It copies the errors and adds new ones. Legacy libraries carry known defects: incomplete procedures, residual energy sources not identified, no isolation sequence at all. Research on lockout program quality suggests only about 10% of programs specify the sequence. Manual re-entry preserves all of it and introduces fresh transcription errors on top.
How long does it take to migrate lockout procedures to new software?
There is no published standard for LOTO migration, which means any timeline you are quoted, including this one, rests on someone’s project history rather than on a norm. What follows is CONFORMiT’s.
By hand, the numbers above hold: months for a mid-size library, longer across sites. AI-assisted extraction splits the answer in two. Hours for the data transfer. Weeks for the project around it, around twelve on a typical engagement.
What moves that number is less the size of the library than the state of the data going into it. Unique identifiers on every isolation device, each one sitting against the right equipment at the right location, consistent naming, fields used for what they were meant for: a library like that migrates quickly. One where the same device appears under four different spellings, or where much of what is in the folder turns out not to be a lockout procedure at all, takes longer, because someone has to sort that out before anything can be structured. Edge cases are unavoidable. The number of them is not.
Worth saying plainly: that sorting is work you can start before you buy anything, and it pays off whichever platform you end up on.
How does AI-assisted lockout procedure migration work?
Nobody re-types the library. You send your sources as they are, and they come back as structured procedures inside CONFORMiT.
Where those sources start from changes the work, and two situations cover nearly every project.
From another system with a structured database behind it, an enterprise platform or another EHS suite, the work is mapping. No two systems share a field list, and that is where expectations need setting. In practice, the CONFORMiT procedure follows a defined structure, so some information gets placed where it fits rather than where it used to sit in the old system. What does not happen is information loss. The CONFORMiT team works the mapping until every piece of data has a home. A structured export makes that considerably easier than a folder of documents.
From documents, Word, PDF, scans, spreadsheets, the work is extraction. That work goes through Johnny, CONFORMiT’s multi-agent AI platform for EHS. Its LOTO Digitization agent reads what you have and pulls out each procedure’s equipment references, isolation devices, step sequences and hazard context, following rules defined with the CONFORMiT team. It is the most mature and most widely deployed capability in Johnny today, and it is live for Lockout.
Give the agent consistent input and it classifies reliably. Give it a library where the same device appears four different ways, and it will occasionally see an element without recognizing what it is. Those cases surface in review rather than passing silently, which is the purpose of the sample stage below.
The project runs in five stages, and that sample is the fourth:
| Stage | What happens |
|---|---|
| Before kickoff | You send your data, CONFORMiT analyzes it |
| Kickoff | Objectives and calendar aligned |
| Migration rules | You define together how your data maps into the new structure |
| Test sample | A first batch migrated into a sandbox, reviewed, adjusted |
| Final import | Everything imported into production, once approved |
Platform onboarding runs in parallel: configuration, roles, training. You validate, CONFORMiT executes.
The first row carries more weight than it looks. That analysis runs on the complete dataset rather than on a sample, which is the only way to put a real number on scope and to know in advance which procedures will need hands on them. Procedures too complex or too degraded for automated extraction are handled separately, manually where that is what it takes. And if a migration turns out not to be a good idea, that is what you will be told, along with a pointer toward trustworthy resources equipped to do it by hand.
Who runs the project matters as much as what extracts the data. A CONFORMiT team works the project with you at each stage, which is what keeps the sample-validate-correct loop from turning into a six-month email thread. It also takes someone on your side who owns the project and can keep it moving, because changing systems is not only moving procedures. It is internal change management and training people on a new tool. Migration projects fail on availability far more often than on technology.
Can AI keep migrated LOTO procedures consistent across sites?
Speed only matters if the destination is better than the origin. This is where the data model does the work.
In CONFORMiT, a lockout procedure is not a standalone file. Isolation devices and equipment live in one central registry, shared across every site, and each procedure points at those records instead of holding its own copy.
That structure changes three things:
- A device is managed in one place. When it changes, every procedure using it updates. No manual sweep, no hunting for which procedures were affected.
- Equipment changes flag the procedures automatically. Depending on the nature of the change, the affected procedures either retrigger the approval process or keep their current status. Drift gets surfaced instead of discovered during an audit.
- Only approved, current versions reach the field. Customizable approval workflow, combined with user roles and permissions govern what each person can open or print. A superseded version does not quietly stay in circulation.
The reason this matters is not just the audit. A procedure that no longer matches the equipment still gets followed. Someone is at the disconnect, following it step by step. An energy source nobody listed. A step in the wrong order. A device that is no longer there. None of those are harmless. Keeping the library current is a safety control, not a housekeeping task.
None of that replaces looking at your procedures on a schedule. Periodic review is required either way. The difference is how much it has to catch: the shared registry keeps the library current between reviews, so the review confirms rather than repairs.
Extraction controls how fast the library arrives. A centralized registry of isolation devices controls whether it is still accurate a year from now, because changing one device reaches every procedure that uses it without anyone hunting for them. The second one is why the move is worth making.
What parts of lockout procedure migration still need a human expert?
The parts where someone’s name goes on the line.
Validating a procedure engages worker safety and legal responsibility. That belongs to competent people who know the equipment, and it stays there:
- An experienced operator validates the content. They confirm the procedure reflects the equipment as it stands today, and they catch what only the trade sees.
- Drifted or obsolete procedures are flagged for rewriting, not copied. The migration is an opportunity to correct rather than a mechanism to freeze errors into a new system. On real projects, structured extraction has surfaced mistakes made by hand years earlier that had been sitting in the library unnoticed. Those got fixed on the way through.
Your approval workflow does the certifying, not the migration. Every migrated procedure enters the cycle you already run, with the source document attached as a PDF so the reviewer compares old and new side by side. You are checking, not transcribing.
How does migration help capture knowledge before experts retire?
Every plant has procedures that are technically complete and still miss something. The valve that has to be cracked in a specific order. The residual pressure that takes longer to bleed than the drawing suggests. The operator who knows it rarely writes it down, because to them it is not knowledge, it is just how the machine behaves.
That knowledge is not in the legacy library. It is in one person, and that person has a retirement date.
A migration is the rare moment when someone sits down and goes through the library procedure by procedure with an expert in the room. Structuring the procedures and capturing what was never written down, can happen in the same pass. Do it while the expert is still there, and the knowledge stays with the equipment record instead of leaving with the person. Do it after they leave, and you are reconstructing from a document that was already incomplete.
Regulators require periodic inspection of energy control procedures (OSHA 29 CFR 1910.147(c)(6) in the United States, CSA Z460:20 in Canada, and the equivalent duties under PUWER 1998 in the UK, where teams more often say energy isolation or safe isolation). None of them require you to capture what the expert knows. The retirement schedule does.
What do you get after migrating your LOTO library?
Here is the point of the whole exercise. Once migration is no longer the wall, what is left is the part you have been postponing.
A lockout program that has been migrated into a system built for it gives you:
- A managed program instead of a collection of procedures. One library, one lifecycle, one set of statuses across sites.
- Real-time visibility through the Command Center. Planned work, lockout in progress, equipment secured, post-work closure, updating as crews progress.
- Field execution through CONFORMiT Ops. The right procedure, step by step, on iOS or Android, even offline where there is no signal, with every execution recorded.
- Structural drift resistance. Update the device once, every affected procedure follows.
- A maturity indicator you can actually track. The execution-on-approved-procedure rate tells you whether the program lives on the floor or only in the library.
- An audit trail that is already assembled. Who changed what, when, on which procedure, and which version was in force during a given isolation.
None of that is available while the library is the hostage of a system that no longer fits your opperational needs.
And if market consolidation is going to push a change on you anyway, the change is worth making toward a platform shaped around how your operation actually runs, on your schedule and your terms.
See what your library looks like on the other side. Book a demo and bring a sample of your current procedures and find out what moving them actually involves.
Lockout procedure migration FAQ
What is digital lockout/tagout software?
Digital LOTO software, sometimes called eLOTO, manages the lifecycle of lockout procedures: authoring, technical validation, approval, distribution to the field, and revision history. It replaces the paper and spreadsheet version of that administration. It does not replace physical locks, tags, or the verification performed at the disconnect.
What sources can AI-assisted lockout procedure migration read?
Structured exports from another platform, and documents: Word, Excel, PDF, and scans of paper procedures. A structured export maps most directly. Documents require extraction rules, defined with you, that tell the system how to recognize device identifiers, equipment numbers, and procedure steps in your own conventions.
How is AI-assisted procedure migration different from OCR?
Optical character recognition converts an image into text. AI-assisted migration goes further and identifies what each piece of text is, so a device identifier is stored as a device, a step as a step, and an equipment reference is linked to the equipment record. The output is structured data, not a searchable document.
Does AI-assisted migration cover safe work procedures and permits?
Not today. LOTO Digitization is live for lockout procedures, which is where the tool has been used and refined most. Safe work procedures and work permits are managed in CONFORMiT, but moving them is not covered by the same automated extraction and should be scoped separately.
What should we prepare before migrating lockout procedures?
Three things make the biggest difference: unique identifiers on isolation devices, each device linked to the right equipment and location, and consistent naming across procedures. It also helps to separate actual lockout procedures from everything else stored alongside them. That sorting pays off whichever platform you choose.
Do operations have to stop during a lockout software migration?
No. Extraction and mapping happen in a sandbox rather than in the production environment, so the plant keeps running on its current procedures while the new library is built and reviewed. The change reaches crews at cutover, which is why training and internal communication are scheduled alongside the migration rather than after it.
Can we export our lockout data out of CONFORMiT later?
Yes. Procedures, isolation devices, equipment records, and execution history can be exported. It is a fair question to put to any vendor before committing, and the answer is worth having in writing. A library you cannot get back out of a system is the reason migrations feel impossible in the first place.
