Most HRIS implementation checklists read like a settings menu. Configure departments, configure leave types, configure approval chains. That work is real, and it is not where implementations fail.
They fail on the cutover. On a leave balance that nobody could reconcile. On a first payroll run that disagreed with the old spreadsheet by an amount nobody could explain before payday. Here is the checklist in the order the work actually lands on you.
Pick the go-live date backwards from a payroll run
Do not pick a go-live date and then work out when payroll starts. Pick the first payroll run you intend to do in the new system, then count backwards.
Go live at a period boundary. The first of a month if you run monthly, the start of a cycle if you run fortnightly. Mid-period cutovers mean splitting one pay period across two systems, and every proration in that split has to be done by hand and defended later.
Give yourself one full month between the data cutover and that first live run. That month is the parallel run, and it is the single item on this list that most projects delete when they fall behind. It is also the one that catches the errors.
Get the employee master right before anything else
Everything else in an HRIS hangs off the employee record. If it is wrong, every report built on it is wrong in a way that looks plausible.
For every person, settle these before import:
- A unique employee code that will never be reused, including for leavers
- Full legal name as it appears on the national ID, not the name people use
- Joining date, which drives leave accrual, probation, and every tenure figure you will ever quote
- Department and reporting manager, and check the manager exists as an employee too
- Gross salary and how it breaks down into basic and each allowance
- Employment type and status, because probation usually changes leave entitlement
- Official email, which in most systems is also the login and therefore has to be unique
Two things to check that people miss. First, the reporting manager chain has to terminate. If A reports to B and B reports to A, some reports will loop and some will silently return nothing. Second, decide now what happens to people who left mid-year. They belong in the system if you want accurate turnover history, and they need a leaving date, not deletion.
Treat the import as the risky step it is
An import that reports success is not the same as an import that worked. Check the count. If you uploaded 214 rows and the system created 198 employees, find those 16 before you do anything else. Silent skips are common: a duplicate email, a department that does not exist yet, a date in a format the parser read differently than you did.
Run the import into a test environment first, look at ten records by hand, and pick the awkward ones deliberately. The person with two surnames. The person who rejoined after leaving. The person on an unusual salary structure. If those ten are right, the rest usually are.
Keep the source file. When a number is queried in month three, the question is always what was loaded, and the answer has to be a file, not a memory.
Carry leave balances across at a stated date
Leave is where the arguments happen, because employees know their own balance and they will check it on day one.
Agree a cutover date and freeze balances as at that date in the old system. Export them. Import them as opening balances, not as accruals, or the new system will accrue on top of a figure that already includes the accrual.
Write down the accrual rule the new system will apply from that date, and confirm it matches what people were told when they were hired. Monthly accrual, annual grant, carry-forward cap, expiry, and what happens to a balance when someone leaves. If the old rule and the new rule differ, that is a policy change, and it needs a decision and an announcement rather than a quiet configuration setting.
One more that catches people every January: check what the system does at year end. Allocations are often created when an employee joins and never created again, which means on the first of January every balance reads zero until somebody runs the rollover.
Deal with attendance hardware early, not last
If you use biometric or card devices, start this in week one. It has more waiting in it than work.
- Confirm each device can reach the server, and on which port
- Check the device clock and its time zone, separately from the server's
- Map every device user ID to an employee code, and expect the mapping to be incomplete
- Decide what an unmatched punch does, because it will happen
The mapping is the slow part. Device IDs were often assigned years ago by whoever installed the reader, and they rarely match your employee codes. Every unmapped device produces attendance that belongs to nobody, and that shows up as absence.
Also settle the shift and grace rules before the first day of tracking. Grace period, what counts as late, what a half day is, and how a missing check-out is treated. These decide whether somebody is marked late, and people notice on day one.
Run payroll twice for one month
For one full cycle, run payroll in the old way and the new way, and reconcile them line by line before paying anyone from the new system.
Compare gross, each allowance, each deduction, and net, per employee. Not the totals. Totals hide two errors that cancel out, and they do cancel out often enough to be dangerous.
Where the two disagree, the new system is not automatically wrong. Parallel runs routinely surface an error that was in the old spreadsheet for years. Either way you need to know which it is before payday, and you need it in writing.
Ernst & Young put the average direct cost of correcting one payroll error in administrator time at $705 for missed sick time and $539 for a W-4 setup error. That is what finding it late costs. Finding it in a parallel run costs an afternoon.
Decide who can see and approve what
Permissions get set once and then inherited forever, so spend an hour on them.
Salary visibility is the one to be deliberate about. Managers usually need attendance and leave for their team and nothing about pay. Finance needs pay and not necessarily performance notes. Whoever can approve a leave request should generally not be the same person who can silently edit the attendance record it was raised against.
Write down who approves leave when the approver is themselves on leave. Every system needs this answer and most projects discover the gap on the first public holiday.
Plan the first month, not the launch day
Launch day is quiet. Month one is not.
Expect questions about leave balances in the first week, and expect most of them to be about the opening balance rather than the accrual. Expect the first payroll run to take longer than it will ever take again. Expect at least one person whose bank details were transcribed wrong, because that is what happens to a field nobody can validate.
Give people one place to ask, and answer publicly where you can, because the same five questions arrive from thirty people.
Then, at the end of month one, go back and check three things: that the leave balances still reconcile, that attendance has no unmapped devices left, and that the payroll figures agree with what finance actually paid out. Those three passing is what finished looks like.
A shorter version
If you only keep one page of this:
- Go live at a period boundary, one month before the first live payroll run
- Get the employee master right first, and check the import count
- Carry leave balances as opening balances at a stated freeze date
- Start device mapping in week one
- Run payroll in parallel for one full cycle and reconcile per employee
- Decide approvals and salary visibility before go-live, not after
Work Mint handles the attendance, leave and payroll side of this, including multi-currency runs and statutory deductions configured per organisation. If you want to see how the cutover works on your own numbers, ask us for a walkthrough at info@workmintpeople.com.