Deployment

Migrating time attendance data from legacy software

Deployment · 8 min read

Replacing attendance software does not mean carrying every old table forward. Attendance data has to be selected, reconciled and previewed before writing, or the new system simply inherits the old errors.

Not every old record should move

Legacy attendance data usually has three layers: employees, shifts and devices; raw punch logs; and calculated timesheets. Not all of them deserve a full migration. Years of history can often stay in read-only files, while the new system needs current data and the periods HR still has to reconcile.

A practical scope is: complete master data, recent raw punches, closed timesheets for reference periods, and balances that still affect payroll such as leave, advances and active allowances.

Employee code mapping is the critical path

Most migration defects come from employee identity. The old software may store leading zeroes, the time clock may use card numbers, and HR may keep a separate employee code. Dropping leading zeroes or matching by name is a fast way to attach someone else's punches.

The safest route is to map against the company's official employee code, keep a separate device-card mapping, and export unmatched rows for HR review. Do not auto-create employees just because a device log contains an unknown code.

Raw punches or calculated timesheets?

If you migrate only calculated timesheets, you preserve closed figures but cannot explain how they were produced. If you migrate only raw punches, the new system can recalculate, but the first payroll period may not match the old result immediately.

In real rollouts we keep both with different roles: raw punches are processed and reconciled by the new engine; closed legacy timesheets become the comparison baseline. Differences are then classified as log issues, shift configuration, leave data or rounding policy.

Preview and backup are not optional

Every large import should have a preview mode: matched rows, missing employees, duplicates and rows that would update existing data. Only after HR accepts the mismatch report should the job write anything.

Before writing, create a backup of the target tables or run inside a transaction that can roll back. This is not ceremony. One bad attendance import can distort hours, payroll, leave balances and audit reports.

Run both systems for one period

The first payroll period after migration should be run in parallel. The legacy system is the baseline; the new system recalculates the same period. Every difference gets classified: old system defect, new configuration defect, or a policy change that has not been reflected in formulas.

Once the important groups reconcile, lock the period in the new system and make it the source of truth.