When to move HR off spreadsheets

Check whether the spreadsheet still does the job

A spreadsheet can serve a small team well. The useful question is whether the whole setup still gives people a dependable answer, not how many rows the main file contains.

Try five ordinary jobs. Can an authorised colleague find the current working pattern, trace a leave balance, correct a changed address everywhere it matters, keep salary or health detail away from the wrong manager and recover the record if its usual owner is absent? Look at recent starters, pay changes, absences and leavers rather than a tidy sample prepared for the exercise.

One weak answer may be fixable with clearer ownership or access. Several connected gaps usually mean the spreadsheet and its surrounding process are no longer easy to control.

Find the records and workflows around the spreadsheet

The main spreadsheet is rarely the whole system. Find manager copies, starter forms, leave trackers, payroll hand-offs, document folders, downloads, shared inboxes and personal notes. Ask the people doing the work where they look first and what they update next.

For each source, record:

• its owner and purpose
• the people and dates it covers
• the sensitive information it holds
• whether it is the current master or a copy
• who can view or change it
• the process that depends on it

This inventory exposes two different problems: the records that need moving and the work that needs redesigning. Importing a correct address will not fix a pay-change approval that still happens through an unrecorded message.

Write requirements before choosing software

Turn each failure into a job the replacement must prove. If managers currently see too much, ask a supplier to demonstrate role-specific access with a realistic manager account. If corrections disappear between systems, ask how a dated change reaches payroll, leave and the employee's own view.

Include the less visible controls: what privileged administrators can access, how access is authenticated and logged, how records are corrected, what the supplier does during an incident, and how the organisation gets its information back. The ICO processor-contract guidance explains the terms that belong in the supplier agreement.

Ask each supplier to show the same short set of jobs with awkward records. A polished feature list is a poor substitute for seeing how a part-time starter, a restricted document and a corrected employment date behave.

Decide what to move, retain or delete

Give every record category one outcome and a reason. Move it when the new system needs it for a current purpose. Retain it elsewhere when the record still has a justified purpose but does not belong in the live people profile. Delete it when no current purpose, legal need or unresolved case supports keeping it.

Use the ICO data-minimisation guidance and storage-limitation guidance to test the decisions. A legacy column is not a reason to import it. A migration is also not permission to destroy a record that still matters to a contract, claim, investigation or agreed retention rule.

Record the decision by category instead of deciding row by row during the import. That makes exceptions visible and gives the person doing the work a rule they can apply consistently.

Prepare the data without changing its meaning

Clean duplicates and formats while preserving source, status and context. A previous address is not inaccurate when it is clearly recorded as historical. A field headed “Start” may mean employment start, role start or the date somebody joined the spreadsheet. Resolve the meaning before mapping it.

Choose one source snapshot, name its owner and control changes while the data is prepared. Standardise dates, working patterns and identifiers only after the intended meaning is clear. Preserve current manager relationships in the signed-off source so they can be rebuilt and checked separately after the people records are reconciled. Keep a short decision log for transformed values and unresolved exceptions.

The ICO accuracy guidance distinguishes an incorrect current fact from an accurate record of what was known or decided at an earlier date. Preserve that distinction during cleaning.

Hand over to one live system

Plan the handover around ownership, not a dramatic weekend. Name the source snapshot, change-freeze point, test group, exception route, reconciliation owner and the moment invitations can be sent.

Compare the expected and imported people, then sample the fields whose errors would matter most: identity, start and leaving dates, working pattern, pay inputs and access to restricted information. Rebuild the preserved manager relationships separately and check the resulting reporting lines. Resolve or explicitly accept every exception before telling the team that the new system is live.

Once the result is accepted, tell people which system is now authoritative and where corrections belong. Remove broad editing access to the old copies. Keep a controlled evidence copy only where the documented purpose and retention rule justify it.

Check access, accuracy and the way out

Before closing the project, sign in as the real roles that will use the system. Confirm what an employee, manager, payroll user and administrator can see and change. Correct a sample record and check that the result, date and decision history are understandable.

Produce an export and inspect it. Confirm who can request one, what it contains, whether files and relationships are usable, and what happens to retained data when the supplier contract ends. Choosing a processor does not transfer the employer's UK GDPR accountability.

If HollyHR is the chosen destination, the spreadsheet migration page explains its current import route and supported boundaries. Keep product mechanics there so this guide can remain useful whichever system the reader selects.