Payroll Software Migration: A Step-by-Step Checklist

Why Payroll Software Migration Scares Everyone (And Why It Shouldn't)

A payroll software migration is the one HR project where "we'll fix it next month" is not an option. If a recruitment tool goes live half-configured, hiring slows down for a week. If payroll goes live half-configured, 200 people get the wrong salary on the 30th, PF challans don't reconcile, and your finance head spends a quarter cleaning up Form 24Q corrections. That asymmetry is why so many Indian SMBs stay on a payroll system they outgrew three years ago.

The good news: payroll software migration is a well-understood, highly repeatable exercise. Nothing about it is mysterious. It is data engineering plus reconciliation plus a disciplined calendar. Teams that break a pay cycle almost never do so because the new software was bad — they do it because they skipped a parallel run, or because they exported the employee master and forgot that year-to-date TDS lives in a completely different table.

This guide is the checklist we wish every payroll team had before kickoff. It covers planning, the data inventory, cleansing, configuration, parallel runs, mid-year YTD and TDS carry-forward, the cutover weekend, go-live and hypercare — with worked INR examples, tables you can copy into your own project tracker, and the specific Indian statutory traps (PF, ESI, PT, TDS, Form 24Q, Form 16) that catch first-timers.

Written for HR managers, founders and payroll teams in India who need to switch payroll software without a single employee noticing anything except that payslips got clearer.

Signs It's Time to Switch Payroll Software

Before you plan a migration, be honest about whether you need one. Switching costs real hours. But staying costs more when these signals show up:

• Payroll takes more than two working days of manual effort. If your payroll executive spends three days a month in Excel reconciling attendance against the payroll tool, the tool is not doing its job.
• You maintain a "shadow" spreadsheet. Nearly every struggling payroll setup has one master Excel that is the real source of truth, with the software acting as a printing press. That spreadsheet is a single point of failure.
• Statutory outputs need rework. If ECR files, ESIC returns, PT challans, or Form 24Q text files need manual editing before upload, the system's compliance engine is not keeping up.
• You can't answer a CTC question in under a minute. Founders asking "what's our fully loaded cost for the engineering team including employer PF and gratuity provision?" should get an answer from a dashboard, not a data pull.
• Employees ping HR for payslips, tax projections, and investment proof status. A modern HRMS pushes this to self-service. If your inbox is the helpdesk, you're subsidising the software's gaps with HR salaries.
• The vendor is slow on statutory changes. When a Budget change or a state PT revision takes your vendor eight weeks to ship, you are carrying the compliance risk personally.
• You've outgrown the headcount band. Tools built for 20 employees behave differently at 300 — approval workflows, role-based access, multi-entity, multi-state PT, and audit trails all start to matter.
• No API, no integrations. If payroll can't talk to your accounting system, attendance devices, and bank portal, you're re-keying data every month, and re-keying is where errors live.
• Audit trail gaps. If you cannot show who changed a salary structure and when, you will fail an internal audit or a due diligence review.

If three or more of these are true, the cost of migration is lower than the cost of another financial year on the old system.

When to Migrate: Financial Year Start vs Mid-Year

The single biggest decision in any payroll software migration is when. It shapes the data scope, the effort, and the risk profile.

Option A: Go live on 1 April (start of the financial year)

This is the cleanest option and, if you can wait, the one to choose.

• No YTD carry-forward. Taxable income, TDS deducted, PF contributions, ESI contributions and PT paid all reset. The new system starts from zero.
• One Form 16 per employee. The new system generates the full-year Form 16 Part B; there's no stitching together of two half-year documents.
• One Form 24Q story. All four quarters get filed from one system, so quarterly TDS statements reconcile naturally.
• Fresh tax regime elections. Employees make their regime choice and submit declarations at the start of the year — you capture them in the new system rather than migrating them.
• Clean investment declaration cycle. Form 12BB declarations are collected fresh in April, so nothing has to be imported.

The trade-off: April is also appraisal and increment season for most Indian companies, plus the previous year's Form 16 generation and Q4 24Q filing. Your team is at peak load exactly when you want them focused on cutover. Mitigate by finishing configuration and UAT in January–February and doing parallel runs in February and March.

Option B: Go live on 1 October (start of Q3)

An underrated middle option. You're mid-year, so YTD carry-forward is required, but:

• Two quarters are done and closed on the old system; two on the new one — a clean 2+2 split.
• Q2 (July–September) filing is complete before you switch, so nothing is straddling a quarter boundary.
• You get six months of live running before year-end Form 16 generation, which means bugs surface with time to fix them.

Option C: Any other mid-year month

Perfectly doable — thousands of Indian companies do it — but you accept two things: full YTD carry-forward, and a quarter that is split across two systems for Form 24Q purposes. Section 4 of this guide handles that in detail.

Rule of thumb: if you can go live at a quarter boundary, do. If you can go live on 1 April, do that instead. If neither is possible, go live at a month boundary and budget an extra two weeks of reconciliation.

Building the Migration Team: Roles and RACI

Payroll migrations fail on ownership more often than on technology. "The vendor is handling it" is not a plan — the vendor does not know that your Chennai office pays a fixed conveyance allowance that must not be included in PF wages.

Assemble a small, named team:

• Project sponsor (CFO, Head of HR, or founder) — resolves scope fights, approves go/no-go.
• Payroll lead — the person who actually runs payroll today. Non-negotiable. They own the data, the parallel run variance analysis, and sign-off.
• HR operations lead — owns employee master data, leave balances, and employee communication.
• Finance/accounting representative — owns GL mapping, cost centres, bank file formats, and the payroll journal.
• IT/systems contact — owns SSO, integrations, biometric/attendance feeds, and data security.
• Vendor implementation manager — owns configuration, imports, and training.
• Pilot group — 15–30 employees across pay bands, locations and edge cases who test self-service before go-live.

RACI for the core activities

Print this. Put names in it. Ambiguity here is what produces "I thought you were validating the PF wage base."

The Payroll Data Migration Checklist: What You Actually Need to Extract

This is the heart of the exercise. Most teams underestimate the inventory by half because they think of payroll data as "employee list plus salary." Here is the full picture for an Indian payroll.

1. Employee master data

• Employee code (and the legacy code, retained as a cross-reference field)
• Full name exactly as per PAN — mismatches here break Form 24Q validation
• Date of birth, gender, date of joining, probation end date
• Employment type: permanent, contract, intern, consultant (consultants may be 194J, not 192)
• Department, designation, grade/band, cost centre, location, legal entity
• Reporting manager, approver hierarchy
• Personal email and mobile (needed for self-service invites)
• PAN, Aadhaar reference where captured, bank account number, IFSC, account holder name
• Date of exit and exit reason for employees who left during the current FY — you still need them for Form 16 and 24Q

2. Salary structures and compensation

• Current CTC and the full breakup by component
• Component-level rules: fixed vs variable, taxable vs exempt, PF-applicable or not, ESI-applicable or not
• Effective-dated salary revision history for the current financial year (critical — a July increment changes the YTD arithmetic)
• Arrears already paid and arrears pending
• Variable pay, bonus, incentive and commission structures with payout frequency
• Retention bonuses, joining bonuses, and clawback conditions
• Notice pay recovery rules

3. Year-to-date earnings and deductions (the part everyone gets wrong)

For every employee, month by month from April of the current FY to the cutover month:

• Gross earnings by component
• Total taxable income considered so far
• Exemptions already granted (HRA exemption, LTA, standard deduction applied)
• Employee PF, employer PF, EPS split, VPF
• Employee ESI and employer ESI
• Professional tax deducted, by state
• TDS deducted and deposited, month by month
• Any other deduction: loan EMI, salary advance, canteen, insurance premium recovery
• Net pay paid
• Labour Welfare Fund where applicable

Do not import a single YTD total. Import month-wise YTD. You will need month-wise detail to reconstruct quarterly Form 24Q figures and to answer an employee who asks "why did my TDS jump in September?"

4. Tax data

• Tax regime election for the current FY (old regime vs new regime) per employee — and the date it was recorded
• Form 12BB investment declarations: declared amounts by section (80C, 80D, 80CCD(1B), home loan interest, etc.)
• Proofs already submitted and verified vs merely declared — the difference materially changes tax projection
• Previous employer income and TDS, where employees submitted Form 12B on joining
• House rent details, landlord PAN where rent exceeds the threshold
• Perquisite details: company car, accommodation, interest-free or concessional loans, ESOP perquisite values
• Any Section 89 relief already computed for arrears

5. Statutory identifiers

• UAN for every employee, plus PF member ID
• PF applicability flag and whether the employee is an "excluded employee"
• Whether PF is on actual basic or capped at the statutory wage ceiling — and whether the employee has an existing higher-wage arrangement
• ESIC insurance number and applicability, including employees who crossed the wage threshold mid-contribution-period
• Professional tax state mapping per employee (based on work location, not head office)
• Establishment-level: PF establishment code, ESIC code, TAN, PAN of the entity, state PT registration numbers, LWF registration
• Gratuity eligibility date and any gratuity trust details

6. Leave and attendance

• Leave balances by leave type as on cutover date, with opening balance, accrued, availed, encashed, lapsed
• Leave policy rules: accrual frequency, carry-forward caps, encashment rules, negative balance permissions
• Comp-off balances and expiry dates
• Attendance regularisation pending items
• LOP (loss of pay) days recorded in the current cycle
• Shift and overtime data if you pay OT

7. Loans, advances and recoveries

• Outstanding loan principal, interest rate, EMI amount, EMIs paid, EMIs remaining
• Perquisite value of concessional loans for tax computation
• Salary advances outstanding
• Any court-ordered or statutory recoveries

8. In-flight items

• Full and final settlements in progress — employees who have resigned but not yet been settled
• Pending reimbursement claims (fuel, telephone, books and periodicals, LTA)
• Approved but unpaid bonuses or incentives
• Pending arrears from a revision approved but not yet processed
• Open investment proof verification cases

9. History and documents

• At least the current FY's payslips as PDFs (archive them; do not assume you'll have legacy access forever)
• Previous years' Form 16s
• Filed Form 24Q acknowledgements and provisional receipts
• Filed ECR files and PF challans
• Signed salary revision letters

Non-negotiable rule: before you cancel the old system's contract, export everything and store it in your own cloud storage with restricted access. Vendors delete data after contract termination. You may need FY-old payslips for a loan verification, a PF grievance, or an income-tax notice three years from now.

Data Cleansing Before Extraction: The Unglamorous Step That Saves You

Never migrate dirty data. A new system will faithfully reproduce every legacy error and add its own validation failures on top. Budget two full weeks for cleansing on a 200–500 employee base.

The workflow is simple: extract to a staging spreadsheet, run validation rules, produce an exception report, fix at source, re-extract. Repeat until the exception report is empty or every remaining exception has a documented reason.

Validation rules table

Practical cleansing tips

• Fix at source in the legacy system where you can, so the next extract is clean. Fixing only in the spreadsheet means the next re-extract undoes your work.
• Get employees to self-verify. Send each person their own PAN, bank details, DOB, address and UAN and ask them to confirm or correct within five working days. This one step removes the majority of master-data defects and shifts accountability.
• Freeze master-data changes after the final extract. Announce a change freeze from the extract date until go-live. Any urgent change goes through a single named approver and gets logged in a "delta list" applied to both systems.
• Decide your rounding and store the decision. Indian payroll rounds in a dozen places — component amounts, PF, ESI, PT, TDS. Write down the rule for each before configuration, not after the first variance appears.

Configuring the New System: Pay Components, Rules and Statutory Setup

Configuration is where the new system either replicates your reality or quietly changes it. Approach it as translation, not reinvention. You can improve your salary structures later; during a payroll software migration your goal is that the new system produces the same numbers as the old one for the same inputs.

Pay component design

For every earning and deduction, define and document:

• Component name and code (keep codes stable — they flow into GL and reports)
• Calculation basis: fixed amount, percentage of basic, percentage of gross, balancing figure, formula
• Taxability: fully taxable, partially exempt, exempt, or perquisite
• PF applicability: does it form part of PF wages?
• ESI applicability
• Whether it is prorated for mid-month joiners and leavers
• Whether it is affected by LOP
• Whether it appears on the payslip and under what label
• Arrear behaviour: does a retrospective revision generate arrears for this component?

Most disputes in a parallel run trace back to two flags: prorate and LOP-affected. Be explicit for every component.

Proration and LOP rules

Decide and configure your day-count convention. The three common approaches produce different numbers:

• Calendar days: monthly amount ÷ actual days in month × payable days
• Fixed 30 days: monthly amount ÷ 30 × payable days
• Working days: monthly amount ÷ working days in month × days worked

Worked example. Ravi's monthly gross is INR 60,000. He joins on 12 August (August has 31 days, 20 working days) and works 20 calendar days.

A INR 1,290 spread across 40 new joiners is INR 51,600 a month of unexplained variance. Nail the convention before the parallel run, and check that the new system applies it identically to joiners, leavers and LOP.

Statutory configuration

• PF: establishment code, contribution rates, whether employer contribution is restricted to the statutory wage ceiling or computed on actual basic, EPS split logic, admin charges, VPF handling, and the treatment of employees who joined above the ceiling. Confirm whether employer PF is inside or outside CTC — this changes gross-to-CTC reconciliation.
• ESI: wage threshold, contribution rates, and the contribution period rule under which an employee who crosses the threshold mid-period continues contributing to the end of that period. Systems that get this wrong understate liability.
• Professional tax: slabs vary by state and some states use half-yearly rather than monthly deduction. Configure per state, map every employee to their work-location state, and test one employee per state.
• TDS: old vs new regime computation, surcharge and cess logic, marginal relief, projection methodology (annualised projection vs actual-to-date plus projected), and how the system handles a regime switch mid-year.
• LWF: applicable states, employee and employer shares, deduction months.
• Gratuity: eligibility, formula, and whether you provision monthly for accounting.

Always verify current statutory rates, thresholds and slab values against official sources at configuration time and again before go-live. Rates change, states revise PT schedules, and Budget announcements alter tax computation. Do not rely on a rate table you copied from a blog — including this one.

Rounding rules

Document rounding for: each pay component, PF employee and employer, ESI employee and employer, PT, TDS, and net pay. Rounding differences are the single most common source of small parallel-run variances, and they are also the easiest to explain away and then forget. Set a tolerance (for instance, differences of up to INR 2 per employee attributable to documented rounding are acceptable) and hold the line on anything above it.

Mid-Year Payroll Switch: Carrying Forward YTD Income and TDS

This is the section that separates a smooth mid-year payroll switch from a painful one. If you're going live on 1 April, skim it. Otherwise, read twice.

Why YTD carry-forward matters

Indian TDS on salary under Section 192 is not a flat monthly percentage. The employer estimates the employee's total income for the financial year, computes the annual tax liability, and deducts it in roughly equal instalments over the remaining months, adjusting each month for changes in income, declarations and proofs.

That means the new system must know three things on day one:

1. Taxable income already paid in the current FY (April to cutover month)
2. Exemptions and deductions already considered in that computation
3. TDS already deducted and deposited in the current FY

If any of these is missing or wrong, the new system will either over-deduct (angry employees, refund claims) or under-deduct (short deduction, interest, and a nasty March surprise).

Worked example: a 1 October cutover

Priya's annual CTC gives a gross salary of INR 15,00,000. She has chosen the old regime and declared INR 1,50,000 under Section 80C and INR 25,000 under 80D. Assume her estimated annual tax liability including cess is INR 1,80,000. The old system deducted TDS evenly from April to September.

On go-live, you load into the new system: YTD gross INR 7,50,000, YTD PF INR 54,000, YTD PT INR 1,200, YTD TDS INR 90,000, plus her regime election and declarations.

The new system then recomputes the full-year picture. Suppose Priya submits proofs in January showing only INR 1,10,000 of the declared INR 1,50,000 under 80C. The revised annual liability rises to, say, INR 1,88,320. The new system's arithmetic must be:

• Annual tax liability: INR 1,88,320
• Less TDS already deducted (Apr–Sep, carried forward): INR 90,000
• Less TDS deducted Oct–Dec by the new system: INR 45,000
• Balance to recover in Jan–Mar: INR 53,320, i.e. approximately INR 17,773 per month

If the YTD TDS of INR 90,000 was not carried forward, the system would try to recover the entire INR 1,88,320 in six months — deducting roughly INR 31,000 a month instead of INR 15,000. That is the classic "my October salary dropped by INR 16,000" ticket, and it will arrive from every employee simultaneously.

The reverse failure: double-counting

The opposite error is loading YTD gross and letting the new system re-run April–September payrolls, so income is counted twice. Symptom: tax projections look enormous and everyone lands in a higher slab. Rule: the new system computes forward from the cutover month only; prior months exist purely as opening balances.

Form 24Q implications

Form 24Q is filed quarterly, per TAN, with employee-wise deduction details, and the fourth-quarter statement carries the annexure with the full-year salary and tax detail per employee.

• Quarters that closed on the old system stay with the old system's data. Do not refile them from the new system.
• The quarter in which you cut over is the danger zone if you go live mid-quarter. If you go live on 1 November, October belongs to the old system and November–December to the new one, but both fall in Q3. You will need to merge deduction details from both systems into a single Q3 statement. Doable, but manual — which is exactly why month-boundary and quarter-boundary go-lives are strongly preferred.
• The year-end annexure needs full-year salary and tax detail per employee. The new system can only produce this correctly if the YTD carry-forward was loaded with the right composition — not just totals, but exemptions and deductions considered.
• Reconcile the total TDS across both systems to the sum of your monthly TDS challans before filing. Deposited amount, deducted amount and statement amount must agree.

Form 16: Part A vs Part B, and the "two Form 16s" question

Form 16 has two parts, and they behave differently in a migration:

• Part A contains the summary of tax deducted and deposited, and is generated and downloaded from the income-tax TDS portal based on the Form 24Q statements filed against your TAN. Your payroll software does not create it. Because it is TAN-based and derived from filings, a mid-year software change does not by itself split Part A — the same TAN, the same filings, one Part A.
• Part B is the annexure showing salary breakup, exemptions, deductions and tax computation. This is what payroll software generates.

So the real question is not "will employees get two Form 16s?" but "can the new system produce a single, complete Part B covering the whole financial year?" It can — if and only if the YTD carry-forward included component-level detail, exemptions granted, and deductions allowed, not just a lump-sum figure.

Two practical approaches for a mid-year cutover:

1. Consolidated Part B (preferred). Load full component-level YTD from the old system so the new system prints one Part B for April–March. Cleanest for employees, cleanest for filing.
2. Two Part Bs. The old vendor issues Part B for the pre-cutover period; the new system issues Part B for the post-cutover period. Legal for employees to file with, but confusing, and it depends on the old vendor still being contractually available in May–June — often they are not.

Whichever route you choose, decide it during planning, not in June when Form 16s are due. If you pick option 2, get it in writing from the outgoing vendor that they will generate and deliver Part B after contract end, and confirm the delivery date.

Special mid-year cases to test explicitly

• Employees who joined mid-year and submitted previous-employer income via Form 12B — that income must survive migration or their tax will be understated.
• Employees who switched tax regime during the year, where permissible, and whose YTD was computed under the earlier regime.
• Employees who received arrears and claimed relief under Section 89 — the relief computation depends on year-wise income allocation.
• Employees who crossed the ESI wage threshold mid contribution period.
• Employees with perquisites such as company accommodation or a concessional loan, where the perquisite value accrues monthly.
• Employees on LWP or sabbatical with zero pay months in the YTD.
• Employees who exited during the year but before cutover — you still need their data for Q4 filing and Form 16.

Parallel Payroll Run: How to Prove the New System Before You Trust It

A parallel payroll run means processing the same month in both the old and new systems and comparing results line by line. It is the single most effective risk control in a payroll software migration, and it is the step most often shortened when the project runs late. Don't shorten it.

How many cycles?

Two cycles is the sweet spot for most Indian SMBs. One cycle proves the configuration; the second proves that the fixes worked and that month-on-month behaviour (arrears, incremental tax, leave accrual) is correct. A single cycle can hide problems that only appear in the second month, such as tax recomputation after a mid-cycle revision.

Designing the parallel run

1. Freeze inputs. Both systems get identical attendance, LOP, leave, variable pay and one-time payment inputs. If the inputs differ, the comparison is meaningless. Export the input set once and load it to both.
2. Run both to the payslip stage. Do not disburse from the new system. The old system remains the system of record during parallel runs.
3. Compare at three levels: company totals, department/cost-centre totals, and employee-by-employee, component-by-component.
4. Log every variance in a shared tracker with an owner and a status.
5. Classify and resolve — every variance must end in one of three states: new system corrected, old system was wrong (document it), or accepted rounding within tolerance.
6. Sign off in writing. The payroll lead and finance sign a one-page sign-off listing residual variances and their justification.

Tolerance thresholds

Set these before you look at the results, so you are not negotiating with yourself.

TDS gets a wider band than PF because projection methodologies legitimately differ between systems (annualised vs actual-plus-projected). But every TDS variance above your amber threshold must have a named reason, and the annual liability should converge even where monthly instalments differ.

Variance investigation table

Use this as your triage cheat sheet. Ninety per cent of parallel-run variances fall into these buckets.

UAT: Test Scenarios You Must Run Before Go-Live

Parallel runs prove the payroll engine. User acceptance testing proves everything around it — workflows, self-service, approvals, reports and edge cases that may not occur in the parallel month.

Build a test script with expected results, run it with real users, and record pass/fail. Minimum scenarios:

Payroll engine - New joiner mid-month, mid-cycle, and on the last day of the month - Exit mid-month with F&F including leave encashment, notice pay recovery and gratuity - Employee with LOP exceeding payable days (negative net pay handling) - Retrospective salary revision generating arrears across three prior months - Employee crossing the ESI threshold - Employee in each PT state you operate in - Old regime vs new regime employees at similar CTC - Employee with previous-employer income loaded - Employee with a company car or accommodation perquisite - Employee with an active loan EMI and a prepayment - Bonus or variable payout in an off-cycle run - Zero-pay month for an employee on unpaid leave

Workflows and self-service - Employee views payslip, downloads it, and sees correct YTD - Employee submits an investment declaration and it flows into the tax projection - Employee uploads a proof; HR approves and rejects one each; projection updates correctly - Manager approves leave and attendance regularisation - Role-based access: a manager cannot see another department's salaries - Payroll admin locks a cycle and cannot edit afterwards without an audit trail

Outputs - Payslip PDF: layout, employer details, component labels, YTD block - Bank transfer file in your bank's exact format, uploaded to the portal in test mode - PF ECR file validated on the portal - ESI contribution file validated - PT challan-ready statement per state - Form 24Q data extract and, where supported, the FVU-ready file - Salary register, statutory register, variance report, headcount and cost reports - GL journal export imported into the accounting system without errors

Security and access - SSO login, password policy, MFA if used - Access removal for a departed HR user - Audit log shows who changed a salary and when - Data export permissions restricted to named roles

Recruit a pilot group of 15–30 employees spanning locations, pay bands, regimes and edge cases. Their feedback on payslip clarity and self-service is worth more than any internal review.

Integrations: Don't Let the Plumbing Break the Cycle

Payroll rarely lives alone. Map every inbound and outbound connection before cutover.

Inbound - Attendance: biometric devices, swipe systems, mobile check-in, or a separate attendance tool. Confirm the file/API format, the sync frequency, and how late corrections are handled. - Leave: if leave stays in a separate HRMS, the LOP feed into payroll must be reliable and cut off at a defined date each month. - Recruitment/onboarding: candidate-to-employee record creation, so new joiners appear in payroll automatically. - Expense/reimbursement systems feeding claim amounts into payroll.

Outbound - Accounting/GL: the payroll journal with cost-centre-wise debits and credits. Agree the account mapping with finance in writing and test the import into the accounting system, not just the export from payroll. - Bank: salary transfer file in the bank's exact format. Every bank has quirks — field order, header rows, name-length limits, IFSC validation. Test with a small batch or the bank's validation tool before go-live. - Insurance and benefits providers: monthly headcount and coverage feeds. - BI/reporting: any dashboards pulling payroll cost data.

Integration checklist - Document the direction, trigger, frequency, format, and owner for each interface - Test with production-shaped volumes, not three sample rows - Define failure behaviour: what happens if the attendance sync fails on the 25th? - Confirm who is alerted and who fixes it - Keep a manual fallback (a CSV upload path) for every automated feed for at least three cycles

Statutory Filing Continuity Across the Switch

Write down, per statutory obligation, which system produces the output for which period. Ambiguity here causes missed deadlines.

Two rules: never change your TAN, PF establishment code or ESIC code in the same month as a software change; and never let a statutory due date fall inside your cutover weekend.

The Cutover Weekend Runbook

Cutover is the short window when the old system stops being the source of truth and the new one starts. Treat it like a deployment: a written runbook, a named owner per step, timestamps, and a go/no-go gate.

T-14 days - Final parallel run signed off - UAT signed off, all critical and high defects closed - Employee communication sent (see below) - Master-data change freeze announced - Old system access list confirmed; read-only access extension negotiated with the outgoing vendor

T-7 days - Final full data extract from the legacy system - Backups taken: employee master, YTD, payslip PDFs, Form 16s, filed returns, ECR files, challans - Backups stored in company-controlled storage with restricted access - Go/no-go checklist circulated

T-3 days - Load final data into the new system's production environment - Run the automated validation suite; exception report must be clean - Reconcile headcount, YTD gross, YTD TDS, PF and ESI totals against the legacy reports — line by line - Confirm bank file format approval from the bank - Confirm GL mapping sign-off from finance

T-1 day: go/no-go Go requires all of the following: - Data reconciliation complete and signed - Parallel run variances within tolerance and documented - Bank file validated - Statutory outputs validated - Rollback plan documented and rehearsed - Support roster confirmed for go-live week - Sponsor's written approval

Any red item means no-go. Postponing by one cycle is cheap; a broken pay cycle is not.

Cutover day 1. Lock the legacy system to read-only. Nobody processes anything there again. 2. Apply the delta list — the changes that occurred between final extract and cutover. 3. Re-run the validation suite after applying deltas. 4. Enable the new system for payroll admins. 5. Send employee self-service invitations in waves, not all at once, so the helpdesk isn't flooded. 6. Publish the support channel and response times. 7. Record the cutover completion timestamp and sign-off.

First live run - Run payroll in the new system, but do not release the bank file yet. - Compare against the previous month's payroll, not against the old system. Explain every employee whose net pay moved by more than a set threshold (say INR 500) — increments, LOP, tax changes and reimbursements will account for nearly all of them. - Have the payroll lead and finance both review the salary register. - Release the bank file only after both sign off. - Generate statutory files and validate on the respective portals before the due dates, not on the due date.

Go-Live, Hypercare and Rollback

Hypercare: the first 60–90 days

Hypercare is a defined period of elevated support. Structure it:

• Daily 15-minute stand-up in week one, twice weekly in weeks two to four, weekly thereafter
• A single issue tracker with severity levels: S1 (pay impact), S2 (statutory impact), S3 (reporting/UX), S4 (enhancement)
• Agreed response times per severity with the vendor, in writing
• A named vendor engineer available during your payroll processing window
• Weekly summary to the sponsor: issues raised, closed, open, and trend

Exit hypercare only after three consecutive clean cycles: no S1 issues, statutory filings on time, and no manual workarounds in the pay run.

Rollback plan

You will probably never use it. Have it anyway.

• Keep the legacy system live in read-only mode for at least three cycles, and ideally until the financial year's Form 16s are issued. Negotiate this into the exit terms with the outgoing vendor before you sign anything with the new one.
• Define rollback triggers explicitly. Examples: net pay errors affecting more than 5% of employees, inability to generate a valid bank file, or a statutory file that fails portal validation with no fix within 24 hours.
• Define the decision-maker and the deadline. Rollback is only viable before disbursement. Set a hard time — for example, if the new system cannot produce a validated bank file by 6 pm two working days before pay date, revert to the legacy system for that cycle.
• Rehearse the fallback path. Confirm you can still process a cycle in the old system: licences active, users not deactivated, data current enough.
• Plan for partial rollback. Sometimes the right move is to pay everyone from the new system but produce statutory files from the old one for a month while a defect is fixed.

Also budget contingency: keep the ability to run a supplementary or off-cycle payroll within 48 hours, so that if a subset of employees is underpaid you can correct it quickly rather than making them wait a month.

Communicating With Employees

Employees do not care about your migration. They care that salary lands on time, the payslip makes sense, and their tax isn't wrong. Communicate accordingly.

Three weeks before go-live — announce the change. Keep it short: we're moving to a new payroll and HR system, pay dates are unchanged, here's what will look different, here's who to contact.

Two weeks before — ask employees to verify their own master data: name as per PAN, PAN, bank account, IFSC, DOB, UAN, address, work location. Give a deadline and a simple form.

One week before — send a short guide (one page or a two-minute video) showing how to log in, find payslips, submit declarations and upload proofs.

Go-live week — send self-service invitations in waves. Publish the helpdesk channel and expected response time.

First payslip — send a comparison note explaining any layout changes: component names that changed, where YTD figures now appear, and a reassurance that gross and net are unchanged unless there was an increment or LOP.

Common employee questions to pre-empt - Will my salary be delayed? No — pay dates are unchanged. - Will my tax deduction change? Your annual tax liability is unchanged. Monthly instalments may shift slightly as the new system recalculates the remaining months. - Will I get two Form 16s? Explain your chosen approach clearly. - Are my old payslips available? Confirm where the archive lives and how to request historical documents. - Is my data safe? Name the security posture: access controls, encryption, and who inside the company can see salary data.

Silence creates rumours, and payroll rumours travel faster than any HR announcement.

A Realistic 12-Week Payroll Implementation Timeline

Compress this only if your headcount is small and your structures are simple. Extend it for multi-entity or multi-state operations.

Two scheduling rules: never schedule cutover in the same week as a statutory due date, and never schedule go-live in a month with an unusual payroll event (annual bonus, appraisal arrears, or a large exit wave).

Common Payroll Migration Mistakes

• Skipping the parallel run because the project is late. This is the mistake that produces the horror stories.
• Migrating dirty data and expecting the new system to clean it. It won't; it will just fail validation at the worst moment.
• Importing only YTD totals instead of month-wise, component-wise detail. Fine until you need Form 16 Part B or a quarterly reconciliation.
• Treating declarations as verified proofs during import, which understates TDS all year and creates a March cliff.
• Forgetting exited employees from the current financial year, who still need Form 16 and appear in Q4 filings.
• Letting the vendor own data validation. They don't know your policies. Your payroll lead must sign off.
• Changing policy during migration. Redesigning salary structures, changing the LOP rule and switching systems at once makes every variance unattributable. Migrate first, optimise later.
• No change freeze, so the data loaded on Monday is stale by Thursday.
• Cancelling the old contract too early, losing access to historical payslips and reports.
• No rollback plan, so a defect becomes a crisis.
• Under-communicating to employees, converting a routine change into a trust problem.
• Ignoring the bank file until the day before pay date. Bank formats are unforgiving.
• Assuming PT is one national rule. It is state-specific, and mapping employees to the wrong state creates both under-deduction and refund headaches.
• Not documenting rounding, so every cycle reopens the same debate.
• No named hypercare owner, so post-go-live issues drift.

Success Metrics: How You Know the Migration Worked

Define these before go-live and report them at the hypercare exit review.

Baseline these numbers before you migrate. Without a baseline, you can't demonstrate the return on the project, and the sponsor who approved it deserves the evidence.

Frequently Asked Questions About Payroll Software Migration

1. How long does a payroll software migration take in India? For an SMB with 50–500 employees and reasonably standard structures, plan 10–12 weeks from kickoff to go-live, plus 8–12 weeks of hypercare. Under 50 employees with simple structures can compress to 5–6 weeks. Multi-entity, multi-state or heavily customised setups take 16 weeks or more. The variable that stretches timelines most is data quality, not software configuration.

2. Can I switch payroll software in the middle of a financial year? Yes. A mid-year payroll switch is common and entirely manageable, provided you carry forward month-wise YTD taxable income, exemptions and deductions already considered, and TDS already deducted. Prefer a quarter boundary (1 July or 1 October) so Form 24Q quarters don't split across systems. If you must go live mid-quarter, plan for manual consolidation of that quarter's deduction details.

3. Will employees get two Form 16s if we switch mid-year? Not necessarily. Form 16 Part A is generated from the TDS portal against your TAN based on filed Form 24Q statements, so a software change does not split it. Part B is produced by payroll software. If you load complete component-level YTD into the new system, it can issue a single consolidated Part B for the whole year. If you don't, you'll need the outgoing vendor to issue Part B for the earlier period — so agree that in writing before their contract ends.

4. How many parallel payroll runs do we really need? Two for most organisations. One proves the configuration; the second proves that fixes held and that month-on-month logic — arrears, incremental TDS, leave accrual, threshold crossings — behaves correctly. Go to three cycles for multi-entity setups, heavy variable pay, or if the first cycle threw variances above tolerance. One cycle is only defensible for a small, simple, 1 April go-live.

5. What is the most commonly missed item in a payroll data migration checklist? Month-wise YTD TDS with its supporting composition — the exemptions and deductions the old system already considered. Teams import a single YTD total, and the new system then computes the remaining months on an incomplete base. The second most missed item is the effective-dated salary revision history, without which arrears calculations and Section 89 relief go wrong.

6. Should we keep the old payroll system running after go-live? Keep it in read-only mode for at least three cycles, and ideally until the financial year's Form 16s are issued and Q4 Form 24Q is filed. Negotiate read-only access into your exit terms. Separately, export and store everything — payslips, Form 16s, filed returns, challans, ECR files — in your own storage before the contract ends. Vendors purge data after termination.

7. What tolerance should we accept in parallel run differences? Statutory deductions (PF, ESI, PT) should match exactly except for documented rounding. Net pay should be within a rupee or two per employee, again with a rounding explanation. TDS can vary more — a few hundred rupees per employee per month — because projection methodologies differ legitimately, but the annual liability should converge and every variance must have a named reason. Nothing unexplained should pass, however small.

8. Do we need to inform PF, ESIC or the income-tax department that we changed payroll software? No. These authorities register your establishment, not your software. Your PF establishment code, ESIC code and TAN are unchanged, and returns continue to be filed against them. What matters is filing continuity and accuracy: same identifiers, no gaps in periods, and totals that reconcile to challans. Do verify current rates, slabs and filing formats against official sources at the time of migration, since these change periodically.

Final Checklist Before You Press Go

• [ ] Go-live date chosen at a month boundary, ideally a quarter or FY boundary
• [ ] Named team with a signed RACI
• [ ] Complete data inventory extracted, including exited employees and in-flight F&Fs
• [ ] Validation rules run; exception report clean or fully justified
• [ ] Month-wise YTD earnings, deductions and TDS loaded with composition detail
• [ ] Tax regime elections and Form 12BB declarations imported, with declared vs verified distinguished
• [ ] Statutory setup verified against current official rates and state rules
• [ ] Proration, LOP and rounding conventions documented and configured
• [ ] Two parallel runs completed and signed off within tolerance
• [ ] UAT complete, pilot group feedback addressed
• [ ] Bank file validated with the bank; GL journal imported cleanly by finance
• [ ] PF ECR, ESI and PT outputs validated on the respective portals
• [ ] Form 16 Part B approach decided and documented
• [ ] Employee communication sent; master data self-verified
• [ ] Change freeze in place; delta list maintained
• [ ] Legacy data exported to company-controlled storage
• [ ] Rollback triggers, owner and deadline defined
• [ ] Hypercare roster and severity SLAs agreed with the vendor
• [ ] Sponsor's written go/no-go approval on file

Conclusion: Migrate Once, Migrate Properly

A payroll software migration is not a technology project with an HR component. It is an HR and finance project with a technology component — and it succeeds on discipline: clean data, explicit rules, month-wise YTD carry-forward, two honest parallel runs, a written runbook, and a rollback plan you never use.

Get those right and the switch is invisible. Salaries land on the same date, payslips look better, statutory files validate on the first attempt, and your payroll lead gets two days a month back. Get them wrong and you spend a quarter apologising.

If you're planning a switch, start with three things this week: pick your go-live date at a month boundary, extract your data and run it through the validation rules table above, and put names against the RACI. Everything else follows from those.

CozyHR is built for exactly this — Indian payroll, PF, ESI, professional tax by state, TDS with both regimes, Form 24Q and Form 16 support, employee self-service, and an implementation team that has done mid-year YTD and TDS carry-forwards many times over. If you'd like a migration plan mapped to your headcount, states and go-live date, take a look at CozyHR or talk to our team about a parallel run on your own data. No pressure, no broken pay cycles.

This article is general guidance, not tax or legal advice. Statutory rates, thresholds, slabs and filing formats change — verify current rules with official sources or your tax advisor before configuring payroll.