Switching HRMS Without a Bad Month: The Parallel Payroll Method

Why migrations go wrong

HRMS migrations do not fail because the new software is bad. They fail because of things that happen before the first login: the switch is planned for month end, when the team is busiest and any error reaches a payslip within days; balances and year-to-date figures are brought across without being reconciled, so the first payslip shows a number the employee does not recognise; and employee masters arrive with gaps, so payroll runs on half a company.

Month-end cutover. The old system is switched off on the 25th and the new one has to produce salaries on the 30th, with no time to compare.
Unreconciled balances. Leave balances, loan outstandings and tax deducted so far are typed in from memory, then argued about for a year.
Missing masters. No UAN for twelve people, no IFSC for eight, no date of joining for the ones who came with the acquisition.
Defaults left in place. PF on full basic, a 9-to-6 shift and a January leave year, because nobody changed them.
No owner for the reconciliation. Everyone assumes the vendor checked, and the vendor assumes finance did.

What to export from the old system

Take everything out of the old system while you still have access, and take it out once, on a dated snapshot. If the old system is a spreadsheet, the export is the spreadsheet, frozen. If it is greytHR, Keka, Zoho People or Tally, use their export reports rather than copying from the screen.

Data	What to include	Why it matters
Employee master	Code, name, date of birth, date of joining, department, designation, grade, branch, reporting manager, PAN, Aadhaar, UAN, ESIC number, bank account and IFSC, contact details	Everything else hangs off this record. A missing UAN blocks the PF return; a wrong IFSC bounces a salary.
Salary structures	Every component per employee with its current amount, the effective date, and whether it attracts PF, ESI and tax	The parallel run compares these component by component.
Leave balances	Opening balance per leave type as of the cutover date, with the accrual rule that produced it	Employees check this on day one.
Loans and advances	Original amount, EMI, instalments recovered, outstanding, and the next recovery date	A wrong outstanding is a wrong deduction every month until someone notices.
Year-to-date tax figures	Gross paid, TDS deducted, declarations and proofs received, previous-employer income	Form 16 and the fourth-quarter Form 24Q must cover the whole year.
PF and ESI registration	Establishment codes, contribution history, the last filed ECR and ESI return	The first challan from the new system must continue the series.
Documents	Offer and appointment letters, ID proofs, past payslips, Form 16s	You lose access to the old system on the day the subscription ends.
Attendance and shift rules	Shift timings, grace, late-mark and overtime rules, and the last three months of muster	The muster is what payroll runs on; the rules are what the muster is judged against.

Validate before you import

Import nothing until the export has been checked. The checks are mechanical and a spreadsheet can do most of them; a good HRMS will run them on the import file and tell you the row and the reason.

Duplicate employee codes, PANs or bank accounts across rows.
Missing PAN, UAN, IFSC or date of joining for anyone active.
Date of joining before date of birth, or a confirmation date before joining.
Salary components that do not add up to the CTC on the offer letter.
Negative leave balances, and balances above the carry-forward cap.
Loan outstanding that is not equal to the original amount minus instalments recovered.
Employees who exist in payroll but not in the master, or the other way round. These are usually contractors, interns or leavers not closed.

Fix the source, not the import file. If the old system has the wrong IFSC, correct it there first and re-export, so the last payroll on the old system and the first on the new one agree.

Configure policies to match, not defaults

Every HRMS ships with defaults: PF restricted to ₹15,000, a single day shift, leave credited in January, loss of pay on calendar days. Yours may differ on any of these, and the parallel run will find every difference as a mismatch. Configure first, from a written list of how you actually pay: PF on the ceiling or on full basic; ESI applicability by branch; the professional tax state of each location; the leave year and accrual; grace and late-mark rules; rounding of each component; how arrears and joining-month proration are computed. Put the list into the payroll configuration and keep it as the reference for the reconciliation.

The parallel run, reconciled line by line

Pick a month. Run it in the old system as you always have and pay from it. Run the same month in the new system, on the same attendance, and do not pay from it. Then put the two registers side by side, employee by employee, and compare every line.

1Gross earnings, then each component: basic, HRA, allowances, overtime, arrears.
2Each deduction on its own: employee PF, ESI, professional tax, TDS, loan recovery, loss of pay.
3Net pay, which should match to the rupee once the lines above do.
4Employer cost: employer PF with EDLI and administrative charges, employer ESI, gratuity provision, any bonus accrual.
5The statutory outputs: the PF ECR line count and total, the ESI contribution total, the PT total per state, the TDS total.

Every difference gets one of three labels: the old system was wrong, the new configuration is wrong, or the data is wrong. Correct the cause, rerun, and compare again until the differences are zero or explained in writing. Kuzhu’s onboarding includes one such parallel payroll reconciled to the rupee against the previous system, and it is the reason a finance controller agrees to switch.

When to cut over

The cleanest date is 1 April, because the tax year restarts and there are no year-to-date figures to carry. Failing that, the first day of a quarter (1 July, 1 October or 1 January) keeps each Form 24Q quarter inside one system, and 1 April and 1 October also align with the ESI contribution periods. A mid-quarter cutover is workable but means loading year-to-date salary and TDS per employee so that Form 16 is complete, and splitting a quarterly TDS return between two sources.

Whatever the date, run the parallel month before it, not on it. If the parallel run is March, cut over on 1 April and the first live payroll is April, paid at the end of April, with the whole month to check the compliance calendar dates that follow.

Telling employees

Employees care about three things: is my salary date the same, is my leave balance the same, and where do I get my payslip now. Send one message a week before cutover that answers all three, with the app link and a two-minute guide. Publish the first payslip from the new system with a note explaining any change in layout, and open a window for balance queries with a promise to answer each one with the ledger, not a reassurance.

Keep the devices and the bank file formats

A migration should not touch the things that already work. Biometric devices from ESSL, Realtime and any maker whose device can push punches are repointed to the new system, not replaced. Salary transfer files are produced in the format your bank already accepts, so the finance team’s upload does not change. Payroll journals export to Tally in a shape the accountant posts without retyping. If a vendor tells you any of these must change, ask why.

A four-week plan

Week	Work	Done when
Week 1	Export from the old system on a dated snapshot; validate; fix at source; import employee master, structures, balances and loans	Import passes with zero errors and the headcount matches
Week 2	Configure statutory settings, salary components, leave policy, shifts, approval chains, holiday calendars; connect devices and the bank format	Every rule on the written list is in the system and signed off by HR and finance
Week 3	Parallel payroll on the same attendance; reconcile gross, each deduction, net, employer cost and statutory totals; rerun until zero	Reconciliation sheet signed by finance with every difference resolved or explained
Week 4	Roll out the app and web logins; managers approve from the queue; employees see balances and the last payslip; the old system is frozen on a date	First live payroll runs from the new system, with support on the phone for it

Four weeks is typical for a company under 500 employees moving from spreadsheets, Tally payroll or another HRMS. Multi-entity and multi-state setups take longer in week 2.

The parallel month is also the best moment to catch the payroll mistakes the old system was quietly making, because it is the only time two independent computations of the same month sit side by side.

See what changes, what you keep, and how long the move takes from spreadsheets, Tally, greytHR, Keka or Zoho People.

How switching works

Questions people ask

How long does it take to switch HRMS in India?

Two to four weeks for a company under 500 employees: a week to export, validate and import data, a week to configure policies, a week for the parallel payroll and its reconciliation, and a week to bring everyone else onto the system. Companies with several legal entities or states spend longer on configuration.

What is a parallel payroll run?

The same payroll month processed in both the old and the new system, on the same attendance and inputs, with the old one actually paying salaries. The two registers are then compared per employee on gross, each deduction, net and employer cost. Differences are fixed and the month rerun until the two agree to the rupee.

Should we switch HRMS in the middle of the financial year?

You can, but the start of a quarter is better and 1 April is best. A mid-year switch means loading year-to-date gross, TDS and declarations per employee so Form 16 and the fourth-quarter Form 24Q are complete. It is routine work, but it is work that a 1 April cutover avoids entirely.

Do we need to replace our biometric machines when we change HRMS?

No. Devices from ESSL, Realtime and most other makers push punches to whatever system they are pointed at. The migration repoints them and checks that punches arrive with the right employee codes. Replacing devices is only needed if the existing ones cannot push data at all, which is rare for anything bought in the last decade.

What if the old system will not export our data?

Every system has reports, and reports can be exported. Salary registers, employee lists and leave ledgers usually come out as Excel. If a vendor blocks exports at the end of a contract, ask in writing, cite the contract, and take exports of the registers before access ends. Bring the last twelve months of salary and the current balances; older history can stay archived.