Most companies adopting an HRMS are moving from a spreadsheet that mostly works. The risk is not the software — it is the handover, where balances get lost or silently changed and staff stop trusting the numbers.
Pick a cutover date first
Choose one date. Before it, the spreadsheet is authoritative. After it, the system is. Do not run both — parallel running sounds cautious and reliably produces two divergent sets of numbers and an argument about which is right.
The start of a calendar year is cleanest because entitlements reset. Mid-year is entirely workable; it just means carrying opening balances across, which is covered below.
1. Reconcile the spreadsheet before you migrate
Do this first, while the spreadsheet is still the source of truth. For each person confirm the entitlement for the year, days taken to date, any carry-forward and its expiry, and any agreed adjustments. Get each employee to confirm their own balance — five minutes each now, versus a disputed balance in four months.
2. Create people with real join dates
Use each employee's actual original join date, not the cutover date. Join date drives pro-rating, tenure-based entitlement growth and probation tracking. Setting everyone to the cutover date breaks all three, and it is tedious to unpick later.
3. Set entitlements with the right tool
This is where migrations go wrong. There are two mechanisms and they are not interchangeable.
- Override — replaces the calculated entitlement for one employee, leave type and year. Use it when your agreed entitlement differs structurally from what the system calculates: a negotiated contract, a legacy arrangement, an unusual pro-rate.
- Adjustment — adds or subtracts days from an otherwise correct entitlement, with a mandatory reason recorded. Use it to carry an opening balance across mid-year, or to apply a one-off correction.
For a mid-year cutover the usual pattern is: let the system calculate the year's entitlement, then apply an adjustment for days already taken under the old spreadsheet, with the reason Opening balance migrated from spreadsheet, [date]. Your future self reading the audit log will be grateful for that reason line.
4. Do not import historical applications
Resist the urge to backfill last year's leave requests. It is a lot of data entry for records nobody consults, and the balance — which is what people actually care about — is already correct from the opening adjustment. Archive the spreadsheet read-only somewhere safe instead.
5. Set up approvers before anyone logs in
If approvers are missing on day one, requests route to nobody and the first impression is that the system is broken. Configure the reporting line and approvers for everyone before you send the invitations.
6. Check the holiday calendar
Verify the current and next year's public holidays under Admin → Settings. A missing holiday means over-deducted leave, and it is the error staff spot fastest.
7. Pilot before you announce
Give three or four people access for a week: one employee, one approver, one admin. Have them apply for leave, approve from the email link, file a claim with a receipt. You will find one thing that needs fixing, and it is much better to find it before the company-wide email.
8. Announce with the balance in hand
When you invite everyone, include their current leave balance in the message. It sets the expectation that the system agrees with the spreadsheet, and any discrepancy surfaces in week one when the spreadsheet is still fresh — rather than in month six, when it is not.
A realistic timeline
| When | What |
|---|---|
| Week 1 | Install, configure, create your company, verify holidays |
| Week 2 | Reconcile the spreadsheet, confirm balances with staff |
| Week 3 | Load employees, set approvers, apply opening balances |
| Week 4 | Pilot with a few people, fix what surfaces |
| Week 5 | Announce, invite everyone, archive the spreadsheet |
A determined admin at a twenty-person company can compress this into a weekend. The reconciliation step is the one not to rush.