Switching From BambooHR to HiBob: What the Migration Actually Costs

TL;DR

• The licence difference is the number everybody compares and the smallest of the four costs. The other three are effort, and they land on the people who are already busiest.
• Four fields reliably fail to map: custom fields with free-text values, historic job and pay changes that were never dated, document categories, and approval or performance history.
• Time-off balances at cut-over are the hard problem. Cut over at the start of a leave year if you possibly can, because mid-year means reconstructing accrual history by hand.
• You will lose the ability to reproduce your old reports. That is not a defect, it is what changing data models means, and the fix is an export of canonical reports on the cut-over date.
• All costs here are expressed in effort rather than money, because implementation effort is the figure nobody publishes and the one that decides whether the project is worth it.
• Do not migrate for capability you have not committed to configuring. The most expensive outcome is paying the switching cost and reproducing what you had.

The Quote Was the Smallest Number

A company of 320 people compared two annual licence figures, found the difference manageable, and approved the move. The business case was one page and the number on it was the licence delta.

The project ran eleven weeks rather than six. Four of the extra five weeks went on data: 41 job titles that occurred exactly once, 23 people whose compensation history had been overwritten rather than dated, and a document library where everything from contracts to expense receipts sat in one category called Other. The fifth week went on time-off, because the cut-over had been scheduled for April and the leave year started in January, so every balance had to be reconstructed from three months of accrual the old system expressed as a single current figure.

Six months later the HR team was happy with the platform and could not reproduce a single report from before April. That last part had never appeared in the business case, nobody had decided to accept it, and it was discovered when a board pack asked for a twelve-month attrition trend.

Recommended Tools

Best tools for HRIS Software

B BambooHR HR management system L Lattice Performance management D Deel Global payroll & EOR

View all recommended tools

Nothing here was anybody's fault and none of it is specific to these two products. It is what a platform migration costs, and the reason it surprises people is that the only number published anywhere is the licence.

Why Companies Leave BambooHR

Worth being precise about, because the reason you are leaving determines whether the move is worth its cost.

The honest version is that BambooHR is very good at what it is and companies outgrow the shape of it rather than the quality of it. It publishes list pricing, which almost nothing else in this market does: read on 6 October 2026, Core is $10 per employee per month, Pro is $17 and Elite is $25, above 25 employees, with flat rates of $250, $425 and $650 per month at 25 employees and under.

Three reasons recur, and only two of them justify a migration.

Organisational structure. The company has acquired a structure that one reporting tree does not describe, usually functional and regional at once, or practices and squads alongside a formal hierarchy. This is a genuine structural limit and it does justify a move, because no amount of configuration makes a single hierarchy hold two.

Multiple entities, usually in other countries. The second or third legal entity turns entity from an attribute into a dimension, and that is a data model question rather than a feature question. Also a genuine reason.

It feels basic. This is the third reason and it is the one that produces regretted migrations. A platform feeling basic is often a statement about how it has been configured and how much of it is in use, and the company that moves for this reason tends to arrive somewhere more capable, configure it the same way, and have spent a quarter of its HR capacity to feel the same within a year.

Where HiBob is the usual destination, the draw is organisational modelling and the employee-facing experience at pace. It publishes no price at all, confirmed on its own site on 10 October 2026, so the licence side of your comparison is one published figure against a quote.

When You Should Not Migrate

When the complaint is configuration rather than capability

Before anything else, list what you are not using in the current platform and why. A surprising share of migrations are triggered by capability that exists and was never switched on, usually because the person who would have configured it left. Spending a week finding out is cheap against a quarter spent migrating.

When the real problem is a reporting definition

If two teams produce different headcount figures and that is the pain, a new platform will reproduce the disagreement faithfully. Publish one definition with a named owner, covering the population, the point in time and the awkward cases. Companies that do this sometimes discover the platform was adequate.

When you cannot name the work that will stop

Write one sentence: six months after launch, nobody will be doing X, Y and Z, which is N hours a week. If you cannot fill it in with named tasks and hours, the business case is a feature comparison and the project will be judged against expectations nobody wrote down.

When the next move is already visible

If you will need derived permissions across hundreds of managers, eight entities and audit-grade historic reporting within three years, you are heading for the enterprise tier and this is a staging post. Buying a staging post deliberately is a reasonable decision. Buying one by accident costs two migrations.

Five Questions People Ask First

"How long does it take?" Six to eight weeks is the figure usually quoted at this size and ten to twelve is the figure companies usually experience, and the difference is almost entirely data rather than product. A company that runs the data checks below before agreeing a date can commit to the shorter number honestly. One that agrees a date first will discover the cleansing work after the timeline is public.

"Can we migrate everything?" No, and planning as though you can is the main cause of overrun. Current-state data moves well. History moves partially, with the quality of the result depending on whether your history was dated in the first place. Documents move as files but usually lose their categorisation, and approval and performance history generally do not move at all in a usable form.

"Will we run both systems in parallel?" For a period, yes, and the question that matters is what you mean by parallel. Running both as systems of record is dangerous and produces two versions of every fact. Running the new one live while keeping the old one read-only for a defined period is safe and is what most companies should do. Decide which you mean before the project starts.

"Who does the work?" Some mix of your HR team, the vendor's implementation function and possibly a partner, and the part nobody can outsource is the decisions. Every mapping question is a decision about your own company, and the throughput of the project is limited by how quickly somebody with authority answers those rather than by anybody's technical capacity.

"What does it cost beyond the licence?" Effort, mostly, which is why this article expresses costs in weeks rather than currency. Expect the equivalent of several weeks of one experienced HR person, concentrated into a short period, plus whatever implementation fee appears in your quote. Any article giving you a currency figure for this is guessing, because it depends on your data and nobody else can see your data.

The Four Costs That Are Not the Licence

Data preparation

The largest and the most predictable, which is a useful combination because it means it can be measured before you commit. It is everything between the export and a file the new platform will accept: duplicates resolved, missing dates filled, job titles rationalised, entity assignments corrected, manager fields pointing at people who still work here.

This is your work and no vendor can do it, because every decision in it is a question about your company. Budget it as the single largest line and measure it first.

Mapping decisions

Smaller in hours and larger in elapsed time, because each one needs somebody with authority to decide and those people have other jobs. Where does this custom field go. Do we keep these eleven titles or collapse them to three. Which document categories survive. What do we do about the twenty-three people whose pay history was overwritten.

The reason this extends projects is queuing rather than effort. A decision that takes four minutes can take nine days to get, and a project with sixty such decisions and no standing slot to make them will drift by a month without anybody working slowly.

The parallel period

Two payroll cycles rather than one, where payroll is in scope, because one cycle proves the configuration and two proves it for the cases that only happen sometimes: a mid-month leaver, a backdated change, a bonus, somebody with two contracts. Three cycles is usually waste.

The cost is doing the same work twice for that period, which is exactly when the team is also doing the migration. This is the cost most likely to be underestimated, and the mitigation is to reduce scope elsewhere during those weeks rather than to assume the capacity exists.

Lost reproducibility

The one that is invisible until somebody asks for a trend. Your old reports will not reproduce in the new platform, because the data model is different and some of the inputs did not come across. This is not a defect and it is not avoidable; it is what changing systems means. It is avoidable to be surprised by it, which is what the section below is for.

The Fields That Do Not Map

Four categories, consistently, and knowing them in advance converts each from a surprise into a decision.

Custom fields with free-text values. Every company accumulates these and they are where institutional knowledge goes to be forgotten. A field called Notes containing twelve years of unstructured observations has no destination, because the new platform has no equivalent and creating one perpetuates the problem. The decision is whether the content is worth structuring, and the honest answer is usually that ten per cent of it is and the rest is history.

Historic job and pay changes that were never dated. If the old record held one current job title and one current salary, overwritten each time they changed, then the history does not exist to migrate. You can import a starting state and you cannot reconstruct what you never stored. This is the cost of not having effective dating, and it is paid at the moment you move to a platform that has it, which is a grim irony worth knowing about in advance.

Document categorisation. Files move. The metadata about them frequently does not, which turns a structured library into a flat one. For a company with contracts, right-to-work records, appraisals and expense receipts in one place, the practical answer is to categorise the important ones before migrating and accept flat storage for the rest, rather than attempting the whole library.

Approval and performance history. Who approved what and when, and the content of past review cycles. These are modelled differently by every platform and rarely come across in a form anybody can use. The usual and correct answer is to leave them in the old system, read-only, for a defined period.

So the practical step is to list your custom fields now, with a count of how many records have a value in each. Fields populated on four records out of 320 are not worth a mapping decision, and discovering that they are populated on four records takes one export and two minutes. Companies that do this arrive at the mapping conversation with a list of nine decisions instead of forty.

Time-Off Balances, Which Is the Hard One

If you read one section, read this one, because it is the single most common cause of a migration being harder than planned.

A time-off balance is not a number. It is the output of a rule applied to a period, and the two platforms will not express it the same way. The old system may hold a current balance with accruals applied monthly; the new one may hold an entitlement, a set of accrual events and a set of deductions. Importing a single figure into the second shape produces a balance that is correct today and wrong the moment the next accrual runs.

Four things make this manageable.

Cut over at the start of a leave year if you can. This is the whole answer where it is available. At the start of a leave year there is no accrual history to reconstruct, balances are entitlements, and the import is a single number per person that is correct by construction. Moving a go-live date by two months to achieve this is almost always worth it and almost never considered.

If you cannot, reconstruct rather than import. Take the entitlement, the accrual rule and the deductions since the leave year started, and compute the balance in the new platform's own terms. Do not import the old system's current figure and hope, because the first accrual in the new platform will apply to a base it did not calculate.

Deal with carry-over explicitly. Carried balances often have different rules and sometimes an expiry, and a platform that imports them as ordinary entitlement will not expire them. Decide how carried balance is represented before the import, not after somebody notices a balance that should have lapsed.

Check the output with the people it belongs to. Before go-live, show twenty people their own balance and ask whether it matches what they expect, weighted towards your non-head-office markets where local rules are most likely to have been applied by hand. This is the only test that uses knowledge the vendor does not have, it takes an afternoon, and it catches the errors that otherwise surface as individual complaints over the following months.

And resist the instinct to fix historic leave errors during the migration. Every company has a handful of balances that are wrong for reasons nobody remembers. Correcting them inside the project turns a data exercise into a set of conversations with individuals about their own entitlement, which is slow and emotive, and it makes any failure in the migration impossible to attribute.

The Reporting History You Lose

This is the cost with no mitigation in the new platform, so the mitigation happens before cut-over.

The mechanism is simple. Reports are built on a data model. Change the model and the report changes, even where the underlying facts are identical, because attrition depends on how transfers are counted, tenure depends on how rehires are treated, and headcount depends on which record types are included. Add in the history that did not migrate and your old numbers are not reproducible.

Three things to do, all of them before the old system is switched off.

Export the reports you actually rely on, as files, dated. Not the ones you might want, the five or six that reach a board or a leadership meeting. Run them at the cut-over date, export them, and store them somewhere other than the old platform. These become your historic record, and they are a perfectly respectable one.

Export the underlying data, not just the report. A report is a conclusion; the data behind it lets somebody answer a question you have not thought of yet. One flat export per report, stored alongside it.

Write down the definitions you were using. The definitions are the part nobody keeps, and without them the old numbers are uninterpretable in two years. One paragraph per metric saying what was counted and when.

Then decide, explicitly, how long the old system stays available read-only. Six months is common and twelve is defensible where performance or approval history matters. Name the date in the project plan with an owner, because a read-only system with no end date is a system you are still paying for in three years, and the licence is the smallest part of what that costs: as long as it exists, somebody will use it to check a number, and then you have two sources again.

How to Choose: Five Questions Before You Commit

What are the five checks on your own data telling you? Export your employee list with every field and count: duplicate people, people with no start date or two, job titles occurring exactly once, blank or wrong entity assignments, and manager fields pointing at people who have left. Those five counts predict your timeline better than any implementation methodology, and they take under an hour.

Can you cut over at the start of a leave year? If yes, plan around it even at the cost of delay. If no, add a week to the plan and assign the reconstruction to somebody specific, because it is the task most likely to be discovered late.

How many custom fields have more than a handful of values? This is your mapping decision count. Under ten and the mapping conversation is an afternoon. Over thirty and it is a work stream that needs a standing decision slot with somebody who has authority.

Which reports reach a board or a leadership meeting? List them. These are the ones to export, with their data and their definitions, and the list is almost always shorter than people expect, which makes this the cheapest item in the whole project.

What work will have stopped six months later? The sentence from earlier, with named tasks and hours. If it cannot be written, the honest conclusion is not to migrate yet, and that conclusion is worth more than a project.

The Cost Table

The Decision Table

Sequencing the Cut-Over

The order matters more than the duration, and this is the sequence that avoids the two expensive failures, which are running two systems of record and discovering data problems after a date is public.

Weeks one and two: export and measure. Before any configuration, run the five data checks and the custom field count. Publish the numbers internally. This is the only point at which the timeline can still be set honestly, and a company that skips it is committing to a date on the basis of nothing.

Weeks two and three: decide the mapping. Book one standing hour a week with somebody who can decide, and bring batched questions to it. Resolve the custom fields, the job titles, the document categories and the history that will not move. Write each decision down, because the same question will be asked again during testing by somebody else.

Weeks three to five: cleanse, and only what you decided to cleanse. The instinct to fix everything is what consumes timelines. A known, flagged inconsistency carried across is manageable. An unknown one surfaces in a board report.

Week five: export the reports, their data and their definitions. Before anything is switched off and while the old system is still authoritative. This is an afternoon and it cannot be done later.

Weeks six and seven: configure and load, then check balances with people. Show twenty people their own leave balance, weighted towards non-head-office markets, and act on what they say.

Weeks eight and nine: parallel payroll, cycle one and cycle two. Both, not one. Treat cycle one as proving the configuration and cycle two as proving the exceptions.

Week ten: the old system becomes read-only, with a named switch-off date. Not a vague intention. A date, an owner, and a note of what has to be true before it passes.

And do not redesign any process during this. Every migration surfaces a dozen processes that are obviously wrong, and fixing them inside the project doubles the scope and makes failure impossible to attribute. Write them on a list and fix them in the quarter afterwards, when the platform is stable and the capacity has returned.

Running the Week That Might Cancel the Project

This article says twice that a week spent checking whether the limit is configurational is cheaper than a quarter spent migrating, so here is what that week contains. It is the highest-return work in the whole decision and it is almost never done, because it has no obvious owner and it might produce an unwelcome answer.

Day one: list every module and feature you are paying for and mark each used, partly used or unused. Not from the sales material, from your own admin interface. Most companies find between three and six things in the unused column, and at least one of them is the capability the migration is being proposed to obtain.

Day two: for each unused item, write one sentence saying why. There are only four answers and they lead different places. Nobody configured it, which is a capacity problem and is fixable. It was configured and abandoned, which is a process problem and will recur in any platform. It does not do what we need, which is the only answer that supports a migration. Or nobody knew it was there, which is a vendor relationship problem and the cheapest of all to fix.

Day three: take the two or three things in the fourth category and switch them on. Genuinely, in production, with one team. A week is enough to know whether a reporting module or an approval workflow addresses the complaint, and the answer is binary in a way no demo is.

Day four: ask the people who complain what specifically they cannot do. Three managers, two members of the HR team. Ask for tasks rather than opinions. Half the answers are usually about something the platform does and the person has not found, which is a documentation and training problem that no migration solves and every migration makes worse for six months.

Day five: write the one-page conclusion. Which complaints are structural, which are configurational, and what proportion of the stated pain would survive a week of configuration work by somebody competent.

Because the honest outcome of this week is sometimes that the migration is unnecessary, it needs a sponsor who is willing to accept that answer. And if the outcome is that the limit is structural after all, the week is not wasted: you now have a specific list of what the new platform must do, which is exactly the written requirement the next section of the project needs and the thing most evaluations never produce.

What Getting This Wrong Costs

The visible cost is the overrun, and at this size it is a few weeks of a small team.

The second cost is reproducing what you had. A company that migrates for capability and then configures the new platform the way the old one was configured has paid the full switching cost for the same experience. This happens for a reason that is entirely understandable: the capacity to configure something new is consumed by the migration itself, and by the time it returns the urgency has gone. The mitigation is to name the two or three capabilities the move is for, and to put them in the plan as deliverables with dates rather than as benefits.

The third is losing the trend. A company that cannot produce a twelve-month series for headcount, attrition and tenure cannot answer the question a board asks most often, and the gap persists until twelve months of new data exists. So the first year after a migration is a year of thin reporting unless the exports were taken, and the exports cost one afternoon that is only available before cut-over.

And the reframing question, which is worth more than the licence comparison: what will somebody be able to do in nine months that they cannot do now, and who has committed to configuring it? If the answer to the second half is nobody in particular, the project will deliver a platform change and not a capability change, and the licence difference is then the only thing you have bought.

When You're Ready to Move

The honest position is that outgrowing a platform is structural and feeling constrained by one is often configurational, and the two are hard to tell apart from inside.

Two markers separate them. The first is whether a single reporting hierarchy describes your company, which is a factual question you can answer on paper in ten minutes. The second is your entity count now and in two years, which follows from a plan rather than from growth. If one hierarchy does not describe you, or you are heading for three entities, the limit is structural and a migration is justified. If neither is true, the limit is probably how the current platform has been set up, and a week spent finding out is the cheapest action available.

The sequence that works starts before any vendor conversation. Run the five data checks and publish the counts. Count the populated custom fields. List the reports that reach a board. Establish whether a leave-year cut-over is possible. Write the sentence about what work will stop, with hours.

Do that and you can commit to a date honestly, you will know your mapping decision count before anybody asks for one, and you will have the exports that make the first year's reporting possible. In a market where one vendor publishes a figure and the other does not, the licence comparison is the part of this decision you can finish in an afternoon. The rest is the project, and the project is what the migration actually costs.

Frequently Asked Questions

HROpsLab takes no vendor money and publishes no paid placements, which is why the costs here are given in effort rather than as a currency figure nobody can verify.