A senior engineer at a sixty-person consultancy hands in her resignation on a Tuesday. Finance asks HR a simple question: what is her gratuity liability? The answer sits across four places. Her joining date is in a master employee sheet that has been re-saved eleven times since 2019. Her salary revisions are in three separate annual increment files. Her last drawn basic is in the July payroll sheet. Nobody is certain whether the six weeks she spent on unpaid leave in 2022 broke her continuous service or not.
Two days later, HR produces a number that is probably right, and that nobody can prove.
That is the moment most service firms decide to move on to a real HR system. The difficulty sits in carrying seven years of accumulated history across without losing the parts that hold legal and financial weight. This guide covers how to do that: what history to protect, what the law in India and the UAE requires you to keep, how to time the cutover, and which reconciliation checks catch errors before they reach a payslip.
What HRIS Migration Means When Your Source Is a Spreadsheet
HRIS migration is the process of moving employee records, payroll history, leave balances, org structure, and supporting documents out of an existing system and into a new HR platform, with the relationships between those records intact. Most published guidance assumes the source is another HR system. Coming from spreadsheets is a different problem, and harder in specific ways.
A legacy HR system, however dated, gives you three things a spreadsheet does not. It gives you a schema, so every employee record has the same fields in the same formats. It gives you referential integrity, so a leave record cannot exist without an employee to attach it to. It gives you an audit trail, so you can see who changed a salary figure and when.
Spreadsheets give you none of that. What you have instead is a set of files that encode rules in people’s heads. The leave tracker works because one person knows that a blank cell in column M means “carried forward, not yet approved.” The payroll sheet balances because someone manually adjusts row 47 every March. When that knowledge is not written down anywhere, migration turns into archaeology.
So the sequence changes. With a system-to-system migration, you start with field mapping. With a spreadsheet migration, you start earlier, by establishing what your data says before you decide where it goes. If you want a refresher on what a modern HR system holds and how the modules connect, our guide on what an HRIS covers in human resources lays out the structure you are mapping into.
The Four Kinds Of History You Are Protecting
“Don’t lose the history” is too vague to plan against. Break it into four categories, because each one is driven by a different requirement and each one fails differently.
- Identity and service history: Joining date, employment type, continuous service, designation changes, confirmation date, reporting line changes, exit date, and reason. This is the smallest dataset and the most consequential. Under Section 53 of the Code on Social Security, 2020, gratuity is payable on five years of continuous service at the rate of fifteen days’ wages for each completed year, calculated on last drawn wages, with fixed-term employees entitled on a pro rata basis after one year. Get the joining date wrong by three months, and you have misstated a liability that sits on your balance sheet.
- Payroll history: Month-by-month gross, component-wise breakup, statutory deductions, employer contributions, reimbursements, arrears, and year-to-date totals. This drives tax computation, statutory filings, and any wage claim that lands on your desk. Component structure matters as much as the totals, and our guide to payroll tax in India covers how those components interact.
- Leave and attendance history: Opening balances, accrual, availed, carried forward, encashed, and lapsed, per leave type per year. Balances are the visible part. The accrual rules behind them are the part that gets lost, and a balance without its rule cannot be recalculated or defended. Our guide on leave balance in India walks through accrual, carry forward caps, and encashment in detail.
- Work history: For a services firm, this is the fourth category, and it is the one general HR guidance ignores completely. Timesheets, project allocations, billable versus non-billable splits, and the billing rate that applied to each person on each date. Lose this, and you lose your ability to see utilization trends, price new engagements from evidence, or reconstruct how a past project made or lost money.
That last point is worth sitting with. SPI Research’s 2026 Professional Services Maturity Benchmark put billable utilization at 66.4 percent, the lowest level in the survey’s history. Knowing where your firm sits against that number requires a trend line, and a trend line requires history. A migration that resets timesheet data to zero costs you the ability to answer the question at all.
| History type | What it drives | What breaks if you lose it | Minimum you must carry |
| Identity and service | Gratuity, notice period, tenure-linked benefits | Terminal benefit calculation, exit disputes | Joining date, employment type, service breaks, exit date |
| Payroll | Tax computation, statutory filings, wage claims | Year-end certificates, claim defense | Component-wise monthly history for the current tax year, plus annual totals for prior years |
| Leave and attendance | Balances, encashment, statutory leave compliance | Employee trust, encashment payouts, audit | Opening balance and current balance per leave type, plus the accrual rule |
| Work and rates | Utilization, project margin, pricing | Benchmarking, estimating, client billing disputes | Timesheet detail for open projects, date-effective billing rates |
What The Law Requires You To Keep
This is where spreadsheet-based HR quietly creates exposure, and where migration is an opportunity to close it.
India
Section 50 of the Code on Wages, 2019 requires every employer to maintain a register with details of persons employed, muster roll, wages, and other prescribed details. Sections 1 to 41 and 43 to 66 of the Code came into force on 21 November 2025. You can read the consolidated text on India Code.
Three provisions in that same Code explain why the register matters more than most firms assume:
- Section 45(6) allows an employee to file a wage claim within three years of the date the claim arises, and the authority may entertain applications after three years on sufficient cause.
- Section 59 places the burden of proof on the employer. Where a claim is filed for non-payment or underpayment of wages or bonus, or for unauthorised deductions, the employer has to prove the dues were paid.
- Section 54(2) provides a fine of up to ten thousand rupees for non-maintenance or improper maintenance of records.
Read together, those three create a straightforward operational requirement. If a former employee raises a wage claim covering a period three years back, your records are the defense, and you carry the obligation to produce them. A spreadsheet nobody can vouch for is a weak position to argue from. This is the practical case for migrating payroll history rather than starting the new system at zero, and it is worth reading alongside our overview of statutory compliance for growing companies.
There is a second timing consideration specific to this year. The Income-tax Act, 2025 and the Income-tax Rules, 2026 took effect from 1 April 2026 and renumbered the salary TDS forms. Under Section 395(4)(b) read with Rule 215(1), the salary TDS certificate is now Form 130, replacing Form 16, and the quarterly salary TDS return is Form 138, replacing Form 24Q. The Income Tax Department’s Form 130 FAQ confirms that the certificate is generated from processed quarterly statements and downloaded from TRACES, and that where an employee has worked for more than one employer in a year, each employer issues Parts A and B for its own period.
That last clause has a direct migration consequence. Your payroll history has to preserve exact employment periods and period-wise TDS, because that is the granularity the certificate is built from.
United Arab Emirates
Article 13(1) of Federal Decree-Law No. 33 of 2021 requires employers to maintain worker files and records in line with Ministry requirements, and to keep those files for not less than two years following the date of end of service. The consolidated text with amendments is published by the Ministry of Human Resources and Emiratisation. Firms with staff in both India and the UAE end up carrying two different retention floors, which is a reason to keep retention rules as a configurable field in the new system rather than a policy document nobody reads.
One Tension Worth Naming
Statutory retention pushes you to keep more. Data protection principles, including India’s Digital Personal Data Protection Act, 2023, push you to keep less and to delete once the purpose is served. The resolution is not to pick a side. It is to make retention deliberate: define a period per data category, tie it to the statute that justifies it, and set the system to enforce it. Migration is the natural moment to do that, because you are already touching every record.
Decide What Moves, What Gets Archived, And What Gets Retired
Firms lose weeks trying to move everything. The stronger approach is to sort every dataset into one of three buckets before you write a single mapping rule.
Migrate
Data the new system needs to operate. Current employees, active org structure, live leave balances, current-year payroll, open projects and their timesheets, and any prior-period data that feeds a live calculation such as continuous service.
Archive
Data you must be able to produce but do not need to operate on. Payroll detail from four years ago, records of employees who left five years ago, superseded policy documents. Put these in a controlled read-only store with a retention label and an access log. They do not belong in your production HR system, and forcing them in slows every report you run.
Retire
Data with no operational, legal, or reporting purpose. Duplicate copies of the same sheet. Draft appraisal notes nobody finalised. Personal data collected for a purpose that ended. Retiring this is a compliance improvement, not a loss.
The decision rule is one question per dataset: does anything the new system calculates depend on this? If yes, migrate. If no, but a regulator, auditor, or claimant could ask for it, archive. If neither, retire it with a documented approval from whoever owns that data.
Audit Your Spreadsheets Before You Map Anything
This phase is unglamorous, and it determines whether the rest of the project goes well.
Inventory every source: Not the three files you think of first. The leave tracker, the payroll workbook, the offer letter folder, the WhatsApp thread where reporting line changes get announced, the finance team’s separate headcount sheet, the folder of scanned documents on someone’s laptop. For each source, record the owner, what it contains, how many records, how often it is updated, and which fields hold sensitive data.
Declare one source of truth per field: You will find conflicts. Payroll says the joining date is 3 March; the offer letter says 1 March; the PF record says 4 March. Pick an authority per field category rather than per file. Statutory records tend to win for legal names, identifiers, and joining dates. HR files tend to win for designations and reporting lines. Write the rule down, apply it consistently, and log every override.
Standardize formats before you clean values: Dates are the usual offender, because a firm running a decade of sheets will have DD/MM/YYYY, MM/DD/YYYY, text dates, and Excel serial numbers in the same column. Employment type will show as “Perm,” “Permanent,” “FT,” and “Full Time.” Fix format first, then fix content, then fix conflicts. Doing it in the other order means redoing work.
Keep a known-bad list: Some records will be unresolvable, usually for people who left years ago. Do not stall the project on them. List them, note what is missing, decide whether they move or get archived with a gap flag, and move on.
Running a broader HR audit alongside this is worth the extra week. You are already opening every file, and the same pass will surface classification issues, missing statutory registrations, and policy gaps that would otherwise migrate into the new system unchanged.
Map Flat Cells To A Relational, Date-Effective Model
The conceptual jump in a spreadsheet migration is from cells that hold current values to records that hold values with validity periods.
A spreadsheet column labelled “Basic Salary” holds one number: today’s number. When someone gets a raise, the number is overwritten, and the previous value is gone unless somebody remembered to save a copy of the file. A proper HR data model stores salary as a series of date-effective records, each with a start date, an end date, and a reason.
That difference matters in four places:
- Salary and CTC. Effective-dated records let you compute what someone earned in any past month without opening an archived file.
- Designation and grade. Promotion history supports internal equity reviews and defends against discrimination claims.
- Reporting line. Approval workflows need to know who the approver was at the time a request was raised, not who it is today.
- Billing rate. For a services firm, this is the one with money attached. If a consultant’s rate went from 4,500 to 5,200 an hour in April, work logged in March has to be billed at the March rate. A system that only stores a current rate will silently re-price historical work.
Juntrax stores billing rates with effective dates for exactly this reason, so time logged against a project is always valued at the rate that applied on the day the work was logged rather than today’s rate. When you migrate rate history, migrate the effective dates with it, not the current value alone.
Two practical mapping rules. First, never map two source fields into one target field without an explicit merge rule, because you will not be able to unpick it later. Second, where the new system has no matching field, decide deliberately between a custom field, a note field, and archiving the data. Dumping unmapped data into a free-text notes field feels like preservation and is closer to loss, because nothing can be reported on or validated from it.
Choose Your Cutover Date Deliberately
Timing is the decision that most affects how much work the migration creates, and it is usually made by accident.
- The financial year boundary is the cleanest option in India. Going live on 1 April means the new system runs a full tax year from a zero year-to-date position. No mid-year carry-in, no split TDS reporting, and Form 138 quarterly filings run cleanly from Q1. Prior-year payroll becomes archive rather than operating data.
- Mid-year cutover is workable and costs more. You have to carry year-to-date figures across accurately: gross paid, each statutory deduction, TDS deducted and deposited, and any exemption already granted. Reconcile those YTD figures against filed returns before you go live, not after. Tax Year 2026-27 is the first year running on the new form series, so a mid-year move this year means your carry-in has to survive both a system change and a form schema change.
- Avoid the last two weeks of any quarter. Statutory filing deadlines and payroll processing compete for the same people. Give yourself clear air.
- For UAE entities, the calendar year is the natural boundary, and end-of-service accrual calculations should be reconciled at cutover so the new system starts from an agreed liability figure.
If you run payroll in more than one country, stagger the cutovers rather than attempting a single global go-live. One entity at a time gives you a working template and a team that has already made its mistakes somewhere small.
Load In Waves, Then Run In Parallel
Sequence the load so that each wave can be validated before the next one depends on it.
Wave 1: Identity and Org structure
Employees, joining dates, employment types, designations, departments, locations, reporting lines, statutory identifiers. Validate headcount and reporting hierarchy before anything else lands.
Wave 2: Leave and Attendance.
Leave types, accrual rules, opening balances, current balances, and pending requests. Configure the rules first, then load balances, then confirm the system recalculates to the same balance you loaded. If it does not, your rule configuration is wrong, and finding that out now is much cheaper than finding it out in January.
Wave 3: Payroll
Salary structures, component definitions, bank details, statutory registrations, and year-to-date figures. This wave carries the most risk and deserves the most validation.
Wave 4: Work history and Documents.
Projects, timesheets, allocations, billing rates, and the document library.
Then run parallel for at least one full payroll cycle, and preferably two. Process the same month in both the spreadsheets and the new system, compare outputs line by line, and pay the employees from whichever you trust more while you resolve the differences. A parallel run is the only test that exercises the whole chain end to end, and skipping it is the single most expensive shortcut available in this project.
Run Reconciliation Tests That Catch Real Errors
Reviewing the data until it looks right is not a test. The checks below are.
| Check | Method | Pass condition |
| Headcount | Count active employees in source versus target | Exact match, and every difference explained by name |
| Payroll control total | Sum year-to-date gross across all employees, both systems | Exact match to the rupee or dirham |
| Component-level total | Sum each salary component separately, both systems | Exact match per component, because offsetting errors hide in a grand total |
| Statutory deduction total | Sum each deduction type against filed returns | Match to the filed figure, not to the spreadsheet |
| Leave balance | Sum balances per leave type, both systems | Exact match, plus a recalculation test on a sample of twenty employees |
| Service date integrity | Count records where joining date is missing, in the future, or after exit date | Zero |
| Statutory ID coverage | Count active employees missing a required identifier | Zero, or an approved documented exception list |
| Manager chain | Count employees with no manager, or with a circular reporting loop | One employee with no manager, no loops |
| Rate history | Spot-check ten consultants’ rate records against source | Every effective date preserved |
| Document linkage | Count documents not attached to an employee record | Zero |
Two habits make these tests worth running. Run them against a filed return or a bank statement wherever you can, rather than against the spreadsheet, because the spreadsheet is the thing you are testing. And run each one twice: once after the load, and once after the first parallel payroll, because a clean load can still be broken by configuration.
Handle The History You Cannot Move
Some history will not migrate cleanly. Scanned documents with no employee identifier. Payroll from a period before your current structure existed. Records for people who left in 2018.
Build a controlled archive rather than leaving those files on a shared drive. The archive needs four properties: a documented retention period per category tied to the statute that justifies it, restricted access with a log of who opened what, an integrity check so you can show the files have not been altered, and an index detailed enough that someone can find a specific record without opening fifty folders.
Note the gap in your migration record too. If nine former employees have incomplete payroll history, write that down with the reason. An audit finding you documented and decided on is a different conversation from one you appear not to have noticed.
A Realistic Timeline For A 25 To 150 Person Firm
Vendor estimates tend to cluster around a few weeks, while firms that skip the audit phase often spend months. The table below is what the middle ground looks like when the work is done properly, and the source is spreadsheets.
| Phase | Duration | Main output |
| Source inventory and audit | 2 to 3 weeks | Source register, source-of-truth rules, known-bad list |
| Cleaning and standardization | 3 to 4 weeks | Cleaned extract per dataset, conflict log |
| Field mapping and configuration | 2 weeks | Mapping document, configured leave and payroll rules |
| Trial load and reconciliation | 2 weeks | Test load in a sandbox, reconciliation results |
| Correction cycle | 1 to 2 weeks | Fixes applied at source, second trial load |
| Production load | 1 week | Live data in the new system |
| Parallel run | 1 to 2 payroll cycles | Verified payroll output, sign-off |
| Archive and decommission | 1 week | Locked archive, spreadsheets read-only |
Twelve to sixteen weeks end-to-end is a reasonable expectation, with the audit and cleaning phases taking roughly half of it. Compressing those two is the reason most migrations overrun.
One practical note on adoption: give employees self-service access early, ideally during the parallel run. When people can see their own leave balance and payslip, they find errors your reconciliation missed, and they find them for free. Our piece on how we use employee self-service at Juntrax covers what that looks like day-to-day.
Mistakes That Cost The Most
Cleaning data in the extract instead of at source: If you clean the exported file, the spreadsheet still holds the bad value and every subsequent extract reintroduces it. Fix it in the source, then re-extract.
Migrating current values instead of dated records: The most common way to lose history while believing you preserved it.
Treating payroll as one workstream with core HR: Payroll has its own cutover rules, its own reconciliation targets, and its own statutory deadlines. Give it a separate track and a separate owner.
Loading balances before configuring rules: The system will accept the balances and then recalculate them incorrectly at the next accrual run.
Skipping the parallel run because the trial load looked clean: A trial load tests the data. A parallel run tests the data plus the configuration plus the process plus the people.
Deleting the spreadsheets on go-live day: Lock them read-only, keep them for at least two payroll cycles past go-live, then archive them under the retention policy. Deleting them is irreversible, and go-live is exactly when you are most likely to need them.
Leaving no record of decisions: Every source-of-truth ruling, every conflict resolution, every known gap. Six months from now, an auditor will ask why a joining date changed, and the answer needs to exist somewhere other than in someone’s memory.
Where Juntrax Fits
Juntrax is a project-to-cash operations platform for small and mid-sized professional services firms, bringing HRMS, Professional Services Automation, and Cash-Flow management into one system. It works alongside your accounting system, whether that is Tally, QuickBooks, Xero, or SAP, rather than replacing it.
For a migration specifically, the relevant characteristic is that the four kinds of history described earlier land in one platform instead of three. Employee records, service history, and payroll sit in HRMS. Timesheets, project allocations, and date-effective billing rates sit in PSA. Invoicing and receivables sit in Cash-Flow. Because they share a database, a consultant’s cost rate and the projects they bill to stay connected without an export and re-import between an HR tool and a project tool, which means one less integration to rebuild during cutover and one fewer place for history to drift out of sync afterward.
That structure suits consulting firms and engineering services firms in particular, where the connection between hours worked, cost, and invoice is the thing that determines margin. If you are still building a shortlist, our roundup of HRIS systems compares the category more broadly, and pricing is published rather than quote-only.
Wrapping Up
The firms that come through this well are the ones that treat history as four separate problems rather than one, decide deliberately what moves and what gets archived, pick a cutover date that works with their filing calendar instead of against it, and refuse to skip the parallel run.
The engineer who resigned on a Tuesday is a good test to hold in mind. After migration, that question should take a minute, and the answer should be defensible from records rather than from memory.
Frequently Asked Questions
How long does an HRIS migration take when moving from spreadsheets?
Twelve to sixteen weeks is realistic for a firm of 25 to 150 people, including a parallel payroll run. Roughly half of that is source auditing and data cleaning. Migrations quoted at four weeks usually assume a clean source system and skip the audit phase, which is the phase that determines whether the history survives.
How many years of payroll history should we migrate?
Migrate the current tax year in full component-level detail, plus annual totals for prior years. Archive the older detail. In India, Section 45(6) of the Code on Wages, 2019 allows wage claims to be filed within three years of the claim arising, and Section 59 places the burden of proving payment on the employer, so three years of retrievable payroll detail is a sensible floor.
What is the safest cutover date?
In India, 1 April, because the new system then runs a complete tax year from zero year-to-date and quarterly Form 138 filings start cleanly at Q1. In the UAE, the start of the calendar year. Mid-year cutover is possible but requires carrying year-to-date figures across and reconciling them against already-filed returns before go-live.
Will we lose leave balances during migration?
Only if you load balances without first configuring the accrual rules. Configure the rules, load opening and current balances, then have the system recalculate the balance from the rules and compare against what you loaded. Any mismatch is a rule configuration error, and it is far cheaper to find it before go-live than at the next accrual run.
Do we need to keep the old spreadsheets after go-live?
Yes. Lock them read-only on go-live day and keep them accessible for at least two payroll cycles, then move them to a controlled archive with a defined retention period. In India, the Code on Wages, 2019 requires wage registers to be maintained. In the UAE, Article 13(1) of Federal Decree-Law No. 33 of 2021 requires worker files to be kept for at least two years after the end of service.
What happens to gratuity calculations if service dates are wrong?
The liability is misstated. Under Section 53 of the Code on Social Security, 2020, gratuity is payable at fifteen days’ wages for each completed year of service on five years of continuous service, calculated on last drawn wages, with fixed-term employees entitled pro rata after one year. Joining date and any breaks in continuous service are therefore the two fields to validate most carefully, and both should be reconciled against statutory records rather than against the HR spreadsheet.
How do we migrate historical billing rates for a services firm?
Migrate rates as date-effective records with their start and end dates, not as a single current value. Work logged in a prior period has to be valued at the rate that applied on the date it was logged. A system that only stores a current rate will re-price historical timesheets and quietly change past project margins.
Should the vendor handle the migration, or should we?
The vendor can execute the technical load. Your team has to own the business decisions: which source is authoritative per field, which conflicts get resolved which way, and final sign-off on reconciliation. Those judgments need context about your firm that a vendor does not have, and they are the ones an auditor will ask about later.