The standard advice is to switch payroll at the start of a financial year. It's good advice, and it's frequently useless, because the reasons people switch don't wait for April. The vendor raised prices, the system can't handle a new state, the support is unusable, or the compliance filings keep failing.
Looking for payroll software?
Check out Techimply's List of the Best Payroll Software in India for your business.
So you're switching in October. It's doable. It's also genuinely harder than an April switch, for one specific reason that most migration guides underplay. This is what actually changes mid-year and under-deducts: how to do it without breaking Form 16.
Why Mid-Year Is Harder: The Year-to-Date Problem
Switching in April means the new system starts and under-deducts: the employee has no income yet, no TDS deducted, and no PF contributed. The system computes forward from a clean slate.
Switching in October means the new system must know what already happened, because salary TDS in India is computed on estimated annual income, not per payment. The system estimates the employee's full-year income, computes annual tax, and spreads it across remaining months.
That calculation is impossible without accurate year-to-date figures. Specifically, the new system needs to know, per employee:
- Gross salary paid April to September
- Every exemption and deduction already applied
- TDS already deducted and deposited
- PF contributed, both shares
- ESI contributed, where applicable
- Professional Tax already deducted, per state
- Perquisites already valued
Get any of these wrong and the new system computes the remaining months' TDS against a false baseline. If the YTD TDS is understated, it over-deducts for the rest of the year. If overstated, it under-deducts, and the employee owes at filing.
The employee never sees the migration. They see their take-home change for no reason they understand.
This is the whole difficulty of a mid-year switch. Everything else is logistics.
Before You Switch: Three Decisions
Pick your cut-over month deliberately
The best mid-year cutover is at a quarter boundary, so a full quarter's data sits in one system, and the TDS return for that quarter comes from a single source. Switching mid-quarter means one return assembled from two systems, which is exactly the situation where challan mismatches appear.
If you can align to the end of Q2 (September) or Q3 (December), do. Avoid switching in Q4, because Q4 carries Annexure II, the full-year salary computation that generates Form 16 Part B, and you don't want that assembled across a migration.
Decide who files the quarter
If the old system produced Q2 and the new one produces Q3, someone must own the Q4 return that includes Annexure II covering the whole year. That data has to come from somewhere, and it must reconcile.
Settle this before cut-over, in writing, with both vendors.
Confirm the old vendor's exit terms
Export format, historical data availability, deletion timeline, cost. If you're mid-contract, check the termination clause. Your leverage is lowest immediately after you give notice, so ask before you do.
The Migration Sequence
Step 1: Extract everything, before you terminate anything
The ordering error that hurts most: terminating the old contract, then discovering you needed data from it.
Extract and store somewhere you control:
- Full YTD payroll register per employee
- All payslips issued this year
- TDS returns already filed, with acknowledgements
- Challans for every deposit
- PF ECR files and ESIC returns filed
- PT challans by state
- Employee master data, including PAN, UAN, ESIC IP number, bank details
- Salary structure history, including any revisions this year
- Investment declarations and any proofs collected
- Leave balances
- Any full-and-final settlements processed this year
Keep this even after migration succeeds. Statutory retention runs for years, and the old vendor won't be there.
Step 2: Clean the data before it moves
Your existing data has problems. The predictable ones:
- PAN name mismatches
- Missing or duplicate UANs
- Inconsistent date formats
- Salary structures that were configured loosely
- Employees who left but were never marked
Fix these before migration, not after. A wrong PAN migrating cleanly still produces a Form 16 that doesn't reconcile.
Step 3: Map the salary structure carefully
Modern Payroll & Benefits Software helps preserve salary structures, statutory deductions, and employee benefit calculations throughout the migration process.
This is where PF correctness is decided. Your components must map to the new system's model, and the critical question is which components sit in the basic plus DA base that PF computes on.
A "special allowance" that was inside the PF base in the old system and outside it in the new one produces a different PF deduction from the same salary. Employees notice. The EPFO notices later.
Get the mapping written down and signed off by whoever owns payroll. Not verbally agreed in a call.
Step 4: Load YTD figures and reconcile
The critical step. Load the year-to-date figures per employee and then verify them independently, don't assume the import worked.
Reconcile, per employee:
- YTD gross in the new system against the old payroll register
- YTD TDS against the challans actually deposited
- YTD PF against the ECR files filed
- YTD PT against the state challans
The TDS reconciliation is the one that matters most, because it drives every remaining month's computation. Reconcile against challans, not against what the old system claims it deducted. Those are different numbers if anything went wrong earlier in the year.
Step 5: Run parallel for one cycle
Process the same month in both systems and compare, employee by employee, to the rupee.
Where they differ, understand why before proceeding. Common causes:
- Salary structure mapped differently
- A component's PF treatment changed
- YTD TDS loaded incorrectly, so the projection differs
- PT applied for a different state
Sometimes the new system is right and the old one was quietly wrong. That's worth finding, and it's a good argument for the parallel run existing at all.
Parallel running costs you one month of double work. Skipping it costs you a payroll error affecting everyone, discovered after payment.
Step 6: Cut over
Go live at the boundary you chose. Confirm bank file format with your bank before the first live run, because a rejected bank file on payday is its own category of problem.
Keep the old system accessible read-only until you've completed Form 16 for the year. You will need to look something up.
Step 7: File the transition quarter carefully
Many organizations use compliance management software to monitor statutory deadlines, validate filings, and reduce reconciliation errors during payroll transitions.
The first return after cut-over deserves manual review rather than a click. Reconcile, deduct, deposit, and file. Check challan mapping specifically.
What to Watch After Cut-Over
The first payslip. Compare take-home against last month for a sample of employees. Any unexplained change is a YTD loading error, and finding it in month one is much better than in March.
Employee queries. A spike in "why is my TDS different" is your signal. Take those seriously; they're free error detection.
The December projection. Run a year-end projection per employee and compare TDS deducted against tax actually due. This catches YTD errors while three months remain to spread the correction.
Form 16 generation. The real test. Part A is generated from your filed return data, so if the transition-quarter filings had errors, Form 16 will be wrong, and you'll need a correction statement first.
The Specific Failures of Mid-Year Migration
YTD TDS loaded from the old system's claims rather than actual challans. If the old system's records diverged from what was deposited, you've imported the discrepancy, and it compounds.
Investment declarations lost. Employees declared in April; the declarations lived in the old system. If they don't migrate, the new system computes on the wrong deduction assumption, and TDS jumps.
PF base changed silently. Structure mapping altered which components sit in basic plus DA. PF deduction changes, nobody catches it, and the ECR is wrong from cut-over.
Perquisites dropped. Valued in the old system, not configured in the new one. Under-deduction until year-end.
Mid-year joiners' previous-employer income is lost. It was in the old system's records for annual computation. Now it isn't, and their TDS is understated.
Two systems, one quarter, no owner. The transition-quarter return gets filed late or with mismatched challans because each vendor assumed the other had it.
Old system terminated too early. You need it for Form 16, and it's gone.
Should You Just Wait for April?
Sometimes, yes. Honestly:
Wait, if you're within a couple of months of April, your current system is functional, and the switch is about preference rather than failure. The YTD reconciliation risk isn't worth two months of mild annoyance.
Don't wait if the current system is producing compliance errors, can't handle a state you now operate in, or is failing filings. Every month you wait adds a month of errors you'll be fixing anyway, and a broken system doesn't get better in March.
If you must switch in Q4, be aware you're switching during the hardest quarter: Annexure II, the full-year computation, and Form 16 generation all land immediately. If the choice is Q4 or April, April is usually right.
Conclusion
Mid-year payroll migration is a year-to-date problem wearing a data-migration costume. Because salary TDS computes on estimated annual income and spreads across remaining months, the new system needs accurate YTD figures or every subsequent deduction is wrong. Reconcile YTD TDS against actual challans, not against what the old system says it deducted. Those numbers differ precisely when something already went wrong. Extract everything before terminating anything. Map the salary structure carefully, especially which components sit inside the PF base. Run one parallel cycle and compare to the rupee. Cut over at a quarter boundary, and avoid Q4 if you can, because that's when Annexure II and Form 16 arrive. Then run a December projection. It's your last chance to catch a YTD error while there's still time to fix it quietly.
