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.
- $499median advertised EOR price, per employee per month
- 7vendors with a verified published price
- 8hiring markets with measured demand
Figures on this page come from the EOR Compass Pricing Index: 7 vendors with a verified published price, median $499 per employee per month, checked against each vendor's own pricing page.
- 7 vendor price pages verifiedevery figure matched verbatim to the vendor's page
- Quoted and dated, never estimatedlast verification pass 2026-08-18
- 8 hiring markets coveredcoverage evidenced by vendors' own country pages
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 advertised EOR price per employee per month in the EOR market was $499 in August 2026, across 7 verified vendor price pages recorded in EOR Compass Pricing Index.
Cite as: "EOR Compass Pricing Index", updated 2026-08-18, https://eorcompass.com/hr-payroll/hris-implementation/.