TL;DR
- Three things break between 200 and 500 people, and none of them is a missing feature. They are permissions, reporting definitions and concurrent work.
- The signal that you have outgrown a platform is not slowness. It is two people producing different headcount figures from the same system and both being right.
- At this size the HR team stops being generalists. The platform has to support several people working in different parts of it at once, with different access.
- List pricing mostly disappears above a few hundred employees, so budgeting shifts from reading a page to running a negotiation. One vendor here still publishes figures and its natural ceiling is below you.
- Multiple legal entities, not headcount, is what actually forces the move for most companies. Check how many you will have in two years, not today.
- A migration at this size is a two-quarter project with a parallel period. Companies that plan it as a configuration exercise are the ones that end up running two systems for a year.
Nobody Could Agree on the Headcount
A company at 480 people went into a board meeting with three headcount figures. Finance had 468, the HR platform reported 491, and the people team's own weekly sheet said 474.
None of them was wrong. Finance counted people on payroll at the end of the previous month. The platform counted active employee records on the day the report was run, which included eleven people who had accepted offers and been set up early. The weekly sheet excluded a team of contractors who had been converted to employees three weeks earlier and had not been added because the person who maintained the sheet was on leave.
The problem was not accuracy, it was that the company had three definitions of headcount and no agreement about which one was the headcount. At 200 people this never came up, because one person produced every number and their definition was the definition. At 480 the question had four stakeholders and the platform had no opinion, so each team used the one that matched their own system.
Best tools for HRIS Software
That is what crossing 500 actually looks like. It is rarely a capability wall. It is the point at which informal agreements that worked when everybody knew each other stop holding, and a system that was happy to answer any question becomes a system that answers the same question three ways.
What Actually Breaks at 500
Three things, in roughly this order.
Permissions. At 200 people, HR sees everything and that is fine, because HR is three people who all know each other and each other's work. At 500 the HR function has specialists, there is a payroll person who should not see performance ratings, there is a recruiter who needs the org chart and nothing else, and there are 60 line managers whose access needs to follow their reporting line and change when it does. Platforms built for the smaller company have a handful of roles and an all-or-nothing admin level, which forces a choice between giving people too much access and doing their work for them.
Reporting definitions. The headcount problem above, repeated for every metric that matters. Attrition, which depends on whether you count people who moved between entities. Time to hire, which depends on when the clock starts. Average tenure, which depends on how rehires are treated. Each needs one owner and one definition, and the platform has to be able to express it rather than requiring a spreadsheet after every export.
Concurrent work. At 200, the HR team works sequentially and informally. At 500 two people are running a salary review and an onboarding wave in the same week, in the same system, and the question of who changed what becomes real. Platforms with a weak audit trail and no concept of draft or approval states make this unmanageable, and the symptom is that the team starts doing the work in spreadsheets and uploading the result.
What does not break, and gets blamed anyway: speed, self-service, and the quality of the employee-facing experience. Mid-market platforms are generally better at those than the enterprise products companies move to, which is why the migration frequently makes the employee experience worse while making the operational one possible.
| What breaks | First symptom | What a weak platform does |
|---|---|---|
| Permissions | A manager can see something they should not | Offers a handful of fixed roles and one admin level |
| Reporting definitions | Two teams produce different headcount | Exports and leaves you to define it in a sheet |
| Concurrent work | The team starts working in spreadsheets again | No draft states, thin audit trail |
| Multiple entities | Payroll is run from a separate system per country | Treats entity as a text field on the record |
| Historic reporting | Last quarter's report changes when re-run | Applies the current structure to a past period |
When You Should Not Move Yet
When the current platform is genuinely fine
If you are at 450 people in one country, one legal entity, with an HR team of four who are not fighting the system, do nothing. Headcount alone is a poor trigger and the vendors that use it as one have an obvious interest. The cost of a migration at this size is a quarter of HR capacity at minimum, and spending it to pre-empt a problem you do not have is a bad trade.
When the complaint is a reporting problem
A surprising share of platform complaints at this size are definitional rather than technical. If the actual pain is that nobody agrees what headcount means, a new platform will reproduce the disagreement faithfully. Fix the definitions first, in writing, with one named owner per metric. Several companies that do this discover the platform was adequate.
When the complaint is one missing integration
One broken or absent integration is almost never a reason to replace a platform. It is a reason to build the integration, which is cheaper than a migration by an order of magnitude. The exception is when the platform has no usable interface to build against at all, which is worth confirming rather than assuming.
The edge case that does force it
A second or third legal entity, especially in another country. This is the trigger that actually justifies a move at this size, because an entity is not a field, it is a different payroll, a different set of employment terms and frequently a different reporting line into the parent. Platforms that model it properly are a different tier of product from platforms that store it as an attribute, and you find out which you have during your first multi-entity salary review.
Five Questions People Ask First
"Is there a headcount at which you have to change?" No, and the number quoted at you will usually be just below your own. The real triggers are entity count, the number of distinct permission profiles you need, and whether your reporting has to reconstruct past states. A company at 800 people in one entity with simple reporting can stay on a mid-market platform comfortably. A company at 250 across four countries frequently cannot.
"Will the employee experience get worse?" Often, yes, and it is worth saying out loud during the business case rather than discovering it at launch. Mid-market platforms compete on self-service and interface quality; enterprise platforms compete on configurability and depth. The move buys you operational capability and costs you some polish, and pretending otherwise is how a project loses the goodwill of the people who have to use it.
"How long does a migration take?" Two quarters is a realistic floor at this size for a platform change with payroll attached, and that assumes a parallel period. The elapsed time is dominated by two things nobody plans for: data cleansing, which surfaces every historic inconsistency you have, and the decisions about process that the configuration forces you to make and that have never been written down.
"What does it cost?" This is the question the market stops answering at this size. Below a few hundred employees there are published prices. Above it, almost every vendor quotes, and the quote depends on module mix, term length, headcount banding and how your financial year lines up with their sales quarter. Budget for the implementation partner as a line item of the same order as the first year of licence, because that is where the figure usually lands.
"Can we keep our current platform for part of this?" Sometimes, and it is underused. Keeping a well-liked mid-market platform for recruitment or performance while moving the core record elsewhere is a legitimate architecture. The cost is another integration and another system of record question, so it is worth doing deliberately rather than as the residue of a half-finished migration.
The Three Routes Out of Mid-Market
Stay and extend
Keep the platform, build the integrations, accept the permission model and solve reporting outside it with a warehouse or a reporting tool. Right when the platform's limits are reporting and integration rather than structure. It fails when the limit is the data model itself, because no amount of downstream reporting fixes a system that cannot represent two entities or reconstruct a past state.
Move up within the same tier
Replace one mid-market platform with a more capable one. Right when the current product has a specific structural gap that a peer handles well, usually multi-entity or organisational modelling. It fails when the company is really heading for enterprise requirements in two years, because this buys about three years and costs a full migration to do it.
Move to enterprise
Replace with a platform built for complexity, accepting a longer project, an implementation partner and a worse interface. Right when entity count, historic reporting and permission granularity are all problems at once, or when finance already runs the same vendor. It fails when it is bought on headcount alone, which is how a 500-person company ends up with a platform configured for 5,000 and an HR team that cannot change anything without a consultant.
Because the second and third routes both cost a full migration, the decision between them is about where you will be in three years rather than where you are. So the question to answer first is the entity count, which is the one input that reliably predicts which tier you need and the one most companies can forecast accurately.
The Headcount Definition Problem
This section is the cheapest fix in the article and the one most likely to be skipped, so it goes before the vendor list rather than after it.
Write down one definition of headcount and publish it. Not three definitions with footnotes, one definition, with a named owner, in a place other teams can read. It should state the population, the point in time and the treatment of the awkward cases.
The population. Employees only, or employees plus contracted individuals who work as part of a team? Companies that exclude contractors and then plan capacity including them produce a headcount that no operational team can use.
The point in time. The last day of the month, the first, or the day the report is run. Any of the three is defensible. Running reports on the day they are needed and comparing them across months is not, because a company hiring steadily will show growth that is partly an artefact of which day of the month the board meeting fell on.
The awkward cases, each decided once. People who have accepted an offer and not started. People on long-term leave. People serving notice. People who moved between entities, which is the one that breaks attrition figures most often, since a transfer looks like a leaver in one entity and a joiner in another and counting both inflates turnover.
And then do the same for the three or four metrics that reach the board, because headcount is only the one that gets noticed. Attrition, time to hire and average tenure each have the same shape of ambiguity, and each is worth about an hour to settle permanently.
| Metric | The ambiguity that matters | Decide once |
|---|---|---|
| Headcount | Point in time, and offer-accepted starters | Month end, employees plus named contracted individuals |
| Attrition | Inter-entity transfers counted as both leaver and joiner | Exclude transfers, report them separately |
| Time to hire | When the clock starts, requisition or first interview | Requisition approved, stated on the report |
| Average tenure | How rehires are treated | Most recent start date, with rehires flagged |
Permissions, Delegation and the Acting Manager
The permission model is the part of this decision that gets the least attention during evaluation and causes the most friction afterwards.
Three requirements appear at this size and are absent from most products built for smaller companies. Access that follows the reporting line automatically, so a manager's view changes when their team changes and nobody has to remember to update it. Delegation, so a manager on leave can hand approvals to somebody for a defined period without that person inheriting the rest of their access. And an acting-manager concept, for the three months after somebody leaves and before their replacement starts, which is a situation every company at this size is permanently in somewhere.
The test to run in a demo takes five minutes and almost nobody runs it. Ask to see a manager's view, then move one person out of their team in the admin interface, then look at the manager's view again without any other action. A platform that handles this will show the change immediately. One that does not will reveal that permissions are assigned per user rather than derived, which means somebody maintains them by hand forever.
Then ask the delegation question as a scenario rather than a feature: a director is on leave for three weeks during a salary review, approvals must continue, and the person covering should not see the director's own compensation. If the answer involves sharing credentials or temporarily promoting somebody, that is the real answer.
How to Choose: Five Questions Before You Talk to Any Vendor
How many legal entities will you have in two years? The single most predictive question, and the one most companies can answer well because entity creation follows from a plan rather than from growth. One entity means you have options. Three or more, particularly across borders, narrows the field sharply and moves the decision towards platforms where entity is structural.
How many distinct permission profiles do you need? Count them properly: every HR specialism, every manager level with different rights, finance, payroll, recruiters, and anybody external. Companies at this size usually find between eight and fifteen. If your current platform offers four, that is a concrete limit rather than a complaint, and it is the kind of evidence a business case needs.
Does any report have to reconstruct a past state? If the board or an auditor asks for a figure as at a date, you need effective dating. If every question is about now, you do not, and you can discount a whole tier of product. This question alone separates the companies that need enterprise capability from the ones that are being sold it.
Who owns each number that reaches the board? If the answer is that HR produces it and finance checks it and they sometimes differ, fix that before buying anything. A platform migration will carry the ambiguity across intact, and you will have spent two quarters to arrive at the same argument in a more expensive system.
What are you willing to lose? Every move up costs something: interface quality, speed of change, the ability for an HR generalist to configure something without help. Decide which of those you can afford to give up and say so in the evaluation, because it is the honest version of the requirements document and it stops the project being sold on capability alone.
The Options
A note on pricing. One vendor below publishes list figures and its natural ceiling sits under 500 people, which is the shape of this market: published prices exist mainly where you are leaving, not where you are going. Dates are given for every figure and every confirmation, because this is the part of a comparison that goes stale fastest.
BambooHR
Best for the company you are, not the one you are becoming. Included here because it is where a large share of 500-person companies are arriving from and because it is the only published price point available for comparison.
Read on 6 October 2026: Core at $10 per employee per month, Pro at $17, Elite at $25, above 25 employees, with flat rates of $250, $425 and $650 at 25 and under. A bundle discount and a nonprofit discount are published alongside.
Where it struggles at this size: the permission model, multi-entity structure and historic reporting are all thinner than what a 500-person company with any complexity needs. It remains excellent at what it is, which is a clean, fast, well-adopted HR record for a simpler organisation, and companies leaving it usually miss the interface.
HiBob
Best for companies between roughly 100 and 1,000 people that want to keep a modern employee experience while gaining organisational depth.
The strongest reason to shortlist it at this transition is organisational modelling. It handles structures that are not a single clean hierarchy, which is the thing that defeats products assuming one reporting tree, and it does so without the implementation weight of an enterprise platform.
Where it struggles: it publishes no price, confirmed on its own site on 10 October 2026, so the comparison requires a sales process to produce a number. Its depth in payroll and in heavily regulated multi-country operations is below the enterprise tier, so a company heading for eight entities should test that specifically rather than assume it.
Personio
Best for companies whose headcount is concentrated in Europe and who want local payroll and compliance handling inside the HR platform.
The reason it reaches shortlists at this size is the breadth of local handling across European markets, which is a genuine differentiator against products designed primarily around one market and extended outwards.
Where it struggles: its pricing page did not return a readable figure when we checked on 10 October 2026, so treat it as quote-based and ask directly. Companies with significant headcount outside Europe should test the coverage claim entity by entity rather than taking a map at face value.
Rippling
Best for companies willing to consolidate HR, payroll, device management and application access into one platform, which is a larger decision than choosing an HRIS.
The consolidation case is real and is strongest exactly at this size, because 500 people is where the cost of running separate HR, payroll and IT provisioning systems becomes visible and where the integrations between them start needing an owner.
Where it struggles: it no longer publishes a price. Checked on 6 October 2026, its pricing page is a quote request form asking which services you need, with no currency figures on it anywhere. Comparisons still quoting a per-user figure for Rippling are repeating a number that is no longer on the vendor's site, which is worth knowing when a shortlist is assembled from third-party content.
Workday
Best for companies above roughly 1,000 people, or smaller ones where finance leads the decision or already runs the same vendor for financials.
The relevant strengths at this transition are the three things that break at 500: permissions are derived and granular, effective dating is core to the data model rather than an add-on, and multiple entities are structural. If all three are problems at once, this tier exists for exactly that situation.
Where it struggles: cost and elapsed time, neither published. It is a project with a partner attached, and a 500-person company buying it without a clear multi-entity or historic-reporting requirement usually finds the configuration overhead exceeds the benefit. It prices on request.
SAP SuccessFactors
Best for companies already inside a wider SAP estate, where the integration with existing finance and master data outweighs the HR module's standalone merits.
Comparable to Workday on organisational depth, effective dating and permission granularity, and the better answer when the surrounding systems are already from the same vendor.
Where it struggles: it is the least likely to be the right answer for a company choosing on HR merit alone, and the implementation expectation is a configuration programme rather than a setup. It prices on request.
Paycor
Best for companies whose complexity is concentrated in United States payroll, with hourly and salaried populations mixed, rather than in multi-country structure.
Strong where the real administrative load is payroll, tax and compliance in one country, which describes a meaningful share of companies at this size and is often mis-specified as an HRIS problem.
Where it struggles: less suited to multi-entity international structure, which is the most common forcing function at this headcount. It prices on request.
The Comparison
| Platform | Publishes a price | Permissions follow the org | Effective dating | Multi-entity | Natural fit at 500 |
|---|---|---|---|---|---|
| BambooHR | Yes, list pricing | Limited | Limited | Attribute, not structural | Below this size |
| HiBob | No | Yes | Good | Good | Strong |
| Personio | Not readable when checked | Yes | Good | Good, European focus | Strong in Europe |
| Rippling | No, quote form only | Yes | Moderate | Good | Strong if consolidating |
| Workday | No | Derived and granular | Core to the product | Structural | Capable, often early |
| SAP SuccessFactors | No | Derived and granular | Core to the product | Structural | Capable, often early |
| Paycor | No | Moderate | Moderate | Limited | Strong for US payroll |
Two columns do the work here. The first tells you that your evaluation is a negotiation rather than a comparison, and should be planned with that elapsed time in it. The last two tell you whether your forecast entity count puts you in the middle three rows or the two below them.
The Decision Table
| Situation | Scale | Setup | Primary Pain | Recommended Starting Point |
|---|---|---|---|---|
| One entity, one country, HR team not fighting the system | 450 to 800 | Current platform plus integrations | Nothing structural | Stay. Fix reporting definitions instead |
| Two teams produce different headcount | Any | One published definition per metric | Definitional, not technical | Write the definitions before any demo |
| Second or third legal entity arriving | 300 plus | Platform where entity is structural | Entity stored as a field | HiBob or Personio, or enterprise if more follow |
| Managers can see things they should not | 400 plus | Derived, org-following permissions | Permissions assigned per user by hand | Test the move-a-person demo on every shortlist |
| Board or auditor asks for figures as at a date | Any | Real effective dating | Historic reports change when re-run | Test a past-dated report before shortlisting |
| Separate HR, payroll and IT provisioning systems | 300 to 1,500 | Single consolidated platform | Integration maintenance with no owner | Rippling, scoped as a consolidation project |
| Finance already runs a major ERP | 500 plus | Same vendor, HR as a module | Two systems disagreeing on the org | The incumbent, with the HR interface tradeoff stated |
| Complexity is US payroll, not structure | Any | Payroll-led platform | Tax and compliance admin | Paycor, scoped as a payroll project |
Running the Migration Without a Parallel Year
Everything above is about choosing. This is the part that decides whether the choice works, and it is where companies at this size lose a year.
The failure mode is specific. A company plans a migration as a configuration exercise, discovers during data preparation that fifteen years of records contain inconsistencies nobody knew about, extends the timeline, launches late with both systems live, and then keeps both running because nobody will sign off switching the old one off while any report still depends on it. Two systems at 500 people is worse than either system alone, because every number now has two sources.
Four things prevent it.
Cleanse before you configure, and timebox it. Run the data extract early, in the first three weeks, and look at it. Expect duplicate records, people with two start dates, job titles that exist once, and entity assignments that were never correct. Decide which categories you will fix and which you will carry across as-is with a flag, because the instinct to fix everything is what consumes the timeline. A known, flagged inconsistency is manageable; an unknown one surfaces in the first board report.
Decide the cut-over for history separately from the cut-over for transactions. These are different decisions and merging them is the most common planning error. You can move all live transactions on one date while leaving historic records in a read-only copy of the old system for a defined period. That is a far smaller project than migrating twenty years of history, and for most companies the historic data is consulted a handful of times a year.
Name the date you turn the old system off, before you start. Put it in the plan as a commitment with an owner, not as a consequence of everything else going well. Companies that leave it implicit run two systems indefinitely, and the licence cost is the smallest part of what that costs.
Run payroll in parallel for two cycles, not one. One cycle proves the configuration. Two proves it for the cases that only occur sometimes, which is where payroll errors live: a mid-month leaver, a backdated change, a bonus, somebody with two contracts. Three cycles is usually waste.
And resist the urge to redesign processes during the migration. Every migration surfaces a dozen processes that are obviously wrong, and fixing them inside the project doubles its scope and makes any failure impossible to attribute. Write them down, ship the migration, fix them in the quarter after.
What Getting This Wrong Costs
The visible cost is the project overrun, and it is the least of it.
The second cost is that the HR team stops using the system for the work that matters. When permissions are too coarse and concurrent work is unmanageable, people do salary reviews and headcount planning in spreadsheets and upload the outcome. The platform becomes a record of decisions made elsewhere, which means the audit trail is a record of uploads, the reporting is as good as the spreadsheet, and the capability you bought is not being used. This is extremely common and it is almost never reported as a problem, because every individual instance is a reasonable workaround.
The third is the one that shows up in a board pack. A company that cannot produce a reliable headcount series cannot produce a reliable cost-per-head series, an attrition trend or a plan. So the planning conversation moves to estimates, and the first time somebody tries to model two scenarios properly, the data to do it does not exist in a form anybody trusts.
The reframing question: if your board asked for headcount, attrition and average tenure as at the end of each of the last eight quarters, could you produce it in an afternoon from one system, and would finance agree with every figure? Most companies at this size cannot, and the gap between that and a platform feature list is where the real decision lives.
When You're Ready to Move Beyond Your Mid-Market Platform
The honest position is that headcount is the worst trigger available and the one most used, because it is the only one that is visible to everybody and arrives on a schedule.
The transition that actually matters is structural, and there are three markers. The first is the second legal entity, which turns an attribute into a dimension. The second is the point at which permissions have to be derived rather than maintained, which arrives at somewhere between eight and fifteen distinct profiles. The third is the first time somebody asks for a number as at a past date and you cannot produce it.
One of those is a reason to look. Two is a reason to move. None of them, at any headcount, is a reason to start a project.
The sequence that works costs almost nothing and does not start with a vendor. Publish one definition of headcount and the three other metrics that reach the board, with an owner each. Count your distinct permission profiles and compare the number against what your current platform offers, which turns a complaint into evidence. Forecast your entity count two years out. Run the move-a-person permission test and the past-dated report test against your current system, so you know which of the three markers you have actually hit.
Then go to vendors with that, and with the one thing you are willing to give up. You will get a shorter evaluation, a defensible business case, and in a market where almost nobody publishes a price, a much better position from which to ask for one.
Frequently Asked Questions
At what headcount do you have to change HRIS?
There is no such number, and the one quoted at you tends to sit just below your own. The triggers that genuinely force a change are structural: a second or third legal entity, needing more distinct permission profiles than the platform supports, and having to report a figure as at a past date. A company at 800 people in one entity with simple reporting can stay where it is comfortably, while a company at 250 across four countries frequently cannot, which is why entity count predicts this better than headcount.
What breaks in an HRIS at 500 employees?
Three things, and none of them is a missing feature. Permissions, because HR stops being a few generalists who can all see everything and becomes specialists who should not. Reporting definitions, because more than one team now produces the same metric and their definitions differ. And concurrent work, because two people running a salary review and an onboarding wave in the same system in the same week need draft states and a real audit trail. The usual symptom of the third is that the team quietly moves the work into spreadsheets.
How long does an HRIS migration take at this size?
Two quarters is a realistic floor for a platform change with payroll attached, assuming a parallel period of two payroll cycles rather than one. The elapsed time is dominated by data cleansing, which surfaces every historic inconsistency the company has accumulated, and by process decisions the configuration forces you to make that have never been written down. Plan the date you switch the old system off before you start, because leaving it implicit is how companies end up running two systems for a year.
Which HRIS platforms publish their pricing?
Very few at this size, and that is the defining feature of the market. BambooHR publishes list pricing on its own site, read on 6 October 2026, and its natural ceiling sits below 500 people, so the one published price point available for comparison belongs to the tier you are leaving. HiBob, Rippling, Workday, SAP SuccessFactors and Paycor all quote on request, and Rippling's pricing page is now a quote request form with no currency figures on it at all. Personio's page did not return a readable figure when we checked on 10 October 2026. Budget for an evaluation measured in months rather than weeks, because six parallel sales processes set the timeline.
Is Workday worth it for a 500-person company?
Sometimes, and it is bought too early more often than too late. It is the right answer when derived granular permissions, real effective dating and structural multi-entity support are all requirements at once, or when finance already runs the same vendor for financials. It is the wrong answer when it is chosen on headcount alone, because a 500-person company then carries the configuration overhead of a platform designed for ten times its size and an HR team that needs help to change anything.
Will the employee experience get worse after moving up?
Usually a little, and it is better to say so in the business case than to discover it at launch. Mid-market platforms compete on self-service and interface quality, while enterprise platforms compete on configurability and depth, so the move buys operational capability and spends some polish. The practical mitigation is to decide in advance which experience you are willing to trade, state it in the evaluation, and avoid selling the project internally on an improvement that is not going to arrive.
Should we fix our reporting before changing platforms?
Yes, and it is the cheapest useful action available. Publish one definition of headcount with a named owner, covering the population, the point in time and the awkward cases, then do the same for attrition, time to hire and average tenure. It takes a few hours per metric. A meaningful share of platform complaints at this size turn out to be definitional, and a migration will carry the ambiguity across faithfully into a more expensive system.
HROpsLab takes no vendor money and publishes no paid placements, which is why the vendors that decline to publish a price are named as declining rather than quietly left out of the comparison.
