Buying EHS Software
EHS Software Migration Checklist: Moving Records That Outlive the Contract
An EHS software migration is a records problem before it is a software problem. Some of what sits in the old system carries a retention period measured in decades, and that obligation stays with you when the contract ends. Plan the migration around what you are required to keep, not around the go-live date.
By Matthew Hart
CEO, Soter
Written for teams planning a platform change. Retention periods are quoted from the regulations; whether a given record falls under a given standard is a determination for the employer and their competent adviser.
The go-live date is the easy constraint. The hard one is that some of these records have to survive the next three vendors.
Start with what you are required to keep
Most migration plans start with a timeline. Start instead with the retention periods attached to what you hold, because they set the shape of everything else and they do not move when the software does.
Under 29 CFR 1904.33(a), the OSHA 300 Log, the privacy case list, the annual summary and the 301 incident reports are kept for five years following the end of the calendar year they cover. The same section requires the 300 Log to be updated during that five-year period when a new case comes to light, which means the archive is not read-only: you may have to write into a record that lives in a system you no longer pay for.
The longer obligations are the ones that catch people out. 29 CFR 1910.1020(d)(1) requires that each employee exposure record be preserved for at least thirty years, that medical records be kept for the duration of employment plus thirty years, and that analyses using either be kept for thirty years as well. A platform decision made this quarter has to be compatible with producing a specific exposure record in 2056.
Responsibility sits with the employer, not with the system. The closest thing the regulations say about handover is 29 CFR 1904.34, which covers a change of business ownership: the seller must transfer the Part 1904 records, and the new owner must save them. That rule is about ownership of a business rather than choice of software, so do not cite it at your vendor. The principle underneath it is the one worth carrying: the records and the duty to preserve them travel together, whatever changes underneath them.
The four things that actually break
Migrations rarely fail at the moment of transfer. They fail quietly, and the failure surfaces during an audit a year later.
- Attachments detach. The export carries the record and leaves behind the photograph, the signed form, or the certificate that made the record evidence rather than a row. Test this first, because it is the most common and the most expensive to discover late.
- Open items have nowhere to land. A corrective action is not a row of text. It has an owner, a due date, a verification step and a state. Systems that model that differently will accept the import and silently flatten it, and you will find out when nothing is overdue because nothing is open.
- Identity does not map. Historical records lose the person who raised, approved or verified them, usually because the old system keyed users by email and half those addresses no longer exist. A record without an approver is weaker evidence than the same record with one.
- Integrations arrive late. When employee, asset and location feeds go live a month after the platform does, the first month of records in the new system is thinner than everything around it, and that gap is permanent.
The checklist
Ten steps in the order that keeps the obligations intact. Each one exists to prevent a specific failure rather than to fill a project plan.
| Step | What it prevents |
|---|---|
| Establish what you are required to keep, and for how long | Building a plan that cannot satisfy a thirty-year obligation |
| Inventory record types, counts and attachments | Discovering a record type nobody owned halfway through |
| Take a full export and open it | Trusting a sample that happened to contain no attachments |
| Decide where open corrective actions land | Silently closing every open action on import |
| Map users, roles and approvers | Records that survive without the person who signed them |
| Rebuild integrations before go-live | A permanently thin first month of records |
| Run one real workflow in parallel for a full cycle | Finding out in month two that the workflow does not fit |
| Verify ten migrated records end to end | An archive that looks complete in aggregate and fails in detail |
| Confirm deletion date, access and re-export cost in writing | Losing the source before you know the copy is good |
| Decommission on a date set after verification | Paying for two systems indefinitely, or shutting down too early |
Parallel running, and what finished means
Run both systems long enough to cover one full cycle of the work you are migrating. For inspections and hazard reporting that is usually a month. For anything quarterly or annual, either wait for the cycle or accept that the first one runs in the new system with some data assembled by hand.
Define the finish line before you start, because parallel running has a real cost: every record entered twice is a record entered carelessly at least once. A workable definition is that the new system has produced one complete cycle of records, a sample has been verified end to end, and the team has stopped asking whether they should also put it in the old one.
Five answers to get in writing
- The export format for every record type, attachments included.
- Whether historical data stays accessible during the notice period, and for how long after it.
- The date your data is deleted, and whether a copy can be requested after that date.
- Whether the export carries audit trail and approval history or only the current state of each record.
- What a second export costs if the first one turns out to be incomplete. This is the question most buyers skip.
If you are still choosing where to go, the buyer's framework covers how to test a platform on your own workflow, the five categories of alternative covers the market shape, and the VelocityEHS limitations piece is an example of the due diligence worth doing on any shortlisted vendor.
Where SoterAI fits
Two things are worth testing in a trial rather than taking on trust. Import a year of your existing records and check what survives the round trip: attachments still attached to the finding they support, corrective actions still carrying an owner and a due date, and the approver still named. Then export it all back out and open the file, because the migration you should plan for is the next one, not this one.
The records pages show which fields each record type holds, and the OSHA 300 guide covers what the recordkeeping forms require of whatever system holds them.
Sources
- 29 CFR 1904.33: Retention and updatingSource for the five-year retention of the 300 Log, privacy case list, annual summary and 301 forms, and for the duty to update the Log during that period.
- 29 CFR 1910.1020: Access to employee exposure and medical recordsSource for the thirty-year retention of exposure records and analyses, and for medical records kept for the duration of employment plus thirty years.
- 29 CFR 1904.34: Change in business ownershipSource for the transfer duty on a change of business ownership. Cited as a principle about records travelling with the duty, not as a rule about changing software vendors.
Test the round trip before you commit to it. See what a record holds.