Moving off spreadsheets without breaking everything

Almost every company running on spreadsheets for safety and operations knows they need to move off them. What stops most of them isn\’t the decision — it\’s the fear of a chaotic cutover, a period where nobody trusts the new system and nobody\’s fully maintaining the old one, and important things fall through the gap in between.

That fear is reasonable, because a badly sequenced migration really can create that gap. The fix isn\’t heroics or a big bang cutover. It\’s picking the right order to bring things across, so at every point in the process you have one clear, trusted source of truth — never a mix of both, and never a hole.

Start with the register everything else depends on

Before anything else, get your asset and equipment list into the new system, properly. Every other module — inspections, maintenance, incident records that reference equipment — eventually needs to point at a real asset record. If you migrate a process before its underlying assets exist as clean records, you end up recreating the same messy cross-referencing you were trying to escape, just inside new software instead of an old spreadsheet.

This step is mostly about data hygiene, not process change. Get every asset a real code, a category, and a location. Don\’t worry yet about workflows built on top of it — get the register right first, because it\’s the foundation everything else sits on.

Move the highest-friction, lowest-risk process next

Resist the urge to migrate your highest-stakes process first, even though it might feel like the most important one to fix. The first live process in a new system is also the one where people are least confident using it, and where any teething problems are most visible. Pick something with real, obvious daily pain — like observation reporting, or help desk tickets — where the downside of a rough week is limited, but the upside of \”this is so much easier now\” builds trust fast.

That early trust matters more than it sounds like it should. The biggest risk in any migration isn\’t a technical failure, it\’s people quietly reverting to the old spreadsheet the moment the new system feels unfamiliar. An early win where the new way is obviously, immediately better than the old way is what stops that reversion from happening later, when it would actually cost you something.

Bring across anything with a compliance clock attached

Certificates, training records, and anything else with an expiry date should move early and deliberately, because these are exactly the records that silently rot in a spreadsheet. Nobody proactively checks a spreadsheet for what\’s about to expire — someone has to remember to look, on a schedule, and that\’s precisely the kind of task that quietly stops happening once the person who used to do it moves on or gets busy.

Getting these into a system that tracks expiry and reminds people automatically closes the exact gap that turns into an audit finding or a lapsed certification nobody caught in time. This is one of the highest-value early migrations, even though it isn\’t the most exciting one.

Save multi-step approval processes for once people trust the system

Work permits, gate passes, anything with a formal multi-stage approval chain — bring these across after people already trust the new system for something simpler. Approval processes involve more than one person\’s behaviour change at once: the requester, the approver, and anyone downstream who acts on the approval. If the underlying system itself is still unfamiliar, you\’re asking people to learn new software and a new process simultaneously, which is where migrations tend to stall.

By the time you get here, people should already be comfortable logging into the system daily for something else. Adding an approval step to a tool people already trust is a much smaller ask than introducing both at once.

Import in batches you can validate, not all at once

Whatever you migrate, do it in a way where a bad row doesn\’t corrupt a good import. A validation pass that checks every row before anything is created — and names exactly which rows failed, rather than half-importing and leaving you to figure out what\’s missing — is the difference between a migration you can trust and one you have to double check by hand afterward. If three rows are wrong, you want to know which three, not discover it three months later when someone can\’t find a record that was supposed to be there.

The order, in short

Assets and equipment first, because everything else references them. Then the highest-friction, lowest-risk daily process, to build trust fast. Then anything with an expiry date, because that\’s what rots silently in a spreadsheet. Then multi-step approvals, once the system itself is no longer the unfamiliar part. Validate every import before it lands, so nothing arrives half broken.

Done in that order, there\’s no point where you\’re running two sources of truth for the same thing, and no point where something falls through a gap between old and new. The goal isn\’t speed. It\’s never having a moment where nobody actually knows which system is right.