Choosing your first HR system.

Spreadsheets fail gradually, then suddenly. The gradual part is familiar: versions multiply, formulas drift, and the person who built the master sheet becomes a single point of failure. The sudden part is an event: a missed probation date, a leave balance dispute nobody can settle, a salary visible to someone it should never have reached. The honest signal that you have outgrown the spreadsheet is not headcount, it is the first time you cannot answer a factual question about your own workforce with confidence.

There are three structural problems no amount of spreadsheet discipline fixes. There is no access control worth the name, so sensitive data is one careless share away from everyone. There is no history, so you cannot say who changed what or what was true in March. And there is no automation, so every date that matters, probation ends, visa expiries, review dates, is tracked by human memory. Those three gaps, permissions, history and reminders, are the actual reason to buy software.

Some technical teams are tempted to build their own: the data model looks simple, and the first version is a satisfying internal project. The trap is that HR software is not one product but a slow accumulation of edge cases: pro rata calculations, per-country rules, approval flows, permissions, audit trails, payroll interactions. Each one is small; together they are years. Meanwhile the homegrown tool has exactly one maintainer, and every HR question quietly becomes an engineering ticket.

The honest build signal is rare: your people processes are genuinely unlike anyone else’s and are themselves a competitive advantage. For everyone else, buying means the edge cases arrive already handled and maintained. The better use of internal technical judgement is evaluating vendors well: asking about data models, export paths and permission depth, where an engineer’s scepticism is worth a great deal more than an engineer’s weekends.

The deepest difference between systems is invisible in a demo: whether the product keeps one record per person that every feature reads, or several records that integrations try to keep aligned. In a one-record architecture, a salary change made once is the salary everywhere; leave, attendance and payroll cannot disagree because they are reading the same facts. In a stapled architecture, every module holds its own copy and the copies drift, which recreates, inside one product, the exact reconciliation problem you were buying your way out of.

You cannot see architecture, but you can test for it. In the demo, change something once, a manager, a salary, a working pattern, and then look for it in every other corner of the product: the org chart, the approval flow, the pay preview, the reports. If the change appears everywhere immediately, the record is shared. If anything needs a sync, an import or a repeat entry, you are looking at staples, and you will be doing the stapling.

Ask where each fact lives and how many times it is entered: the one-record test in question form. Ask what happens at the edges: a part-time joiner mid-month, an employee in a second country, a manager who leaves while approvals are pending. Ask who can see what, and whether permissions go deep enough to hide a salary while showing a role. Ask how you get your data out, in full, in a usable format, on the day you decide to leave. Vendors who are comfortable with these questions have been asked them before.

Then ask about the boring machinery, because the boring machinery is the product. How are balances calculated, and can they show their working? What lands on the audit trail? What does the payroll handoff actually contain? Pricing deserves the same scrutiny: per person or per module, minimum terms, and what happens to the price at renewal. A vendor’s pricing page tells you a lot about how they will behave in year two.

Migration is where first HR system projects actually struggle, and rarely for technical reasons. The work is not moving the data, it is discovering that the data disagrees with itself: three spellings of one job title, two versions of a salary, leave balances nobody can derive. Budget real time for cleaning before the import, because whatever you load becomes the new truth. A useful discipline is to migrate the minimum: current employees, current facts, current balances, and archive the historical mess rather than importing it.

Plan the cutover explicitly. Pick a date, freeze the spreadsheets, load the system, and have people verify their own records in the first week: names, dates, balances, bank details. Self-checking distributes the proofreading to the people who know the facts best and builds trust in the new system at the same time. Keep the old files readable somewhere for a year, and resist every request to keep maintaining them in parallel.

A first HR system changes daily habits, so the rollout is a people project with a software component. Start with the record and one visible win, usually leave, because everyone touches it and the improvement is felt in the first week. Resist switching on everything at once: each capability you add later lands on data that already exists, which is progressively easier. Tell people plainly what the system knows about them and who can see it, because trust in the tool is mostly trust about visibility.

Expect a shadow-system phase, where old habits continue in chat and side sheets. The cure is not enforcement but usefulness: when the system answers questions faster than the old way, the old way fades. Managers matter most here. If managers approve leave and check their teams in the system, everyone follows within a month; if managers route around it, no policy will save the rollout.