HR technology projects rarely fail on the technology. They fail on scope nobody fixed, data nobody cleaned, and adoption nobody owned after go-live.
All three belong to HR, and none of them can be handed to IT or the vendor.
Who owns the project?
Someone in HR, by name, with time protected for it. A project owned by a committee is owned by nobody, and a project owned by IT optimises for the install rather than the use.
The vendor runs the setup. The owner decides what good looks like and says no to scope that does not serve it.
What has to be decided before setup starts?
- Which states you operate in, and the rules each one brings
- Leave policy, including accrual, carry-forward caps and encashment
- Shift patterns, overtime rules and holiday calendars per location
- Salary structure and which components are legal
- Who approves what, at which level
Every one of these is a policy decision, not a software setting. Firms that start setting up before deciding end up encoding whatever the previous spreadsheet did.
Why is data migration the real risk?
Because it carries years of built-up error. Leave balances that drifted, salary structures with one-off tweaks, and KYC that never matched.
Migrate clean data or clean it during migration. Importing a bad balance means arguing about it for a year, and the employee will remember the number from the old system.
What does a parallel run prove?
That the legal engine produces the same answer as your current process, on your real data.
PF at 12% with a 15,000 wage ceiling, ESI at 3.25% employer and 0.75% employee up to 21,000, and legal bonus between 8.33% and 20% all have to reconcile to the rupee. Rules sit with the Employees Provident Fund Organisation and the Employees State Insurance Corporation.
Run one or two cycles twice. A vendor who resists quoting for it is telling you something.
What does HR owe employees during the change?
Notice, a reason and a working alternative. A payslip that arrives from a different system with no warning generates more tickets than any feature saves.
Benefits cover matters most. ESIC says "ESIC provides reasonable Medical Care for self and family from day one of entering into insurable employment", so enrolments and KYC must carry across without a gap.
When does adoption actually happen?
After go-live, when the project team has moved on. That is why the owner role has to survive the launch.
Announce self-service, give it 2 weeks, then route routine requests back to it with a link. While the old route still works, a share of people will keep using it.
Which absences must survive the switch?
Long planned ones. ESIC says "ESIC provides 100% of average daily wages in cash up to 26 weeks in confinement and 6 week in case of miscarriage, during maternity leave and 12 weeks for commissioning mother and adopting mother."
Someone 14 weeks into a 26-week absence during a migration must not lose the record of it. Check open long-leave cases before you cut over, not after.
What should HR refuse?
| Pressure | The answer |
|---|---|
| Go live before the parallel run tallies | No. Payroll errors are not winnable goodwill |
| Switch on every module at once | No. Core first, the rest by quarter |
| Migrate data as-is to save time | No. You inherit the errors permanently |
| Skip training to hit a date | No. Untrained users produce the tickets |
Each of these is proposed with good motives and each one costs more than the delay it avoids.
How do you know it worked?
Payroll corrections per cycle, days to close month-end, and HR hours on routine queries. ESIC also says "ESIC provides monthly payment apportioned among dependants in case of death due to employment injury", so dependant-record coverage is a fair measure of whether migration was done properly.
The employment framework is published by the Ministry of Labour and Employment. What the platform covers sits under complete HRMS.