Moving five years of paper records without breaking retention rules

The instinct when you buy water hygiene software is to scan the archive, all five years of temperature logs, risk assessments and tank inspections, so everything finally lives in one place. Resist it. Scanning is weeks of work, it produces a worse record than you started with (a scan of a photocopy of a faded printout is not an upgrade), and the retention rules never asked for it.

Here is the shape that works instead. Pick a cutover date. Digitise only the living data: the asset register, the active schedules, the open remedial actions, and the current risk assessment status for each site. Box and index the paper archive by site and year so any single record can still be produced on request. Then start clean. Your historical records go on satisfying the retention duty by sitting in a labelled box you can find, not by being retyped into a system that doesn't need them.

The retention clock doesn't pause for a migration

The duties keep running straight through any change of system. Monitoring records still have to reach at least five years old, and general records are kept while current plus two years after. Swapping software is not an event the record duty recognises. The morning after your cutover, a temperature reading from three years ago still has to be producible if someone asks.

The mistake is assuming your new system has to hold that reading. It doesn't. It has to not lose track of where the reading is. Those are very different jobs, and only one of them involves a scanner.

Digitise the living data, not the dead

"Living" has a narrow meaning here, and keeping it narrow is what makes the job finishable:

• The asset register. Every tank, calorifier, TMV and sentinel outlet, per site. This is the spine of the new system, and without it your schedules have nothing to hang on.
• The active schedules. Which task recurs at what frequency against which asset. If you need the cadences themselves, we put every water hygiene task and how often on one page.
• The open remedial actions. Anything still waiting on a fix. A remedial closed out two years ago stays in the box.
• The current risk assessment status per site: in date, due, or overdue.

That's the whole list. You're standing up a system that runs from today forward, seeded with the state of play today, not the story of how you got here. Everything older is history, and history belongs in the archive, not the migration.

The few documents worth scanning

There's one honest exception to the no-scanning rule, and it's a small one. A handful of living documents get opened constantly: the current risk assessment for each site, and any in-date certificates you quote to clients. Those few, scan or attach to the site record, because you'll reach for them every week and walking to a box for a document you use every week is its own waste. The rule is about the archive, the dead five years of monitoring sheets nobody reads until an audit. It was never a ban on having today's live risk assessment on the screen. Keep the exception small, though. The moment "documents we use constantly" starts creeping toward "documents from 2022 that might come up", you're back to scanning the archive by the back door.

Box it, index it, say where it lives

The paper doesn't get destroyed and it doesn't get scanned. It gets organised until it's reliably producible. Index by site and by year, because that is exactly how an auditor or an inspector will ask: the temperature records for this building, 2023. A retention duty you can satisfy by walking to a labelled box is a duty you have met. The records going forward, of course, need to clear a different bar, authentication and all the rest of it, which we cover in the piece on digital records being acceptable.

One more step people skip: tell your clients and your LCA assessor where the historical records now live. A silent migration is how a client comes to believe five years of their compliance history evaporated when you changed software.

Who owns the boxes when a client leaves

Worth settling before you migrate, not after. When a client moves to another contractor, the historical records for their sites are usually theirs, and they will ask for them. Boxed and indexed by site, that handover is an afternoon of pulling folders. Scanned into your software and tangled with every other client's data, it becomes an export job and an argument about formats. The physical archive, organised by site, is quietly the easier thing to hand over cleanly, which is one more reason not to pour five years of everyone's paper into one database you'll later have to unpick.

Run parallel once, then stop

The temptation is to keep the paper going next to the software "just until we trust it". Give it one monitoring cycle. Run both through a single month of sentinel temperatures, or one round of whichever task comes up first, compare the two, fix what the software got wrong, and then stop the paper. Set the date you'll stop before you start.

Indefinite parallel running is where migrations die. Two half-trusted systems, engineers filling in both and doing neither properly, and eventually a month where neither is complete and you can't prove the work at all. Double entry also costs real money and real goodwill, which we put numbers to in the true cost of double data entry.

The limbo to avoid

Picture the failure directly. Six months after go-live, the asset register is half-loaded, some sites are on the software and some are still on paper, and nobody can answer "is this site compliant?" without checking both places. Neither system is trusted, so people trust neither, and the confident answer you bought the software to get is further away than before you started.

The way out is the same discipline that prevents it: a hard cutover date, and the restraint to digitise only the living data. Loading the state of play is a small, finishable job. Loading the whole archive is a job that never ends, and half-finished is the worst place to stop.

Where BlueWave starts a migration

This is why a BlueWave migration starts with the asset register and the schedules, built per site, before an engineer ever opens the app. Land engineers on a system that already knows their tanks, their outlets and their next visit, and day one feels like an ordinary day rather than a launch (the asset register and schedules, set up first). We don't ingest your paper archive, and honestly you shouldn't want us to. That is what the labelled boxes are for, and they meet the retention duty perfectly well on their own.

Rule of thumb: if your migration plan contains the word "scan", it's the wrong plan. Digitise what's alive, index what's done, fix the cutover date, and run parallel exactly once. The retention rules were never the hard part of moving to software. The half-finished middle is where firms come unstuck.