When companies switch payroll providers, the questions asked are about migration: will the data come across, will year-to-date figures reconcile, and will Form 16 still work? Reasonable questions, all of them forward-looking. Almost nobody asks the backward question. What happens to the salary data sitting in the system you're leaving?
Looking for payroll software?
Check out Techimply's List of the Best Payroll Software in India for your business.
It's a live question now rather than a theoretical one. Under India's Digital Personal Data Protection framework, indefinite retention has become unlawful without a statutory basis, you remain accountable for what your processors hold on your behalf, and penalties reach a scale that makes this worth an hour of attention.
What Your Old Payroll System Actually Holds
Worth being concrete, because "payroll data" understates it.
Your former provider's database contains, for every employee you ever had: full name, PAN, Aadhaar in many cases, bank account and IFSC, salary and every revision, PF and UAN details, ESIC numbers, tax declarations including home loan and investment details, and often address, date of birth, and family details for insurance.
That's a near-complete financial and identity profile of every person who has worked for you. It's more sensitive than most of what your CRM holds, and it sits with a vendor you've stopped paying and stopped monitoring.
The Legal Position Has Changed
Three shifts matter here.
Indefinite retention is no longer lawful
The old default was to keep everything forever, on the theory that storage is cheap and you never know. Under the DPDP framework, that's now a violation. Personal data must not be retained beyond the period necessary for the purpose it was collected, unless another law requires it.
The practical effect is an inversion. Retention now needs a justification. "We might need it someday" isn't one.
You stay accountable for your processes.
Your payroll vendor is a data processor acting on your behalf. You're the data fiduciary, and you remain legally accountable for what they do with the data, including after you've left.
This is the clause that changes the switching conversation. If your old vendor retains employee data with no lawful basis, that's not their exposure alone. It's yours, because you're the one who was supposed to instruct them and hold them to it.
Penalties are substantial
Improper retention or deletion practices carry penalties reaching ₹50 crore and higher where breaches are involved, with the framework's upper limit at ₹250 crore. These numbers exist to make data hoarding uneconomic, and they succeed. Organizations often use compliance management software to manage data retention policies, regulatory documentation, and audit requirements across departments.
The Retention Conflict Nobody Explains Well
Here's what makes payroll harder than most data categories: you have simultaneous obligations to delete and to keep.
Statutory retention requires you to keep certain records. Payroll records for income tax purposes are commonly retained for around seven years, tax and finance records under various statutes stretch to eight, PF records follow EPFO requirements, and labor law record retention generally runs to at least three years for exit documentation.
DPDP requires you to delete once the purpose ends.
These aren't contradictory once you separate the categories, and that separation is the actual work:
- Statutorily required records stay for their mandated period. The statute is your lawful basis.
- Everything else goes when the purpose ends.
The failure is treating "payroll data" as one blob. Your obligation to retain wage registers for a statutory period is not an obligation to retain an ex-employee's Aadhaar copy, their investment declarations from four years ago, or their emergency contact details.
Align retention to the strictest applicable rule per category, not the strictest rule across all of them. Otherwise you'll justify keeping everything for eight years by pointing at a tax rule that only covers a subset.
What to Do Before You Sign With a New Provider
Counterintuitive, but the exit terms matter more at signature than at exit, because your leverage is entirely front-loaded. Once you've given notice, the vendor has no commercial reason to be helpful.
Get these in writing:
Data export format and completeness. Not "we'll provide your data." Specifically: which fields, in what format, and does it include historical payroll, not just current master data. A PDF dump of payslips is not a data export.
Deletion commitment with a timeline. How long after termination until data is deleted, and what triggers it.
A deletion certificate. Written confirmation that deletion occurred, covering which data and when. This is your evidence if anyone asks later.
Backup coverage. The clause most contracts miss. Primary database deletion is straightforward; backups are where data survives. Ask specifically whether backups are covered and on what expiry cycle, because a vendor who deletes your production data while retaining a two-year backup has not deleted your data.
Sub-processor coverage. If your vendor uses a cloud provider or an offshore team, deletion has to cascade. You're accountable for the whole chain.
Data location. Where is it stored, and does it leave India.
Cost of exit. Some vendors charge for export. Knowing that number at signature is very different from discovering it during a migration.
The Migration Itself
Between systems is where data is most exposed, because it leaves a controlled environment and moves through whatever channel someone chose under time pressure.
Never email the file. Payroll exports get emailed constantly, usually to a personal address because someone was working from home. That file then sits in a mailbox indefinitely.
Use encrypted transfer, SFTP, or an equivalent, with credentials shared separately from the file. If payroll records need to be retained, secure cloud storage software with encryption and access controls provides a safer alternative than storing files in email inboxes or local devices.
Restrict the working copies. A migration produces intermediate files: the export, the cleaned version, the mapping spreadsheet, someone's local copy for reconciliation. Each is a full salary database. Inventory them, and delete them when the migration closes.
Don't use production data for testing unless you have to. Where you must, restrict access to the specific people running the test.
Log who touched what. Access logging is a DPDP expectation, capturing user, timestamp, action, and IP. Migration is exactly when this matters and exactly when it's skipped.
Decommissioning the Old System Properly
Most companies stop paying the old vendor and consider the matter closed. It isn't.
Revoke access first. The day you cut over, remove every user account on the old system. People leave, and dormant accounts on an abandoned system with full salary data are a genuinely bad combination.
Extract what you're statutorily required to keep, before you terminate. This is the ordering error that hurts: terminate first, then discover you needed wage registers from three years ago and the account is closed.
Take Form 16 history, ECR filings, ESIC returns, PT challans, wage registers, and full-and-final settlement records. Store them somewhere you control, with the retention clock running per category. Many businesses archive these records using document management software to improve security, control access, and simplify long-term record retention.
Then issue the deletion instruction in writing, referencing the contract clause, with a date.
Follow up for the certificate. If it doesn't arrive, chase it. An undocumented deletion is, from an audit standpoint, indistinguishable from no deletion.
Check for stragglers. Integrations that still hold data, reporting tools connected to the old system, the vendor's mobile app on employee phones.
The Employee-Facing Obligation
Two points frequently missed.
Employees have rights over their data, including erasure where retention isn't legally required. A switch is a good moment to have a defensible answer to "what did you do with my information," and the answer should be specific.
And employees should know a switch is happening. Not a compliance formality so much as basic practice: their salary data is moving to a new processor, and telling them is cheap. The alternative is that they find out when a payslip arrives from an unfamiliar domain.
The Questions Worth Asking
Of your new vendor, before signing:
- Which fields will I get on export, in what format, including history?
- What's your deletion timeline after termination, and do backups fall within it?
- Will you issue a deletion certificate?
- Who are your sub-processors, and does deletion cascade to them?
- Where is data stored, and does it leave India?
- What does export cost?
Of your old vendor, at exit:
- Confirm the deletion date in writing
- Confirm backup expiry
- Request the certificate
- Confirm sub-processor deletion
Of yourself:
- What am I statutorily required to keep, by category, and for how long?
- Where does that live now that it isn't in the old system?
- Who has access to the migration files, and when do they get deleted?
Conclusion
Switching payroll providers means moving a complete financial and identity profile of everyone who has ever worked for you. The forward migration gets attention. What stays behind rarely does. Under DPDP, indefinite retention without a statutory basis is unlawful, and you stay accountable for what your processors hold on your behalf, including after you leave. That makes your old vendor's retention your exposure, not just theirs. Separate your data by category. Keep what the statute requires for the period it requires, and delete the rest. Don't let a seven-year tax rule justify keeping an ex-employee's Aadhaar copy forever. Negotiate export format, deletion timeline, backup coverage, and the deletion certificate at signature when you have leverage, not at exit when you have none. Extract your statutory records before you terminate the contract. And get the deletion in writing, because an undeleted database at a vendor you stopped paying is a breach waiting to be attributed to you.
