Hris implementation: the hris implementation steps that decide whether a go live is quiet or expensive
Hris implementation fails in predictable places, and none of them is the software. It fails on data nobody had looked at closely, on a permission model agreed in a meeting and never tested, and on a cutover date chosen for the finance calendar rather than for the payroll one. A plan that treats those three as the project rather than as risks tends to land quietly.
- 6 USDMedian published figure, HR Payroll Software Pricing Index
- 14Published figures
- 20 of 52Sources read that publish one
Figures on this page come from the EOR Compass HR Payroll Software Pricing Index: 20 of the 52 source pages read in full publish a price, and the median published figure is 6 USD across 14 of them, each quoted from its own page.
- 52 source pages read in full20 publish a figure; the rest are recorded as publishing none
- Quoted verbatim and datedevery figure read from its source's own page, last read 12 October 2026
Hris implementation steps in the order that works
- Extract and read your own data first. Before any configuration, pull the current record and read it. Duplicate people, impossible dates, leavers still marked active. Every hour spent here removes a day later, and it happens before the vendor clock starts.
- Agree the permission model on paper. Write down what each role can see and change, including the awkward cases: a manager of managers, a contractor, somebody on a performance process. Agree it before configuration, because changing it afterwards means retesting everything.
- Configure against real cases, not sample data. Use your own awkward employees in the build environment. Sample data never contains the two contract case, which is exactly the one that will break the payroll export.
- Run one full cycle in parallel. Where payroll is in scope this is not optional. One full period calculated in both systems and reconciled to the penny is the only test that compares the new configuration against a known answer.
- Cut over between periods, never inside one. Pick a date that falls cleanly between pay periods and after any statutory reporting deadline. A cutover mid period creates a reconciliation nobody has a procedure for.
The point of no return
There is one moment in an implementation after which reversing is a project rather than a decision: the moment the old system stops being updated. Everything before it is reversible at the cost of some wasted effort. Everything after it commits you to fixing forward.
Name that moment in the plan and make the go or no go decision at it explicitly, with the parallel run reconciliation in front of the people deciding. Projects that drift past it without a decision are the ones that end badly.
History, and how much of it to bring
Loading every year of history is expensive and often unnecessary. What is necessary is enough to answer the questions you are legally and practically obliged to answer, which usually means current terms, service dates, and the retention period for pay and absence records.
Everything older can stay in a read only archive of the old system provided somebody can still open it. Write down where it is and who has access, because that note is the thing nobody can find three years later.
Training that survives the first month
Training delivered two weeks before go live is forgotten by go live. Training delivered in the first week of use, on the real system with real records, sticks. Budget for the second kind and treat the first as an introduction rather than as training.
Managers need a different session from the HR team and a much shorter one. If a manager cannot approve an absence request without a manual, the configuration is wrong and no amount of training will fix it.
Common questions
- How long does an hris implementation take?
- For a mid sized employer with clean data and no payroll in scope, a few weeks of configuration and a few more of testing. With payroll in scope, add a full parallel cycle, which sets a floor of one pay period and usually two.
- Can we skip the parallel run?
- Only where payroll is out of scope. Where it is in scope the parallel run is the only comparison against a known correct answer, and skipping it moves the discovery of errors to the payslips.
- Who should own the project internally?
- Someone who can decide, not someone who can only report. Most delays are decisions waiting for an owner, particularly on permissions and on which historical data to bring.
- What should be in the vendor statement of work?
- Named integrations, the number of years of history loaded, the number of custom reports, the test environments provided, and what triggers additional charges. Those five cover most disputes.
Get a shortlist for your hiring plan
Coverage by country
- Employer of record vendors covering Singapore
- Employer of record vendors covering Mexico
- Employer of record vendors covering Spain
- Employer of record vendors covering Colombia
- Employer of record vendors covering United Kingdom
- Employer of record vendors covering France
- Employer of record vendors covering Hungary
- Employer of record vendors covering New Zealand
Sources
Cite or embed this figure
The median published figure in the HR Payroll Software Pricing Index is 6 USD across 14 sources' own pages in USD (range 2 to 10 USD; 20 sources publish a figure), read 12 October 2026.
20 of the 52 named sources read in full publish a figure; 32 publish none, read 12 October 2026.
Cite as: "EOR Compass HR Payroll Software Pricing Index", updated 2026-10-19, https://eorcompass.com/hr-payroll/hris-implementation/.