Migrating From Paper
This is not legal advice.
Moving from paper to a system is a small project with one genuine trap in it, and the trap is not technical. For an additional implementation-oriented example, see workforce analytics software.
Reviewed August 9, 2026.
The rule that matters
Do not retype the historical records into the new system.
It is the obvious first instinct, it feels tidy, and it converts a set of contemporaneous paper records into a set of entries created on the migration date. That fails the "objective" limb — the new entries are transcriptions, not records made at the time. For additional workplace and technology context, see International Labour Organization.
Keep the paper. It remains a valid record for its period, and it satisfies the duty for the time it covers.
The sequence
One. Set a cut-over date. Everything before it lives on paper; everything after lives in the system. No overlap and no backfill.
Two. Store the paper properly. In order, for the applicable retention period, somewhere it can be produced. This is now an archive with a defined life rather than a working file.
Three. Note where it is. One line in your records policy saying that records before the cut-over date are held in paper form at a stated location. An auditor asking for a period before the cut-over needs to be pointed somewhere.
Four. Start the system clean, on the cut-over date, with everybody.
Five. Run a parallel week if you can — paper and system together — to find the gaps before the paper stops.
If you must digitise the paper
Sometimes there is a reason: storage, site closure, a search requirement.
Scan it, do not retype it. A scan is an image of the contemporaneous record and preserves its character. A retyped entry is a new record.
Keep the originals if the retention period is still running and there is any doubt.
And store the scans as an archive, separate from the live system, so nobody later mistakes them for entries made in it.
What to get right at the cut-over
Everybody moves at once. A period where some people are on paper and some in the system produces exactly the gaps an inspection notices.
The correction rule carries over. Whatever you decided about corrections applies in the new system, and the new system should make it easier rather than different.
Employee access from day one. Not a later phase — it is part of the standard, and adding it afterwards means running non-compliantly in the interim.
And the retention configuration set before go-live, not after the first records exist.
What the migration is a good moment for
Deciding who records, rather than inheriting whatever the paper habit was.
Writing the short policy you did not have — what is recorded, who corrects, how long it is kept, who can see it.
And talking to the works council if there is one, because the system choice is the co-determination question and doing it at migration is far easier than retrofitting agreement.
The short version
- Do not retype historical records into the new system; transcriptions created on the migration date are not contemporaneous records
- Keep the paper — it remains valid for its period and satisfies the duty for the time it covers
- Sequence: set a cut-over date, store the paper in order, note where it is, start clean, run a parallel week
- If you must digitise, scan rather than retype, keep originals while retention runs, and store scans as a separate archive
- Everybody moves at once, the correction rule carries over, employee access from day one, retention configured before go-live
- Use the migration to decide who records, write the short policy, and settle the works council question