The Data-Mapping Gap Behind Every Keka Alternative Search in India

A payroll platform switch fails in the gap between the export file and the import template, not in the sales cycle. That gap has a shape: your old system stores an employee's PF wage as one column, your new one splits basic and DA; your old system exports leave in days, your new one wants a decimal balance with a carry-forward date. Nobody flags it. It surfaces at the point of import, in the same week the payroll cycle locks. If you are evaluating a Keka alternative in India right now, that is the thing to check before you sign anything. Our team's view, after building Payroll around Indian statutory rules, is that a migration is an audit, not an install. Treat it as an install and you will find out on the 30th.

That is the actual risk in a switch, and it is the reason most guides to changing HRMS providers are useless. They compare feature grids. Feature grids do not tell you whether your April PF challan will reconcile.

Treat the Switch as a Reconciliation, Not an Install

Here is the distinction that matters. An install asks: is the new system configured? A reconciliation asks: does the new system produce the same numbers as the old one, for the same month, for every employee, down to the rupee?

Those are different questions with different failure modes. A configured system can happily compute a wrong gratuity for eleven people and tell you nothing. Reconciliation catches it.

This is what we call the Zero-Delta Switch: you do not go live on a new HR system until one full month's payroll, run twice on two systems, produces a delta of zero on net pay and on every statutory deduction behind it. Not "close enough." Zero, or a documented reason for every rupee of variance. It sounds pedantic. It is the only thing standing between you and a payroll correction cycle that runs for two quarters.

It has three phases, and each one has a test you either pass or fail:

The cutover gate deserves one extra line, because it is the one people get wrong under commercial pressure. A gate is a condition set, not a date. Cancelling on a calendar date because the contract renews is how companies end up with no access to their own historical payslips.

The Parallel Run Checklist for Your Transition Month

Run this in the month before cutover, alongside your live payroll. Copy it into a shared sheet and assign an owner to each line.

Before the run

• Freeze master data in the old system on a stated date. Every mid-month joiner or exit after that date gets entered into both systems manually, and logged.
• Export a full employee master, an active-employee list, and the prior three months of processed payroll registers.
• Confirm your new system has the same financial-year opening balances: YTD gross, YTD TDS deducted, YTD PF, leave balances as at 1 April.
• Load the same attendance and leave data into both. Do not let one system use biometric data and the other use a manual sheet, or your delta is meaningless.

During the run

• Process payroll in the new system for the same cycle, same cut-off dates, same approval chain.
• Compare at four levels: company total, department total, per-employee net, per-employee component. Most teams stop at company total. Company total can net to zero while two employees are individually wrong in opposite directions.
• Check PF against the ₹15,000 monthly basic-plus-DA ceiling on employer liability and the 12% employee contribution on basic plus DA that EPFO publishes in its employer guidance. If your new system applies the ceiling differently from the old one (restricted versus unrestricted wages), you will see a systematic delta across a whole band of employees. That is a configuration decision, not a bug, and you need to make it consciously.
• Check ESI eligibility flips at the ₹21,000 monthly gross threshold set by ESIC. An employee who crossed it mid-contribution-period must stay in for the rest of the period. Systems handle this differently.
• Check professional tax by state, remembering the constitutional cap of ₹2,500 per year, and that some states levy none at all.
• Check gratuity provisioning against the statutory formula of 15 days' wages × completed years ÷ 26, with the 5-year qualifying-service rule.

Before you cut over

• Every delta is either resolved or has a written explanation naming the correct treatment.
• One full statutory filing is generated from the new system and eyeballed against the old ECR format.
• Someone other than the person who did the migration has reviewed the mapping ledger.

Let me make the case for a parallel run in arithmetic you can check. This is an illustrative model, not anyone's real data, and the inputs are meant to be argued with. Take a 200-person company. Assume a per-employee comparison across all salary components takes 90 seconds: that is 300 minutes, five hours of one person's month. Now assume you skip the run and 16 of those 200 records carry a mapping error into live payroll. Each one costs an employee conversation, a recomputation, an off-cycle payment, often a revised challan too. At two hours of blended HR and finance time apiece, that is 32 hours before you count the trust cost. Halve my error assumption to eight records and the parallel run still wins on hours alone. Adjust the rate to your own team; the conclusion holds.

HRMS Migration: The Technical Reality of Exporting Your Data

Every Indian HRMS exports data. The question is what shape it comes out in, and how much of your history it carries.

What you can normally get out

Most SaaS HR platforms, including Keka, give admins CSV or Excel exports of employee master data, salary structures, attendance registers, leave balances, and processed payroll registers, plus PDF payslips and Form 16 files. Some data lives only inside generated reports rather than as a clean table. That distinction matters more than people expect when you plan the data export.

The four mapping problems that actually bite

Salary structure decomposition. Old system stores a single "CTC" and derives components at runtime; new system wants each component as a stored value. Or the reverse. Either way, someone has to decide the mapping rule and apply it identically to every band.

Date format collisions. DD-MM-YYYY versus MM-DD-YYYY versus a serial date number that Excel silently reinterprets when you open the file. A joining date that flips from 03-11-2021 to 11-03-2021 changes gratuity eligibility. Open exports in a text editor first, or import them as text, before Excel helpfully corrects them for you.

Employee ID continuity. If IDs change, every historical record and every past appraisal loses its anchor. Keep the old ID as a stored secondary field even if the new system generates its own. You will need it during any statutory query for the next several years.

Leave encoding. Half-days, comp-offs, sandwich-leave rules and encashment-eligible balances are encoded differently by every vendor. Reconcile the balance as at your policy year start, then replay transactions, rather than trusting a single balance figure. A well-built Leave Management setup should let you import an opening balance and a transaction history separately, precisely so this is auditable.

What to keep from the old system regardless

Keep raw exports of everything, plus PDF payslips and Form 16s, in your own storage. Statutory record-retention obligations do not transfer to your new vendor. Once the subscription lapses, portal access typically goes with it, and teams tend to discover that in the week someone needs a three-year-old payslip for a loan verification.

Our own sequencing guide, the HRMS migration playbook for Indian HR teams, goes further into ordering the load itself.

Pricing a Keka Alternative in India: Per-Employee or Flat-Fee

Pricing is where switching decisions are usually made and where they are most often made badly.

Per-employee-per-month pricing is the Indian market default. It is transparent and it scales with you in both directions. Its weakness is module gating: the headline rate covers core HR, and payroll or hiring arrive as separate line items that appear at renewal. One published Indian buyer's guide lists per-module pricing creep on renewal among the most common reasons companies start looking elsewhere.

Flat-fee or banded pricing gives you a predictable annual number, which finance teams like. The catch is that a band priced for 200 employees is expensive at 120, and you rarely get money back when headcount dips.

Three questions cut through vendor pricing decks:

1. What is the all-modules price, not the entry price? Ask for a quote with everything you would actually deploy.
2. What is the implementation charge, and is it one-time or recurring as "support"?
3. What does the renewal look like in year two and year three, in writing?

Our own pricing is published rather than quoted: per user per month, billed yearly with 10 users included, Ignite is ₹49, Pulse ₹52, Pulse Plus ₹82 and Apex ₹112, with a free Launchpad tier to start on. You can read the full breakdown on the Human Maximizer pricing page. We publish it because a buyer comparing three vendors should not have to sit through three calls to learn a number.

On contract overlap: budget for one to two months of paying both vendors. That overlap is the price of the parallel run, and it is cheaper than the alternative. Negotiate it deliberately rather than discovering it. If your existing contract auto-renews annually, count backwards from the renewal date and start the migration at least 90 days out, not 30. Ask, too, who owns the implementation handover once the go-live call ends, because an unowned handover is where a clean migration quietly decays.

Payroll and Compliance: What "Automation" Should Actually Mean

Payroll automation is claimed by every vendor. The useful test is narrower: does the system compute statutory obligations correctly for your state and your establishment type without someone manually adjusting a spreadsheet afterward?

Specifically, ask a prospective vendor to demonstrate these live, with your own data:

• PF computed against restricted or unrestricted wages, your choice, with the ₹15,000 ceiling applied per your policy, and an ECR file generated in the format EPFO accepts. The PF deposit and ECR filing deadline is the 15th of the following month, and a system that cannot produce a filing-ready file on the 12th is not automating anything.
• ESI contribution and eligibility handling across the contribution period, not just at a single point in time.
• Professional tax by state, including states with no levy.
• Full and final settlement computed to the two-working-day expectation set out under the Code on Wages, along with gratuity where it is due. Read the Code on Wages, 2019 as enacted yourself, particularly its definition of wages, before you accept any vendor's interpretation of it.

There is a difference between a system that calculates and a system that catches. Human Maximizer keeps a dedicated in-house compliance team tracking statutory changes, which is how the rules stay current in the engine. That is a human process behind the software, and we would rather describe it accurately than call it something autonomous.

What our own migration logs show

We cannot publish a named client migration timeline, because we do not have permission to publish any client's results and will not invent one. What we can publish is the aggregate from our internal implementation tracker, with its sample sizes attached.

These are our own project logs, not a third-party study, and they are averages rather than promises. A company running 14 salary structures across three states will sit at the slower end of the first row. If you want the provenance behind how we built the product in the first place, our team interviewed 50+ Indian HR managers and payroll specialists during development, which is on our about page.

Feature Parity: Attendance, Leave, Performance and Self-Service

Parity is not about counting modules. It is about whether the specific workflows your managers already rely on survive the move.

Attendance is usually the most configured part of any HR system, and therefore the most fragile in a platform transition. Shift patterns, overtime rules, late-mark grace periods, week-off logic, biometric device mappings: each is a small decision someone made two years ago and nobody documented. Before you migrate, export your existing shift and policy configuration and rebuild it explicitly. If your workforce is field-based, check how geo-fenced check-ins reconcile against the roster, since Attendance Management that treats location and shift as separate systems will produce exceptions your payroll then inherits.

On self-service, the practical measure is what fraction of routine HR queries an employee can resolve without messaging HR. Payslip download, tax declaration, leave balance, applying for a shift swap. Most operational friction lives at the handoffs, where one team considers a request done and the next has not started it. An internal helpdesk with SLA timers and escalation rules, which is what our Ticket Management module does, converts scattered WhatsApp queries into something with an owner and a clock.

Here is a concrete exception-handling example of how the switch should behave once you are live. An employee in a Nagpur manufacturing unit is marked absent for two days because their biometric punches failed to sync during a device outage. Roster Management shows they were scheduled and their supervisor's shift log confirms attendance. The exception is flagged before payroll locks, the supervisor regularises the two days against the roster, and the corrected attendance flows into the payroll run without an off-cycle correction afterwards. The point is not that nothing goes wrong. Things go wrong. The point is whether the system surfaces the mismatch before the salary is disbursed or after.

For performance, the migration question is whether in-flight review cycles carry over. They usually do not, cleanly. Plan your switch between cycles, and if you cannot, export the current cycle's ratings and feedback as a flat record before you move. Goal alignment can be re-established quickly in a new system through a module like Synergy, which syncs OKRs between managers and their direct reports. Historical review narrative cannot.

Employee Data Privacy When Changing HRMS Providers

This is the section most guides to switching HR software omit entirely, and it is the one with legal weight.

Migrating employee records means moving PAN numbers, Aadhaar-linked UANs, bank account details, salary history, and often medical or disciplinary records. India's Digital Personal Data Protection framework treats these as personal data with obligations on you as the entity determining how they are processed. Your obligations do not pause during a migration.

Practical steps that cost you almost nothing and protect you considerably:

Do not email the export. A full employee master in an email attachment is a breach waiting for a forwarded thread. Use an encrypted transfer or an upload directly into the new platform.

Have a written data processing agreement with the incoming vendor before you send a single file, covering where data is hosted, who at the vendor can access it, retention on termination, and breach notification.

Ask where the data physically sits. Data residency is a legitimate question for an Indian employer, and any vendor should answer it in one sentence.

Minimise what you move. You probably do not need to migrate scanned documents for employees who left four years ago. Archive them separately under your own control instead of loading them into a new system where more people can see them.

Document deletion from the old vendor. When you exit, request written confirmation of data deletion under the terms of your contract. Get it before you stop paying, because your leverage disappears afterwards.

Restrict access during the transition. Migration temporarily concentrates access, since a small team can suddenly see everyone's salary. Time-box that access and revoke it on completion. Employee Documents Management with role-based permissions should be configured before the bulk load, not after.

Where This Approach Does Not Help

A parallel run is genuinely expensive in attention, and it is not always the right call.

If you are a 30-person company with a single salary structure in one state and no variable pay, a full month of dual processing is probably over-engineering. Run a single reconciled test cycle against last month's actuals instead, and spend the saved effort on training.

The reconciliation approach also assumes your old data is correct. It is not always. If your existing system has been quietly computing PF on an incorrect wage definition, a zero delta means you have faithfully reproduced a mistake. Where you suspect a historical error, get it reviewed by your CA or a labour-law adviser before migration, because a switch is exactly when such errors become visible to an inspector.

And no software resolves a policy your leadership has not decided. If your leave encashment rule has been "whatever the HR head approves," no import template will fix that. Write the policy first.

One more honest note, and it cuts against our own commercial interest. If you are a single-entity company somewhere in the 50-to-300 headcount range, running standard leave policies and operating only within India, your incumbent platform may well be adequate. Switching costs are real. Migrate because your current system is genuinely failing you on compliance or cost, not because a comparison table looked appealing.

Scalability: Off-the-Shelf or Custom-Built

Teams outgrowing their first HR system often ask whether to build. Three archetypes, honestly assessed:

Custom builds fail on statutory maintenance, not on features. Every change to PF rules or to a state's professional tax schedule becomes a sprint your engineering team did not plan for, forever. Unless HR software is your product, that is a poor allocation of engineers.

Point tools fail at the handoffs, which is where most operational friction accumulates anyway. Attendance in one system, payroll in another, with a monthly export-import ritual between them: that ritual is exactly the mapping gap this article opened with, except you perform it every month instead of once. Our longer argument on this sits in choosing the best HRMS software in India.

Frequently Asked Questions

How does per-employee HRMS pricing in India actually compare across vendors? Compare all-in configured cost, not headline per-user rates, because module gating is where the difference appears. Ask each vendor for a quote covering every module you would deploy, plus implementation, plus the year-two renewal figure in writing. Our own tiers are published at ₹49 to ₹112 per user per month billed yearly, so the comparison starts from a real number.

What is the process for migrating employee data out of an existing HRMS? Export the employee master, salary structures, attendance and leave registers, processed payroll registers, and PDF payslips and Form 16s. Map each field to the new system's schema in a written ledger before importing anything, then load into a test environment and reconcile against last month's actual payroll. Keep the raw exports in your own storage permanently.

How do I handle contract overlap when changing HRMS providers? Plan to pay both vendors for one to two months, which funds the parallel run. Start the process at least 90 days before your current contract's auto-renewal date, and make cancellation conditional on a clean reconciliation rather than on a calendar date.

Should we build our own HRMS instead of buying one? Only if you have engineering capacity permanently committed to statutory maintenance. PF, ESI, professional tax and wage-code rules change, and each change becomes your team's work indefinitely. For most Indian companies under a few thousand employees, that maintenance load outweighs the configurability gained.

Conclusion

Go back to the mismatch this started with: an export file whose columns do not line up with the import template, discovered in the week payroll locks. That is not a data problem. It is a sequencing problem, caused by cancelling the old contract before proving the new system reproduces the old numbers. The Zero-Delta Switch fixes the sequence. Reconcile first. Document every mapping. Then let the cutover be a condition you meet rather than a date you hit.

The cost of getting it wrong is specific and dated. PF and ECR filings are due by the 15th of the following month, and a migration that breaks in the first cycle puts that deadline, and the interest and damages that follow a missed one, directly at risk.

Planning a switch and want the reconciliation done properly before anyone gets paid from the new system? Talk to our team about how a Human Maximizer migration is sequenced.

---

About the Author & Reviewer

Nishant Tandon — Co-founder & Lead Partner, Razor Infotech
Nishant Tandon is Co-founder and Lead Partner at Razor Infotech, with over a decade in IT, customer support and business operations, helping SMEs achieve cost efficiency, stronger customer experience and scalable, sustainable growth.
Connect on LinkedIn

Reviewed & approved by Sameer Hameed — Founder & Chairman, Razor Infotech
Sameer Hameed is the Founder & Chairman of Razor Infotech, where he is guiding the creation of Human Maximizer. An entrepreneur across technology, real estate, mining and travel, he builds organisations on clarity, trust and responsible growth — on the belief that businesses grow only when the people behind them grow.
Connect on LinkedIn

Human Maximizer is built by Razor Infotech in New Delhi, India (founded 2019). About Human Maximizer.