Leaving Keka without losing payroll history

Leaving Keka is a payroll problem wearing an HR problem’s clothes. The directory and the reports come out of the reporting tools, and that part is manageable in an afternoon. What decides whether the move is calm or expensive is the year-to-date payroll position of every person on your roster, because the Indian financial year does not restart when your vendor contract does. Get the payroll and statutory records out first, choose your boundary deliberately, and the HR side is comparatively easy.

One note on sourcing before anything else. What follows about Keka’s own product is our reading of their public help material, read in August 2026, and gathered through search because direct access to their help centre is blocked from where this was written. Their help centre is the authority, screens move between releases, and you should confirm the current article before you plan a week of work around a menu path. Everything else here is about your obligations and your data, which do not move when a vendor ships a redesign.

What you are actually moving

An India-first payroll suite holds more than a directory, and the piles arrived through different doors:

• The directory. Who works here, in what capacity, on what terms, from which location and legal entity. This is your master index and everything else is checked back against it.
• Documents. Offer letters, contracts, PAN and Aadhaar copies, education and past-employment papers, policy acknowledgements, anything uploaded to a profile.
• Payroll output, per closed month. The pay register for each run and the payslip each person received. These are the human-readable record of what you actually paid.
• Statutory output, per period. The PF and ESI returns, the professional tax statements, the income tax reports behind the quarterly TDS returns, and the Form 16 set for each completed year, together with the challans and acknowledgements that prove the money went where the return said it did.
• Balances and policies. Leave balances as at your cutover, and the accrual rules that produced them.
• The year-to-date position, per person. The running totals that carry through the financial year. This is rarely a single named report in any product, and it is the one that costs you money if you leave it behind.

The export checklist, in order

Do all of this while the account is active and paid. Access to reports is a function of your subscription in every product, and a former customer is a lower support priority everywhere.

1. Directory first. Keka’s help centre describes an employee master details report in the Org section, filtered and downloaded as a spreadsheet (help.keka.com, read August 2026). Take it with every column you can select, including custom fields, and keep it as your index.
2. Pay registers, one per closed month. Keka’s help centre describes the pay register for a selected month under Payroll and Run Payroll, in the payroll outcome for that run (help.keka.com, read August 2026). Pull every closed month of the current financial year at minimum, and every month you can still reach for the years you remain obliged to keep records for.
3. Payslips, in bulk. Keka’s help centre describes generating and downloading payslips for a selected set of employees from the manage payslip screen of a finalised run (help.keka.com, read August 2026). Take them per month, filed by month rather than by person, because that is how anyone will ask for them later.
4. The statutory set. Keka’s help centre describes payroll reports covering PF, including a monthly electronic challan cum return, an ESI monthly electronic return, professional tax statements including a state-wise view, and a family of income tax reports, downloadable in spreadsheet and document formats (help.keka.com, read August 2026). Take the file as filed, and pair each one with its challan or acknowledgement from the relevant portal. The return is only half the evidence.
5. Form 16, both halves. Part A originates from TRACES against your own TAN and is uploaded into the payroll system to be issued; Part B is produced from the payroll (help.keka.com, read August 2026). So keep three things: the TRACES source files, the issued documents, and the annual tax computation behind Part B. The first of those is recoverable from TRACES if you lose it. The third is not.
6. Documents. Keka’s help centre describes downloading documents from a person’s profile and from the employee documents area in the Org section (help.keka.com, read August 2026). Test the mechanism on one profile before you size the job. If files come out per person, your timeline is a function of headcount, and you want to know that in week one rather than week three.
7. Balances and policies. Export current leave balances and write the accrual rules down in plain words. You will be re-entering both by hand somewhere.
8. The year-to-date pack, which you have to ask for. See below.

The pack nobody exports until it is too late

Whoever computes your payroll after the move has to continue the financial year, not restart it. Restarting it means over-deducting or under-deducting tax for every person for the rest of the year, and then correcting it in March under time pressure.

Ask for one spreadsheet, one row per person, with these columns. Ask in those words, because a request for “our payroll data” gets you whatever is easiest to produce:

• PAN, employee code, date of joining, and date of leaving where it applies
• UAN and PF member ID, and the ESIC insurance number where the person is covered
• Year-to-date gross, broken out by pay component rather than as a single figure
• Year-to-date employee and employer contributions, by head: PF, ESI, professional tax, labour welfare fund where it applies
• Year-to-date tax deducted, and the projected annual tax the last run was working to
• The tax regime each person elected for the year
• Investment declarations on file, and which proofs have been accepted rather than merely submitted
• Previous-employer income and tax already taken into account for anyone who joined mid-year
• Perquisite values in progress
• Loss of pay days, arrears and any prior-period adjustments already processed
• Outstanding recoveries: loans, advances, notice pay, asset recoveries

Then reconcile the totals against your filed returns and your bank statements before you accept it. A pack that does not tie to what you filed is a pack that will be argued about in March.

Timing: the financial year decides, not your renewal date

The cheapest boundary is 1 April. Everybody starts the year at zero, the previous year closes with one party responsible for it end to end, and the Form 16 for that year is produced by the system that computed every month of it. If you can wait for that boundary, wait for it.

The next best boundary is immediately after a quarter has been filed and reconciled, because the quarterly TDS return is the unit the year is assembled from, and a boundary that falls between quarters leaves nothing half-reported.

The window to avoid is the January to March run-in, when the annual reconciliation, proof collection and Form 16 production all land at once. A vendor change in that window competes for the same weeks as the year-end work, and the year-end work has a statutory deadline while your migration does not.

When a mid-year move is worth it anyway. Waiting is the default, not a rule. Move mid-year when the current arrangement is actually failing, meaning filings have been late, corrections are frequent, or support does not answer when a person’s pay is wrong. Move when a corporate event forces it: a new entity, an acquisition, a demerger, a change of TAN, which is a bigger reset than any software change. Move when a renewal date would otherwise commit you to a further full year. And move when the cost of staying is being paid every month in manual work, which is a real cost even though nobody invoices you for it. In each of those cases the mid-year friction is the smaller number, and you should say out loud which number you are choosing.

Whenever you move, put the split in writing before anything is cancelled: which party files which return, for which period, and who issues Form 16 for the year. That single email is the cheapest insurance in the whole project.

The move that is cheaper mid-year than it looks

There is one structural way to take the sting out of a mid-year change, and it is worth understanding whichever vendor you choose next.

The system that holds your records and the system that computes your payroll do not have to be the same system, and they do not have to change on the same day. If you separate them, you can move the record whenever it suits you, and change who computes at the financial year boundary, because the year-to-date arithmetic stays where it was. Two smaller changes on two sensible dates beats one large change on a date chosen by a renewal invoice.

That separation is Capstan’s default rather than a workaround. Capstan compiles joiners and leavers, pay structures, leave, attendance and adjustments into a documented export for your payroll partner, and files the results the partner returns back onto each employee record. It holds no rate, slab, bracket, threshold or formula, computes no gross to net, and files nothing with any authority. The payroll module sets out exactly what crosses the line in each direction, and the reasoning is in why payroll should be a partner. If you want the shape of the alternative described plainly first, payroll-first HR systems is the one to read.

Where it tends to be hard

Documents may come out one profile at a time. Test it on day one and size the job from the answer, not from the assumption.

History flattens. A directory export gives you today’s salary, designation and manager, and nothing behind them. Pull whatever change or history report exists as a separate step. After cancellation, the answer to “can we still see the old figure” is no, in every product.

Leave balances mean nothing without their policy. A balance is the output of an accrual rule, and no two systems model accrual identically. Export the numbers, write the rules down in words, and expect to key opening balances in by hand.

Some things you rely on are screens, not reports. Anything you have only ever looked at rather than downloaded should be tested for export early. If it will not come out, decide now whether you need it badly enough to capture it another way.

Access ends on a schedule you should know in advance. Published terms for HR and payroll products generally describe a limited window after termination during which you can still retrieve your data, and a deletion process that follows it. Read your own contract for the actual dates, put both in your calendar, and finish your export well before the first one. Do not rely on a support exception you have not been granted in writing.

What you have to keep, whoever you buy from

Some of this is not a migration question at all. Indian employment and tax records carry retention obligations that follow the employer, not the software: payroll registers, the returns you filed and their challans, Form 16 issued to each person, PF and ESI records, and the registers required under the shops and establishment or factories rules that apply to you. The periods differ by statute and change, so confirm them with your chartered accountant rather than with any vendor, including us.

The practical consequence is simple and it survives every switch: keep your own dated archive, outside any vendor. A folder per financial year, sub-foldered by month, containing the registers, the payslips, the returns, the challans and the Form 16 set. Records you hold are records nobody can revoke, suspend or reprice. Build it even if you are not switching, because the day you need it is never a day you planned for.

Standing up the replacement

The general order to configure a new system in, what to set up before you load anybody and what to test before you invite the team, is a checklist of its own: use the implementation checklist alongside this, and read the steps below as the payroll-specific overlay.

1. Validate the export before you touch anything else. Open the files. Confirm the payslip count per month matches the headcount you actually paid. Confirm the register totals tie to your bank. A file that will not open is not a backup.
2. Load the new system in parallel, while the old one is live. With Capstan that means a spreadsheet import for people, with a dry run that previews every row and fails bad rows individually rather than sinking the batch. Be clear-eyed about what does not import: documents load per person, opening leave balances are entered as an adjustment carrying a reason, contractors are created individually as their own identity class, and effective-dated history is not imported at all. Your export from the old system stays your archive of that history. What imports and what does not is written out in full, and asking every other vendor the same question in the same words is the fastest way to compare honestly.
3. Set a go-live date before anyone starts marking attendance. One company-wide date means working days before it are treated as not expected rather than absent, so a parallel run never turns into loss of pay on the first payroll you compile.
4. Hand your payroll partner one period of inputs and compare. Run the export for a month you have already paid under the old system, give it to the partner, and check their output line by line against the register you exported. If those agree, your inputs are right. The payable days calculator is useful while you are checking prorations, and the CTC breakdown calculator while you are checking structures.
5. Reconcile ten people by hand. Across different locations, entities and pay structures, including one joiner and one leaver. If those ten are right, the bulk is probably right.
6. Cancel only after a full cycle has run cleanly, and after every register, return, challan and document is safely in the archive you control.

Who should stay where they are

Be fair to the product you are leaving. An India payroll suite that computes statutory deductions, produces the returns and carries the year-end through to Form 16 is doing a large, specific job, and it is doing it inside one login. If payroll computation and filing are the centre of your operation, and you want one vendor answerable for the whole of it, staying is a reasonable answer and we would say so in your position.

A record-first system with partner-integration payroll is a different shape. It suits teams whose priority is a clean, portable system of record, who already work with a payroll partner or a chartered accountant they trust, or who expect to operate in more than one country and do not want a computation engine per jurisdiction. It does not suit a team that wants the software itself to compute and file. That is not a gap awaiting a release; it is the design.

So the deciding question is narrow. If the purchase is payroll computation and filing, buy that. If the purchase is the system of record, with payroll handed to someone whose job it is, that is where this shape earns its place. The Keka comparison sets the two published models side by side, including where Capstan is the wrong tool. Read how to read an HR pricing page before you compare totals, and get every candidate’s all-in number at your real headcount. Capstan’s figures are on one public pricing page, adjusted by country, and the complete core is on every plan including the free one.

Where to go next

If you are new to the components themselves, statutory payroll in India is the conceptual map, and the HR compliance calendar sets out what falls due when, which is what your timing decision is really made of. If your move coincides with people leaving, the full and final settlement guide covers the exit calculation and who does which part of it. And whatever you buy next, start your shortlist with the export is the habit worth keeping: ask about the exit before you sign the entrance.