Switching time clock systems without losing your history

The risk is the cancellation, not the setup

Setting up a new time clock is a known quantity. You add your people, you put a device on the wall, you run a pay period. It takes a few hours and if it goes badly you have lost a few hours.

Cancelling the old one is the irreversible step, and it is the one people do casually because it feels like the end of the process rather than the middle. The old subscription lapses, the account goes read only for a grace period nobody notes down, and then one day the login stops working. Two years of clock in and clock out records are now somewhere you cannot reach, and you will not discover this on a quiet Tuesday. You will discover it when somebody asks a question about a shift from eighteen months ago.

Under federal recordkeeping rules you are required to keep timekeeping records for two years and payroll records for three, and the limitations period for a wage claim reaches back two years, or three where a violation is found willful. Your obligation does not transfer to the vendor and it does not end when the subscription does.

What to export, specifically

Ask for everything, in a format you can open without the vendor. CSV is ideal because any spreadsheet program reads it and it will still open in ten years. A PDF report is a picture of your data rather than your data, and a proprietary backup file is worse than nothing because it requires the product you just cancelled.

• Every clock in and clock out, for the full history, with dates, times, employee identity and location. Not a summary of hours. The individual records.
• Timesheet totals per pay period, so you have the figures that were actually paid alongside the raw punches that produced them.
• The correction history if the product keeps one. Who changed what, when, and from what to what. Many products do not expose this in an export, and it is worth asking specifically.
• The employee list, including people who have left. Departed employees are exactly the ones a future question is most likely to concern, and roster exports routinely omit them unless you ask.
• Punch photographs, if the product captures them and you have a reason to keep them. Consider your own retention policy here rather than hoarding by default.

Then open the files. Actually open them, in a spreadsheet, and look at a month you remember. An export you have never opened is a file of unknown contents, and the failure mode is finding out it is empty or truncated after the account is gone.

Where to keep it

Somewhere that is not one person’s laptop and not the new vendor either. A folder in whatever cloud storage the business already pays for, with a name that says what it is and what period it covers. The point of this file is that it survives the next change too.

Bringing the history into the new system

There are two positions on this and both are respectable. You can keep the archive as files and start the new system fresh, or you can import the history so that everything lives in one place.

Files are simpler and cost nothing. The trouble is that a file is only consulted by somebody who remembers it exists. Two years from now, the manager answering a question about a shift from the old system may not be the person who did the migration.

Importing is better if the new product will take it honestly. The word honestly is doing work there, because an import can be done in two very different ways. If the imported records are recomputed by the new system’s own hours engine, you get history you can actually use: it groups into pay periods, it totals correctly, it appears on the same screens as everything else. If the import only stores the old system’s computed totals as text, you have a picture again.

We built ours the first way, and there are two decisions inside it worth borrowing as questions for any vendor. Imported records are marked as imported, permanently, so nobody two years from now mistakes a record brought from elsewhere for one this clock took. And the hours are recalculated from the raw times under your own settings rather than trusting the file’s totals. On the first real month we tested, the recalculated figure differed from the file’s own total by about one hour across a month. Neither number was fraudulent. They were computed under different rounding assumptions, which is exactly why you want to know which one you are looking at.

Run both for two pay periods. Not one.

This is the step everybody wants to skip and the one that finds the problems. Run the old system and the new one at the same time, for two complete pay periods, and reconcile them employee by employee.

Two periods rather than one, for three reasons.

1. The first period is contaminated by the changeover. People forget the new clock exists, somebody is missing a badge, a manager fixes half the week by hand. You learn about adoption, not about arithmetic.
2. Overtime only shows up in a busy week. If the first period is quiet, the workweek boundary and the overtime split are untested.
3. Two periods catch the things that differ by a small amount. A one hour difference in a single period looks like somebody forgot to punch. The same one hour difference in both periods is a rounding or break setting that does not match, and that is a real finding.

Reconcile per person, not in total. Totals can match while two employees are wrong in opposite directions, and the person whose hours are short is the one who will notice.

When the figures differ, the usual causes are boring and quick to find: a different rounding setting, a break policy that deducts in one system and not the other, a workweek that starts on a different day, or an overnight shift landing in a different week. Check those four before you check anything else.

What does not migrate, and what to do about it

Some things cannot come across, and knowing which in advance turns a nasty surprise into a task on a list.

• PINs. A well built system stores PINs hashed, which means they cannot be exported in a usable form. Plan to issue new ones. If your old vendor CAN hand you a list of everybody’s PIN in plain text, that is worth pausing over, because it means anybody with access to that system could read them too.
• Badge credentials. Physical cards can often be re enrolled rather than replaced, since the card’s identifier is a property of the card. Ask whether the new reader produces the same identifier format before you order anything.
• Permission levels and roles. Every product models these differently. Write down who should be able to do what before you start, rather than trying to mirror the old structure.
• Wage rates. Often deliberately not exported, and often held in your payroll provider rather than your time clock in the first place.
• Anything the old product computed rather than recorded. Accrual balances, scores, streaks. If it was derived, it will be derived differently.

A timeline that works

Six weeks, most of which is waiting rather than working. Compressing it is possible and the step people compress is the parallel run, which is the one that protects them.

1. Week one. Export everything from the old system and open the files. Set up the new system: people, locations, pay period, workweek, break policy, rounding. Copy the settings across deliberately rather than accepting defaults, because the defaults are where the reconciliation differences come from.
2. Week two. Put the new clock on the wall beside the old one and tell people what is happening and why. Expect the first three days to be untidy.
3. Weeks three and four. Both systems run. Reconcile the first period per employee and fix what differs.
4. Weeks five and six. Both systems run again. Reconcile the second period. If it comes out clean, you are done.
5. Then, and only then, cancel. Check your export one more time first. It costs five minutes and it is the last opportunity you will have.

One last piece of advice that has nothing to do with software. Tell your team before the device appears, not after. A new time clock that shows up unannounced reads as surveillance, and a new time clock that was explained a week earlier reads as the business fixing the thing everybody complained about. The technology is identical. The reception is not.