Skip to content
Who's In

Everything  /  Tools

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.