Moving From the Spreadsheet
A week of work, done in the right order, and the one thing that must be right before anyone logs in.
Tools
Moving attendance to a product is a small migration with one hard part: the opening balances.
Get the balances right first
Everything else can be fixed later. This cannot, because people check their balance on day one and a wrong number destroys confidence in the whole thing.
Recalculate each person's entitlement from scratch rather than importing last year's figure.
Reconcile against the spreadsheet, person by person, and investigate every difference. The spreadsheet is wrong about as often as the calculation.
Show each person their opening balance before go-live and ask them to confirm it. Ten minutes each, and it converts a future dispute into a conversation now.
Choose the moment
The start of a leave year, if one is close. Everything is cleaner.
Otherwise mid-year is fine, with opening balances as of a stated date.
Not during your busiest period, and not while the person who owns the spreadsheet is on holiday.
What to bring across
Current balances, per person.
Approved future leave, which people have already booked and planned around. Missing this is the most annoying possible error.
The current leave year's history, for context.
Older history: leave in the spreadsheet, archived and readable, rather than imported. There is rarely a reason to carry years of detail into a new product.
Sickness dates within the statutory look-back, because sick pay linking rules need them.
Keep the spreadsheet
Frozen, read-only, kept for the retention period.
Not updated in parallel, which produces two versions and an argument.
Named so its status is obvious, which sounds trivial and prevents someone editing it in a year.
Running both is not the answer
Unlike payroll systems, attendance does not need a parallel period.
The calculation is checkable by hand, which is faster and more reliable than running two systems.
Check a sample of five people after the first month against what the spreadsheet would have said.
Telling people
What changes for them: where to book, where to see their balance, how to report sickness.
What does not change: entitlement, the process, who approves.
That their balance was checked and confirmed.
Five minutes at a team meeting, which is the whole training requirement for a product in this category. Anything more is a sign the product is wrong for the size of business.
Bring across approved future leave
The error that annoys people most and is easiest to avoid.
People have booked time off and planned around it.
Losing it in a migration means someone turns up to a shift they arranged childcare to avoid, or discovers their holiday was never approved.
Check it person by person before go-live, not afterwards.
And ask people to confirm their own bookings, which takes minutes and catches what the migration dropped.
A concrete product reference
When translating this principle into a buying test, project time tracking application provides a concrete workflow reference. Verify the current behaviour in a trial, retain the exported evidence and judge it against the purpose and limits described above.