Buying HR software

The real cost of switching HR systems

The quote for the new system is the only number anyone circulates, and it is the smallest number in the project. The expensive parts of a migration do not appear on any quote, because they are your own people’s time, and time inside a company is free in exactly the way that nothing else is free.

Here is what a switch actually costs, in the order you incur it.

The five costs nobody quotes

Data cleanup. Every HR system accumulates a decade of tolerance. Duplicated people, leavers never marked as leavers, three spellings of the same department, a contractor recorded as an employee because that was the only record type available in 2023, leave balances adjusted by hand for reasons that lived in someone’s inbox. The old system tolerated all of it. The new one will validate on import, which is how you find out. This is the single largest line, and it is largest precisely at the companies that most want a new system.

The parallel run. For at least one full cycle you maintain both systems, because you cannot verify the new one against nothing. That means double entry for a month, and the double entry is done by the person who is also learning the new tool.

Retraining. Not the admin, who wanted this. Everyone else: the managers who approved leave by muscle memory and now cannot find the button, the finance person whose monthly export has different column headings, the employees who will each ask one question. It is a small cost per head and a real cost in total.

Rebuilt integrations. Whatever the old system was wired into gets rewired. The payroll handoff, the identity provider, the spreadsheet someone in finance built against a report that will not exist in the new system. Each of these is small. There are always more of them than the inventory said, because the inventory was made from documentation and the integrations were made by people.

Institutional memory. The most underrated line. Your team knows that the leave report is wrong in the first week of the month, that you have to run the export twice, that the field labelled “start date” actually holds the rehire date for four people. That knowledge is worth something, and it is worth nothing the day you move. You will rebuild it in the new system over about six months, and during those six months you are slightly slower at everything.

A sequence that works

Export first, before you have chosen anything. Take a full export from the current system while your account is healthy and paid, open the archive, and read it. This is diagnostic, not preparatory: whatever is missing from that file is the work you are about to do by hand. The switching guide has the full checklist of what to pull and in what order.

Then clean the data in the old system, not the new one. It is tempting to treat the migration as the cleanup, but a broken record is easier to fix where its history still lives.

Migrate the system of record next, and only that: people, employment, documents, structure. Get one source of truth standing and correct before anything else touches it. Peripheral modules follow one at a time, in the order you will actually use them, which is usually leave first because it is the most visible to employees.

That middle step is where the estimates further down are won or lost, so read what an implementation actually involves before you put a date on it. Entities, locations, calendars and leave policies are configured before a single person is loaded, and doing it in the other order means loading them twice.

Run the parallel cycle. One complete month of leave requests and approvals, one full handoff to whoever runs your payroll, one recurring compliance task.

Cancel last. One extra month of a subscription you no longer want is cheap next to discovering in week three that a report you relied on exists nowhere else.

Roughly what it costs, by size

Under twenty five people, one country, no statutory reporting beyond the basics: a focused week of one person, plus a few days of tidying afterwards. The tool matters less than whether your spreadsheet was tidy.

Twenty five to a hundred: two to four weeks of one HR person’s working time, spread over six or seven calendar weeks, with a day each from finance and IT and a couple of hours from every manager. Assume the parallel run doubles the leave admin for one month.

A hundred to four hundred, or any headcount across more than one country: a project with a named owner, a defined end date, and a quarter of elapsed time. Multiple countries multiply the cleanup rather than the setup, because each country has its own statutory fields, its own document set, and its own definition of a leaver.

These are estimates from the shape of the work rather than a survey, and the variable that moves them most is not the vendor. It is how honest the old data is.

Why this is exactly what makes gating profitable

Now connect the two halves of the buying problem. A vendor’s pricing power over you is bounded by what it would cost you to leave. On day one that cost is near zero, which is why the first year is competitively priced. By month eighteen the cost is everything described above, and the vendor knows it more precisely than you do.

That is why feature gating clusters where it does. The features that end up behind an upgrade are rarely the ones you evaluate on. They are the ones you need later: single sign-on when you hire your first security-conscious customer, an API when a spreadsheet stops scaling, an audit log when a diligence request arrives, a second country when you open one. Each of those needs arrives after your switching cost has matured. That timing is not a coincidence, it is the business model, and it is the argument in feature gating is a tax on growing.

The defence is not cynicism about vendors. It is keeping your exit cost low on purpose, so that the renewal conversation is a conversation.

Three ways to cut the bill

Export early and read the export, on a schedule, before you need it. A quarterly export you have actually opened turns your exit from a project into a file. It also tells you which vendor you are dealing with, which is why the strongest evaluation method is to start your shortlist with the export.

Migrate the system of record before the peripheral modules, and resist the temptation to move everything in one weekend because the whole team is available. One correct source of truth is worth more than five half-loaded modules.

Never migrate during a payroll cycle or a review cycle. Both are periods where the old system is load bearing and an error is visible to employees or a regulator. The tool-specific guides cover the traps per system, including leaving BambooHR and leaving Deel, and the traps differ more than the vendors admit.

Where we stand

We are the new system in this story, which means our incentive is to make the number above look small. So take the specific commitments instead of the reassurance. Our export is one archive of open formats with the documents included and a manifest you can check the contents against, an owner runs it without asking us, and it deliberately keeps working while an invoice is unpaid or a workspace is suspended. That is on the security page, with the document behind it named.

What we do not have is an import that makes any of this painless. There is no magic connector that lifts a competitor’s history into ours, and the cleanup described above will be your cleanup. We would rather say that now than sell a two-week timeline and hand you a spreadsheet in week three. If you are still deciding whether the move is worth making at all, the case, including the parts that argue against it, is on why switch.

Common questions

How long does it take to switch HR systems?

For a company under twenty five people in one country, a focused week of one person plus a few days of tidying, and most of that is cleaning the employee list rather than using the new tool. Between twenty five and a hundred, plan two to four weeks of one HR person spread across six or seven calendar weeks, with a day each from finance and IT. Above a hundred, or across more than one country, it is a project with a named owner for a quarter. The variable is not the software. It is how tidy the old data is.

What is the most expensive part of an HR migration?

Data cleanup, almost always. Every HR system accumulates duplicates, people who left but were never marked as leavers, job titles typed four different ways, and leave balances adjusted by hand for reasons nobody wrote down. None of that migrates cleanly, because the new system will validate what the old one tolerated. The second most expensive part is the parallel run, where two systems are maintained at once so that the first month in the new tool can be checked against the last month in the old one.

When should I not switch HR systems?

Never during a payroll cycle, never during a performance review cycle, and never in the weeks before a statutory filing deadline. Those are the three periods when the old system is load bearing and an error is visible to employees or a regulator. Pick a window immediately after a pay run completes, which gives you the longest clear runway before the next one. If your review cycle and your fiscal year end fall close together, the quiet month is usually just after the review cycle closes.

That was the argument. The free core is where you check it.